abraunegg

It has always been that way in the documentation, even in prior releases (v2.3.x, v2.4.x etc). Again I need to re-iterate that the client or Docker container does not do this. The integration / this plugin that has been created is what must be doing that. I did not create the integration used here.

I wrote the application. There is zero code that modifies a users config file. Great - but by default the client or Docker container does not write out any 'config' file. It only ever reads it. So the integration with this platform is where your problem lies as to why the 'config' file is being re-written etc ..... that is not my issue - but is an issue for the developer of the integration with this platform.

Permission issues are a problem for how this is integrated to this platform ... Are you unable to access all files, or just files post re-installation of the Docker container? If all files, then this will be some sort of unraid problem because the 2nd Docker volume that gets used is your physical disk media ... nothing is stored inside the Docker container.

@cosmas What is the content of the 'config' file before you start the Docker container and after? As per https://github.com/abraunegg/onedrive/blob/master/docs/usage.md#performing-a---resync - a resync is required when the following options are changed: drive_id sync_dir skip_file skip_dir skip_dotfiles skip_symlinks sync_business_shared_items Additionally, if you modify your 'sync_list' file, this also triggers this requirement. A hash file is used to determine if the file has been changed, changing a single character in a comment will trigger a check of the 'config' or 'sync_list' to determine if something has changed, so the current backup of the files are read in, so that they can be compared with the current actual files. If there is then a difference in the options being used, then this flags that a resync is required. So .. either these options are being changed by Unraid (and given the config file is being updated - and I know that the 'onedrive' client does not do this) - this is why I am advising this is not a 'onedrive' bug or issue .. it is to do with how this has been integrated with this platform.

As the developer of the 'onedrive' application used within the Docker container, I know what the code of the application does. As the provider of the Docker image https://hub.docker.com/r/driveone/onedrive I also know what it does - which is it only uses a Docker volume to read a 'config' file if it exists, and to store the online cache file and your access token to the OneDrive service. Neither the application or the Docker container writes a 'config' file. The application 'only' reads it if it exists. Who ever implemented this in this platform, something with that integration is modifying the 'config' file each and every time - it is not the 'onedrive' binary or the Docker container.

Whilst it may be in a loop - your theory that the container changes the config file is 100% inaccurate and false. The application and/or the Docker container has zero code to write to the 'config' file. The application only ever reads it and closes it post reading it. This issue you are all facing is something to do with how the Docker container has been integrated with this platform.