openmediavault-onedrive: Deletes all contents (from Onedrive) after reboot

1. offizieller Beitrag

    Hi everyone,


    I'm starting to make more use of the UI features that OMV offers and really like the proposition of using my 1TB Onedrive storage, that came with Office 365 Family, purerly to backup my Pictures.


    However, since only one "Ondrive" Shared Folder can be defined, I would need to move all of my nicely structured data to a separate folder and I don't particularly like that. I though I could make use of Symlinks and therefore created a Symlink (using the OMV Plugin) to my "image" folder ("Bilder") on my media drive and checked if that would upload correctly. Lo-and-behold, it was synching to Onedrive like a champ.

    However, it's happend multiple times now, that all Images from Onedrive were delete after reboot and the "Bilder"-Folder would not continue synching to Onedrive, leaving me with an empty Onedrive folder...


    Originally I thought only the Symlinks are deleted, but the "Testdir" you see is actually a "physical" folder in the "onedrive" shared folder... After the last Reboot both were gone again.



    What's going on here? Am I not supposed to create the "onedrive" folder on a mounted drive and instead should put the "onedrive" folder on the root filesystem and then use symlinks from there to my files? As stated before, after the reboot, the synching never starts again.


    Update: I played around a bit and noticed that the service would not start anymore after the reboot (or would start and then shut down)... I decided to uninstall and reinstall the plug-in, run omv-onedrive-auth again and set the onedrive folder to my root partition (/onedrive_root).


    Now the folders on Onedrive also survived a reboot. Since rebooting the machine takes quite a while in my case, I'm leaving it at that for now. I discovered the "onedrive --display-config" command and saw that it is also possible to enable a log, by setting the flag in the config path (I'm not quite sure how to do that though). Could you give me some directions on how the configuration of the plugin works, so I can work and report with more details next time? :)


    Update2: Being the curious cat I am, I of course had to test it with the Onedrive folder on my attached USB-Harddrive. Once I used Onedrive on that drive after a reboot all files were gone again:

    Code
    Jul 28 23:06:01 suteki-omv onedrive[1084]: Initializing the Synchronization Engine ...
Jul 28 23:06:01 suteki-omv onedrive[1084]: Initializing monitor ...
Jul 28 23:06:01 suteki-omv onedrive[1084]: OneDrive monitor interval (seconds): 60
Jul 28 23:06:01 suteki-omv onedrive[1084]: Starting a sync with OneDrive
Jul 28 23:06:01 suteki-omv onedrive[1084]: Uploading differences of /srv/dev-disk-by-id-ata-ST2000LM003_HN-M201RAD_S34RJ9FFC04314-pa>
Jul 28 23:06:01 suteki-omv onedrive[1084]: Deleting item from OneDrive: Testdir
Jul 28 23:06:02 suteki-omv onedrive[1084]: Deleting item from OneDrive: test.txt
Jul 28 23:06:02 suteki-omv onedrive[1084]: Deleting item from OneDrive: Bilder
Jul 28 23:06:03 suteki-omv onedrive[1084]: Uploading new items of /srv/dev-disk-by-id-ata-ST2000LM003_HN-M201RAD_S34RJ9FFC04314-part>
Jul 28 23:06:03 suteki-omv onedrive[1084]: Sync with OneDrive is complete

    I'm really not quite getting the logic here...


    Either way, switching back to putting everything on the SATA-attached Root-Folder, that seemed to work fine.


    Another obervation: When switching the shared folder, that onedrive should be using, it refuses to start:

    Code
    onedrive.service - OneDrive Free Client
     Loaded: loaded (/lib/systemd/system/onedrive.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/onedrive.service.d
             └─openmediavault.conf
     Active: activating (auto-restart) (Result: exit-code) since Fri 2023-07-28 23:10:42 CEST; 502ms ago
    Process: 5157 ExecStart=/usr/bin/onedrive --confdir /var/cache/onedrive --monitor (code=exited, status=126)
   Main PID: 5157 (code=exited, status=126)
        CPU: 34ms

    I assumed I'd need to run "onedrive --resync", however that fails with the error-message "ERROR: Unable to perform a database vacuum: out of memory"


    The only way to get onedrive running again for me was to uninstall the plugin, reinstall it, set it up once (with omv-onedrive-auth etc.) and set the onedrive folder on the root fs.

  • Dixxy

    Hat den Titel des Themas von „openmediavault-onedrive with symlinks: Deletes all contents in symlinked folder after reboot“ zu „openmediavault-onedrive: Deletes all contents (from Onedrive) after reboot“ geändert.
    Zitat

    However, it's happend multiple times now, that all Images from Onedrive were delete after reboot and the "Bilder"-Folder would not continue synching to Onedrive, leaving me with an empty Onedrive folder...


    So what is going on ...


    100% most likely, without knowing how your system is setup - your 'sync_dir' is a mounted drive - or something to that effect.


    When 'onedrive' is starting - and the mounted drive is not present - it is an empty folder - thus ... 'onedrive' thinks that you have deleted your data ... which you have not - its just not mounted yet.


    The additional problem you have here is the OMV plugin that has been developed, and from my perspective was implemented in such a way that it does not factor in how the 'onedrive' application is meant to be actually run (dont run as root, leverage user home directory for configuration files and so on). I cant solve how the OMV plugin operates.


    Now to potentially solve your issue - please read: https://github.com/abraunegg/o…ir-is-a-mounted-directory


    The issue is - the OMV plugin potentially wont support the required configuration additional items needed here to help you .. and if you do get this setup, that configuration will then be lost on next OMV change .. so your trick here will be working out how to get the OMV plugin configuration to use the additional configuration options, whist adding the .nosync file to your mount point - before your drive is mounted.


    Zitat


    I assumed I'd need to run "onedrive --resync", however that fails with the error-message "ERROR: Unable to perform a database vacuum: out of memory"


    You get that message specifically because you are trying to do a resync, on an application that is not authenticated - because you are not running the application as the user that the OMV plugin is running the application as (root) ..


    For further help please read the docs here: https://github.com/abraunegg/onedrive/tree/master/docs



    votdev

    Can you please look at re-working your plugin so that it works in a manner that is more consistent with how the application is meant to be run?

    • Offizieller Beitrag
    Zitat von abraunegg

    dont run as root

    OMV does not run onedrive as root, its using the configured user that is by default onedrive with limited privileges. This is done by overriding the systemd unit file with an additional conf file, see https://github.com/openmediava…/onedrive/default.sls#L61.

    Zitat von abraunegg

    Can you please look at re-working your plugin so that it works in a manner that is more consistent with how the application is meant to be run?

    What is "meant to be run"? I do not see any problem running the app this way. The plugin fulfills my personal needs exactly that way it is implemented. BTW, i do not see a better way to run it to fit into the concept how things are handled in OMV. I'm open for suggestions if you have a better solution.


    Nevertheless, i'll improve the plugin to harden the system unit to wait for the mount to be available. That's easy thanks to systemd.

  • votdev

    Hat das Label OMV 6.x hinzugefügt.
    • Offizieller Beitrag

    abraunegg The idea with .nosync is good, but in my opinion too short-sighted. Creating this file is possible in a single user desktop environment where the admin can do whatever they want, but not on a system with many users and services that are accessing this mount/file system. In that case it is simply not possible to unmount the file system to create the file without interrupting services like NFS, SMB, FTP and many others that are working on the same file system. Besides that from what it would mean to interrupt user file transfers, which would result in data loss. Another problem is that it is impossible to unmount a file system that is in use. IMO the better or additional solution to the existing one is to add a config option that allows the admin/user to specify a file in the sync_dir that MUST exist, e.g. .sync. If this does not exist the sync is stopped.

    abraunegg It seems that onedrive is indeed run by the specially created "onedrive" user:

    Could it be that the error I reported int he OP was because I was running the session as rootand not as onedrive user?


    The .nosync option would work fine by me, as this is a simple home-server. I believe most OMV-boxes would fullfill this purpose, so even if it is not ideal for a larger multi-user server, I think it would be a good thing if we have all the configoptions of the tool availalable to make use of the .nosync option.


    votdev I don't think you necessarily need to implement these config options into the UI (however nice that may be), but I believe other OMV Plugins/Features use ENV variables to set hidden options? Is that possible with the onedrive plugin to keep settings across updates?

    If not, could I just update the onedrive-config file in /var/cache/onedrive?


    All in all I feel the ENV option to be a bit clunky, especially if some plugins use it and some don't. But if everything in OMV works that way, I think one could get used to it.

    Zitat von votdev

    abraunegg The idea with .nosync is good, but in my opinion too short-sighted. Creating this file is possible in a single user desktop environment where the admin can do whatever they want, but not on a system with many users and services that are accessing this mount/file system. In that case it is simply not possible to unmount the file system to create the file without interrupting services like NFS, SMB, FTP and many others that are working on the same file system. Besides that from what it would mean to interrupt user file transfers, which would result in data loss. Another problem is that it is impossible to unmount a file system that is in use. IMO the better or additional solution to the existing one is to add a config option that allows the admin/user to specify a file in the sync_dir that MUST exist, e.g. .sync. If this does not exist the sync is stopped.

    That is the whole premise of .nosync in the directory where the file system gets mounted.


    This is the solution that works, this is the solution that has been tried and tested and validated over the last 5+ years.

    • Offizieller Beitrag
    Zitat von abraunegg

    votdev


    My opinion here is that you should support the use of a 'config' file in your 'onedrive user' home directory.

    Not to use the home directory of the user is done with reason because NO user in OMV has a home dir by design. It is possible to enable that, but then they are located on a shared folder and not at the default location that a normal user expects.


    Zitat von abraunegg

    votdev


    This will allow users to configure the application correctly based on the application documentation.

    If there is a option to specify an alternative path to the config file, then it is not wrong to use it. Additionally OMV plugins are meant to NOT be configured manually by the user. The system/plugin has complete control over the config files. So if a user thinks they need to change it manually, that's their fault.

    To make it short, the user is forbidden to modify the configuration because it brings the system in an erroneous state. IMO the main problem is not how OMV uses and implements onedrive, the real problem is that some users think they have to screw around with the configuration even though they have no idea what they are doing.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden