cosmas

@abraunegg I understand what you mean, but there is anywhere a code, which alters the config file. Therefore onedrive docker thinks, there are changes made in the config file and asks for a resync. I checked it already many times. This behavior is new. To clarify it: - onedrive docker changes the time and date of the config file immediately after start/restart - but it does not change the content of the config file This is e.g. the content of a config file: monitor_interval = "86400" check_nosync = "true"" rate_limit = "9830400" download_only = "true" skip_dir = "NAS01_upload" skip_dir = "Anlagen" skip_dir = "Duplicati" skip_dir = "Synology_DS720plus_Uploads" Files while onedrive docker was running: drwxr-x--- 1 onedrive-download users 9 Sep 22 16:27 ./ drwxr-x--- 1 onedrive-download users 3 Sep 27 2023 ../ -rw------- 1 onedrive-download users 207 Sep 22 16:27 .config.backup -rw------- 1 onedrive-download users 28 Sep 22 16:27 .config.hash -rw-r----- 1 onedrive-download users 207 Sep 22 16:27 config -rw-r--r-- 1 onedrive-download users 39702528 Sep 22 16:42 items.sqlite3 -rw-r--r-- 1 onedrive-download users 32768 Sep 22 16:27 items.sqlite3-shm -rw-r--r-- 1 onedrive-download users 0 Sep 22 16:43 items.sqlite3-wal -rw------- 1 onedrive-download users 928 Sep 22 16:27 refresh_token Files after a restart of onedrive docker container on Sept. 23, at 11:14am: drwxr-x--- 1 onedrive-download users 7 Sep 23 11:14 ./ drwxr-x--- 1 onedrive-download users 3 Sep 27 2023 ../ -rw------- 1 onedrive-download users 207 Sep 22 16:27 .config.backup -rw------- 1 onedrive-download users 28 Sep 22 16:27 .config.hash -rw-r----- 1 onedrive-download users 207 Sep 23 11:14 config -rw-r--r-- 1 onedrive-download users 36794368 Sep 23 11:14 items.sqlite3 -rw------- 1 onedrive-download users 928 Sep 22 16:27 refresh_token

@abraunegg The thing is, that I run onedrive container on Unraid since more than 2 years now. And i run several other docker containers on my system. I tested already yesterday, but its clear: ondrive docker on Unraid changes the config file. I tested with 2 onedrive installations and both change the date/time of the config file. I tested with other docker containers and checked, if they change the config file, but the do not. Therefore I think its a problem with this docker image. And if you see above, other user have the same problem: @Cheeshead @bigrizz The files are located on 2 WD black NVME 4 TB drives in a mirrored cache group.

Try to use -e ONEDRIVE_RESYNC=1 as extra parameter. That works so far for me, but when disabled the --resync request is there again. Its a kind of loop and I can see that the container changes the config file itself as the date changes. Therefore onedrive thinks, that the config file was changed.

I have the same problem.

onedrive docker asking for --resync in endless loop 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 It seems that onedrive docker changes the config file itself: 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 I already asked this question on: https://github.com/abraunegg/onedrive/discussions/2839 and abraunegg answered me: Anyone an idea?

Hello, I had the same problem. I solved it this way: Unraid IP 192.168.1.20/16, GW 192.168.0.1 metric 1 VLAN IP 10.0.0.20/24, GW 10.0.0.1 metric 2

To change the machine type to "Q35-7.1" and the primary vdisk bus to "SATA" helped in my case. Windows 11 pro runs stable now.

This solution works for me. Mac time machine works now fine. Its doing all backups and I can find old backups. Furthermore I changed: SMB multichannel: yes Enhanced MacOS interoperability: yes

I am also trying to enter a extra configuration for SMB: [Global] vfs objects = fruit streams_xattr fruit:metadata = stream fruit:model = MacSamba fruit:posix_rename = yes fruit:veto_appledouble = no fruit:nfs_aces = no fruit:wipe_intentionally_left_blank_rfork = yes fruit:delete_empty_adfiles = yes [TimeMachineBackup] fruit:time machine = yes It is described here: https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X

Hello, I have the same problems. The timemachine stops making backups. The backups you can see are the backups on your local mac computer. If I try to write on the SMB share from my macbook, everything is fine. I am trying now to use a drive share instead of a user share, as described here: