onedrive docker asking for --resync in endless loop

[kobby-w]

Hello,

I have the problem that I run onedrive docker on Unraid since years, but after the last update its asking for a --resync because the config files was changed.

I let the config file unchanged and started docker with ONEDRIVE_RESYNC=1. After it was synced and finished, I removed ONEDRIVE_RESYNC=1 and restarted onedrive docker. But its aksing again for --resync as the config file was changed, but it was not changed. I tried this already several times. It finishes with "Sync with Microsoft OneDrive is complete"

Error:

# Running container as user: onedrive
# Base Args: --monitor
# We are being verbose
# Adding --verbose
# Changing ownership permissions on /onedrive/data and /onedrive/conf to onedrive:onedrive
# Launching 'onedrive' as onedrive via gosu
Reading configuration file: /onedrive/conf/config
Configuration file successfully loaded
Using 'user' configuration path for application config and state data: /onedrive/conf

An application configuration change has been detected where a --resync is required

Unraid 6.12.13 (latest)
onedrive docker driveone/onedrive latest, Sep 19, 2024

The files:

-rw------- 1 1998 users        461 Sep 21 13:18 .config.backup
-rw------- 1 1998 nogroup       28 Sep 21 13:18 .config.hash
-rw-r--r-- 1 1998 users        461 Sep 21 13:41 config
-rw-r--r-- 1 1998 nogroup 36737024 Sep 21 13:41 items.sqlite3
-rw------- 1 1998 users        928 Sep 21 13:18 refresh_token

Anyone an idea?

[kobby-w]

And it seems that onedrive docker does change the config file itself after start:

Before start:

-rw------- 1 1997 users        358 Sep 21 13:25 .config.backup
-rw------- 1 1997 nogroup       28 Sep 21 13:25 .config.hash
-rw-r--r-- 1 1997 users        111 **Sep 21 13:59 config**
-rw-r--r-- 1 1997 nogroup    28672 Sep 21 13:25 items.sqlite3
-rw-r--r-- 1 1997 nogroup    32768 Sep 21 13:25 items.sqlite3-shm
-rw-r--r-- 1 1997 nogroup 16274032 Sep 21 14:22 items.sqlite3-wal
-rw------- 1 1997 users        928 Sep 21 13:25 refresh_token
-rw-r--r-- 1 1997 nogroup     1458 Sep 21 14:23 session_upload.2WStbYzhR0xQHpUw
-rw-r--r-- 1 1997 nogroup     1458 Sep 21 14:23 session_upload.6oOmZsewx3BVQNk5
-rw-r--r-- 1 1997 nogroup     1458 Sep 21 14:23 session_upload.hLEsbQDvjaHFc9Su

After start:

-rw------- 1 1997 users     111 Sep 21 14:24 .config.backup
-rw------- 1 1997 nogroup    28 Sep 21 14:24 .config.hash
-rw-r--r-- 1 1997 users     111 **Sep 21 14:24 config**
-rw-r--r-- 1 1997 nogroup 28672 Sep 21 14:24 items.sqlite3
-rw-r--r-- 1 1997 nogroup 32768 Sep 21 14:24 items.sqlite3-shm
-rw-r--r-- 1 1997 nogroup 24752 Sep 21 14:24 items.sqlite3-wal
-rw------- 1 1997 users     928 Sep 21 14:24 refresh_token

[abraunegg]

@kobby-w
I need to 100% correct your understanding here - the Docker container that is pulled from here: https://hub.docker.com/r/driveone/onedrive - does not - under any circumstance update, or write the config file.

If this is the behavior you are seeing - this will be due to the 'Unraid' Docker plugin or however the above container has been integrated to the unraid platform.

I suggest you do the following:

• Confirm the correct behavior on a system running Docker without using unraid or the unraid plugin (https://forums.unraid.net/topic/132486-guide-set-up-the-onedrive-client-for-linux-abraunegg-as-docker-container/)
• Raise a bug|support issue with the developers or unraid or the folk that did that integration

[kobby-w]

Hello @abraunegg :)

thank you very much for your fast answer. I made now a comment about this situation here:
https://forums.unraid.net/topic/133978-support-bversluis-onedrive/page/2/#comment-1467352

[altrnate32]

Hello, I have the exact same issue (since recovering from the timstamp issue) and don't use unraid (or at least not that I know).
I use Proxmox and run Docker in a Debian VM. Has been working flawless for years. Now suddenly the 'please resync loop'
I also see the timestamp of the config file change after start.

Before start:

-rw-r--r-- 1 onedrive onedrive      106 Sep 30 10:09 config
-rw------- 1 onedrive onedrive       12 Sep 30 10:09 .config.hash

After start:

-rw-r--r-- 1 onedrive onedrive      106 Sep 30 10:23 config
-rw------- 1 onedrive onedrive       12 Sep 30 10:09 .config.hash

I run the container using this compose file:

services:
  onedrive:
    container_name: onedrive
    hostname: onedrive
    image: driveone/onedrive:edge
    restart: unless-stopped
    environment:
      - ONEDRIVE_UID=1003
      - ONEDRIVE_GID=1003
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - onedrive_conf:/onedrive/conf
      - /mnt/onedrive_storage/onedrive:/onedrive/data

And to be complete:

Log output:

# Running container as user: onedrive
# Base Args: --monitor
# Changing ownership permissions on /onedrive/data and /onedrive/conf to onedrive:onedrive
# Launching 'onedrive' as onedrive via gosu
Reading configuration file: /onedrive/conf/config
Configuration file successfully loaded
Application configuration file has been updated, checking if --resync needed
An application configuration change has been detected where a --resync is required

Contents of config:

monitor_interval = "600"
download_only = "true"
cleanup_local_files = "true"
monitor_log_frequency = "24"

Contents of .config.backup:

monitor_interval = "600"
download_only = "true"
cleanup_local_files = "true"
monitor_log_frequency = "24"

[abraunegg]

@altrnate32

An application configuration change has been detected where a --resync is required

To determine what is tripping this up, run the Docker container in debug mode and this will advise what variable is causing this to trip.

I suspect it will be 'sync_dir' - as you are specifying /mnt/onedrive_storage/onedrive:/onedrive/data in your compose configuration which will be interpreted as --sync-dir '/mnt/onedrive_storage/onedrive' which is not the default of ~/OneDrive

To resolve this, you will most likely need to ensure you add:

sync_dir = "/mnt/onedrive_storage/onedrive/"

to your 'config' file

[altrnate32]

Thanks for your quick reply!
I have added the syncdir ("/onedrive/data" as Docker mounts /mnt/onedrive_storage/onedrive/ to /onedrive/data in the container) to the config file. And just done a resync.
Now after a restart the config file timestamp is not modified anymore, and the 'resync loop' has stopped.

So something was causing the config file to be touched on start. And adding the syncdir to the config solved this.
This is new behaviour as I have been using this setup and this config (without syncdir in the config file) for at least a year (probably two) without issues.

Thanks a lot for all the work you do on this client! I notice that I really depend on it :)

[abraunegg]

OK .. so at least the 'fix' is that ... I wonder if this is something unique to containers ....

I will see if I can reproduce this somehow

[cholzer79]

I suspect it will be 'sync_dir' - as you are specifying /mnt/onedrive_storage/onedrive:/onedrive/data in your compose configuration which will be interpreted as --sync-dir '/mnt/onedrive_storage/onedrive' which is not the default of ~/OneDrive

I faced the exact same issue and adding the path of the bind to the conf as you described fixes the issue! :)
The conf file is nolonger modified on container start/restart.

#2887

[abraunegg]

@altrnate32

I also see the timestamp of the config file change after start.

As for this item ... there is 100% zero code that writes to the config file ... the timestamp should not even updated or modified by 'onedrive' itself .... so something outside of the application is making that config timestamp change.

[altrnate32]

Maybe something in the docker container that errors when there is no syncdir specified?
For some reason with syncdir in the config file nothing happens. Without syncdir in the config the config file timestamp is updated on every start.

[cholzer79]

As for this item ... there is 100% zero code that writes to the config file ... the timestamp should not even updated or modified by 'onedrive' itself .... so something outside of the application is making that config timestamp change.

I see the exact same behaviour where on (re)start of the container the modification data of the conf file changes - until I add the host path of the data bind to the conf file as sync_dir like you suggested, which fixes the issue. :)

#2887

[abraunegg]

This is a regression from v2.5.0-alpha-4. Please read #2889 for resolution.

[abraunegg]

@kobby-w , @cholzer79 , @altrnate32
Have you looked at the PR #2889 to solve this regression yet ?

[altrnate32]

Yes for me it is fixed, have had no more issues. Thx!

…

On Sun, 13 Oct 2024, 20:20 abraunegg - notifications at github.com, < ***@***.***> wrote: @kobby-w <https://github.com/kobby-w> , @cholzer79 <https://github.com/cholzer79> , @altrnate32 <https://github.com/altrnate32> Have you looked at the PR #2889 <#2889> to solve this regression yet ? — Reply to this email directly, view it on GitHub <#2839 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVKCKOGMKQOGW5D2V4EWDJDZ3K2WNAVCNFSM6AAAAABOTQTYEOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAOJTGAYDAMA> . You are receiving this because you were mentioned.Message ID: ***@***.***>