OneDrive does no more sync

[CoSoCo]

Hi,
can someone explain the following messages:

     Loaded: loaded (/usr/lib/systemd/user/onedrive.service; enabled; preset: enabled)
    Drop-In: /home/praxis/.config/systemd/user/onedrive.service.d
             └─override.conf
     Active: active (running) since Wed 2026-01-07 11:01:32 CET; 6h ago
       Docs: https://github.com/abraunegg/onedrive
    Process: 1656 ExecStartPre=/bin/sh -c sleep 15 (code=exited, status=0/SUCCESS)
   Main PID: 2638 (onedrive)
      Tasks: 18 (limit: 4345)
     Memory: 223.0M (peak: 607.5M swap: 85.8M swap peak: 86.8M)
        CPU: 32min 28.039s
     CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/onedrive.service
             └─2638 /usr/bin/onedrive --monitor

Jan 07 16:59:32 T540p onedrive[2638]: Retrying the respective Microsoft Graph API call for Internal Thread ID: OZpkcVzKaJg4R6Db (Timestamp: 2026-Jan-07 16:59:32) ...
Jan 07 16:59:32 T540p onedrive[2638]: ERROR: Encountered a std.net.curl.CurlException:
Jan 07 16:59:32 T540p onedrive[2638]:   Error Message:    Send failed since rewinding of the data stream failed on handle 5FF985D34600
Jan 07 16:59:32 T540p onedrive[2638]:   Calling Function: onedrive.OneDriveApi.acquireToken
Jan 07 16:59:32 T540p onedrive[2638]:   Line number:      1242
Jan 07 17:01:32 T540p onedrive[2638]: Retrying the respective Microsoft Graph API call for Internal Thread ID: OZpkcVzKaJg4R6Db (Timestamp: 2026-Jan-07 17:01:32) ...
Jan 07 17:01:32 T540p onedrive[2638]: ERROR: Encountered a std.net.curl.CurlException:
Jan 07 17:01:32 T540p onedrive[2638]:   Error Message:    Send failed since rewinding of the data stream failed on handle 5FF985D34600
Jan 07 17:01:32 T540p onedrive[2638]:   Calling Function: onedrive.OneDriveApi.acquireToken
Jan 07 17:01:32 T540p onedrive[2638]:   Line number:      1242
~

How can this be fixed?

[abraunegg]

@CoSoCo

can someone explain the following messages:

Your 'curl' version is unable to internally process what it needs to process - data streams are failing. This is a 'curl' version issue.

How can this be fixed?

Please follow the Basic Troubleshooting Steps as per https://github.com/abraunegg/onedrive?tab=readme-ov-file#basic-troubleshooting-steps

You have most likely a broken curl version. Please ensure you:

• Configure the client to use IPv4 only and HTTP/1.1
• Use 'curl' and 'libcurl' 8.14.1 as a minimum. If you are using something newer try and downgrade to this known good version.

If this resolves your issue, raise a bug against 'curl' for the Send failed since rewinding of the data stream failed on handle problem for the 'curl' version you were using as that explicit message is generated from 'curl' .. and not this client.

[CoSoCo]

Please follow the Basic Troubleshooting Steps as per https://github.com/abraunegg/onedrive?tab=readme-ov-file#basic-troubleshooting-steps

Much thanks for your hint.

You have most likely a broken curl version. Please ensure you:

* Configure the client to use IPv4 only and HTTP/1.1

The machine was configured as follows 5 months ago and worked fine for some time (I don't remember, why sync_dir was commented out) :

$ cat .config/onedrive/config
# sync_dir = "/mnt/Daten/Users/Praxis/OneDrive"
classify_as_big_delete = "100"
check_nomount = "true"
check_nosync = "true"

$ ls -ld OneDrive
lrwxrwxrwx 1 praxis praxis 32 Jul 25 14:44 OneDrive -> /mnt/Daten/Users/Praxis/OneDrive

$ mount | grep "/mnt/Daten"
/dev/sda7 on /mnt/Daten type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096)

Now I have added:

# sync_dir = "/mnt/Daten/Users/Praxis/OneDrive"
classify_as_big_delete = "100"
check_nomount = "true"
check_nosync = "true"
ip_protocol_version = "1"
force_http_11 = "true"

This seems to help.

* Use 'curl' and 'libcurl' 8.14.1 as a minimum. If you are using something _newer_ try and _downgrade_ to this known good version.

I think, the versions are still correct:

praxis@T540p:~$ apt list onedrive
Auflistung… Fertig
onedrive/unbekannt,now 2.5.9-1+np1+1.1 amd64  [installiert]
onedrive/unbekannt 2.5.9-1+np1+1.1 arm64
onedrive/unbekannt 2.5.9-1+np1+1.1 armhf
praxis@T540p:~$ apt policy onedrive
onedrive:
  Installiert:           2.5.9-1+np1+1.1
  Installationskandidat: 2.5.9-1+np1+1.1
  Versionstabelle:
 *** 2.5.9-1+np1+1.1 500
        500 https://download.opensuse.org/repositories/home:/npreining:/debian-ubuntu-onedrive/xUbuntu_24.04 ./ Packages
        100 /var/lib/dpkg/status
     2.4.25-1build5 500
        500 http://de.archive.ubuntu.com/ubuntu noble/universe amd64 Packages
praxis@T540p:~$ apt list curl
Auflistung… Fertig
curl/noble-updates,noble-security,now 8.5.0-2ubuntu10.6 amd64  [installiert]
curl/noble-updates,noble-security 8.5.0-2ubuntu10.6 i386
praxis@T540p:~$ curl --version
curl 8.14.1 (x86_64-pc-linux-gnu) libcurl/8.14.1 OpenSSL/3.0.13 zlib/1.3 brotli/1.1.0 libpsl/0.21.2 nghttp2/1.59.0
Release-Date: 2025-06-04
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM PSL SSL threadsafe TLS-SRP UnixSockets

[abraunegg]

@CoSoCo

If this message is occurring post resuming from sleep / hibernation,

potentially need to investigate the following: systemd “system-sleep” hook

systemd “system-sleep” hook
A systemd-suspend.service runs executables in /usr/lib/systemd/system-sleep/ supporting 2 arguments for suspend, hibernate etc.

What you will need to develop is a script, that restarts the systemd service you have enabled, so when you are sleeping your laptop or waking your laptop, you 'stop' the applicable 'onedrive' system service, then when you wake/resume, you start the 'onedrive' service.

This way on system resume, the service is restarted, clearing any stale curl status.

[CoSoCo]

This is interesting.
It could explain why first I saw the service inactive at the start of my investigation.

It could also explain why I saw a couple of backup folders with partly incomplete content like:

/mnt/Daten/Users/Praxis/OneDrive/Documents/Rechnungen-T540p-safeBackup-0001/Rech2018
/mnt/Daten/Users/Praxis/OneDrive/Documents/Rechnungen-T540p-safeBackup-0001-T540p-safeBackup-0001/Rech2018
/mnt/Daten/Users/Praxis/OneDrive/Documents/Rechnungen-T540p-safeBackup-0001-T540p-safeBackup-0001-T540p-safeBackup-0001
... and more

and the original folder Rechnungen only contained the last new files and folders.
I could recover all files and folders in Rechnungen manually again and delete the superfluous backup folders except one:

/mnt/Daten/Users/Praxis/OneDrive/Documents/Rechnungen-T540p-safeBackup-0001

I can delete it by browser access in the OneDrive cloud, but this doesn't remove it locally. Instead after few minutes in appears again remotely. Something weird happens here, see also: https://forum.ubuntuusers.de/topic/kann-verzeichnis-nicht-loeschen-2 (please use translater, if you don't understand german).

But the user says, that he never used hibernate or suspend, he always starts the machine from power off. He also says, that he never closed the lid while the machine was running. But who knows, maybe it happened by accident a few times in the last 5 months.

$ systemd “system-sleep” hook
Excess arguments.

Did you mean the above as valid command?

How could such script look like?
Would it be possible to include it in the binaries and DEB package of OneDrive, as I guess, it could be useful for plenty users,

[abraunegg]

@CoSoCo

/mnt/Daten/Users/Praxis/OneDrive/Documents/Rechnungen-T540p-safeBackup-0001-T540p-safeBackup-0001-T540p-safeBackup-0001

This is because you are running an older client version. This was fixed in release v2.5.8. Either you are running and old client version or you have not cleaned up your data.

I can delete it by browser access in the OneDrive cloud, but this doesn't remove it locally. Instead after few minutes in appears again remotely.

This indicates your have potentially 2 client binaries running, with 2 configurations and the client is uploading data that it things should exist.

Did you mean the above as valid command?

systemd-suspend.service runs executables in /usr/lib/systemd/system-sleep/

You need to create the folder /usr/lib/systemd/system-sleep/ if this does not exist.

You then need to create a script, make it executable, and put it in that location. For example:

#!/bin/sh
# $1 = pre|post, $2 = suspend|hibernate|hybrid-sleep|suspend-then-hibernate

case "$1" in
  post)
    # If onedrive is a *system* service
    #
    # or change this to the actual service that has been created
    /usr/bin/systemctl restart onedrive.service  
    ;;
esac

[CoSoCo]

This is because you are running an older client version.

I guess you meant, I was running an older client. Currently I use 2.5.9-1+np1+1.1.

... or you have not cleaned up your data.

What is meant by that?

This indicates your have potentially 2 client binaries running, with 2 configurations and the client is uploading data that it things should exist.

I don't think so and I only have 1 configuration: ~/.config/onedrive/config

Do you have an idea, why I can't delete the relics of that problem? See: https://forum.ubuntuusers.de/topic/kann-verzeichnis-nicht-loeschen-2 (please use translator, if you don't understand german).

[abraunegg]

@CoSoCo

See: https://forum.ubuntuusers.de/topic/kann-verzeichnis-nicht-loeschen-2 (please use translator, if you don't understand german).
......
Because in case of emergency, the files should also be usable from Windows.
.....

So this is all new information.

You should not be writing Microsoft OneDrive data using this client to a Microsoft NTFS partition .. that is going to cause you issues and grief.

Your choice of distribution - Ubuntu - compounds this because of the lethargic packaging policies that Ubuntu use. This makes you then use older software all over the place that have bugs that are fixed elsewhere.

I have advised you before to use a better distribution - you must consider it and avoid using a poor quality distribution such as Ubuntu.

Now .. to reliably access any Windows partition, you must use a very specific version of 'ntfs-3g' that includes enhancements to understand the Windows Microsoft OneDrive folder structure and file formats.

You must install and use this specific version of 'ntfs-3g' on your platform: https://github.com/gbrielgustavo/ntfs-3g-onedrive

If you have issues, you must seek support from the 'ntfs-3g' project: https://github.com/tuxera/ntfs-3g

This is all explained here: https://github.com/abraunegg/onedrive/blob/master/docs/advanced-usage.md#accessing-windows-onedrive-files-from-linux-dual-boot-setup

Do you have an idea, why I can't delete the relics of that problem?

Option 1: Unmount and fix

IMPORTANT: First stop all 'onedrive' binary from running otherwise you will not be able to unmount the device. Disable any 'onedrive' systemd service.

IMPORTANT: Ensure you are using the 'ntfs-3g-onedrive' component.

sudo umount /dev/sda7
sudo ntfsfix /dev/sda7
sudo mount -t ntfs-3g /dev/sda7 /mnt/Daten 
sudo rm -rf "/mnt/Daten/Users/Praxis/OneDrive/Documents/Rechnungen-T540p-safeBackup-0001"

Please adjust the commands for the folders / device names / mount point if not correct

Option 2: Remove from Windows

1. Shutdown Linux, and boot into Microsoft Windows
2. Then run from a command prompt:

powercfg /h off
chkdsk X: /f

3. Delete the offending folder from Microsoft Windows
4. Once removed, shutdown Microsoft Windows and boot back into Linux

[CoSoCo]

I could remove the relics from Windows side.
Now, when the user reboots back into Linux, the OneDrive service does no more start automatically. How can I fix this?

This evening I again will have remote access via AnyDesk. Then I will see if all is ok also from Linux side. This is also the chance to install the suggested 'ntfs-3g-onedrive' plugin.

[abraunegg]

Now, when the user reboots back into Linux, the OneDrive service does no more start automatically. How can I fix this?

You can fix this by reversing the steps you took to disable it.

Please read the documentation to assist you.

[CoSoCo]

In the mean time ...

Now I have remote access again to this machine via AnyDesk. I can see, that the suggested 'ntfs-3g-onedrive' plugin is already installed since 5 months.

Now, when the user reboots back into Linux, the OneDrive service does no more start automatically. I see:

$ systemctl --user status onedrive.service
○ onedrive.service - OneDrive Client for Linux
     Loaded: loaded (/usr/lib/systemd/user/onedrive.service; enabled; preset: enabled)
    Drop-In: /home/praxis/.config/systemd/user/onedrive.service.d
             └─override.conf
     Active: inactive (dead) since Mon 2026-01-19 19:51:35 CET; 5min ago
   Duration: 5.032s
       Docs: https://github.com/abraunegg/onedrive
    Process: 11200 ExecStartPre=/bin/sh -c sleep 15 (code=exited, status=0/SUCCESS)
    Process: 11206 ExecStart=/usr/bin/onedrive --monitor (code=exited, status=0/SUCCESS)
   Main PID: 11206 (code=exited, status=0/SUCCESS)
        CPU: 1.007s

Jan 19 19:51:33 T540p onedrive[11206]: Enabled WebSocket support to monitor Microsoft Graph API changes in near real-time.
Jan 19 19:51:33 T540p onedrive[11206]: OneDrive synchronisation interval (seconds): 300
Jan 19 19:51:33 T540p onedrive[11206]: Initialising filesystem inotify monitoring ...
Jan 19 19:51:34 T540p onedrive[11206]: Performing initial synchronisation to ensure consistent local state ...
Jan 19 19:51:34 T540p onedrive[11206]: Attempting to contact the Microsoft OneDrive Service
Jan 19 19:51:34 T540p onedrive[11206]: Successfully reached the Microsoft OneDrive Service
Jan 19 19:51:34 T540p onedrive[11206]: Starting a sync with Microsoft OneDrive
Jan 19 19:51:35 T540p onedrive[11206]: Fetching items from the OneDrive API for Drive ID: 6496f80a07782055 ..Attempting to perform a database vacuum to optimise database
Jan 19 19:51:35 T540p onedrive[11206]: Database vacuum is complete
Jan 19 19:51:35 T540p systemd[1538]: onedrive.service: Consumed 1.007s CPU time.

And after running

systemctl --user start onedrive.service

the service is still inactive, but the status output has new current timestamps.
How can I fix this?

Also I can see, that a new local file was not uploaded, even with manual onedrive --sync additionally.

$ ls -al "OneDrive/Documents/Rechnungen/Rechnungen 2026/"003.odt
-rwx------ 1 praxis praxis 18390 Jan 19 17:07 'OneDrive/Documents/Rechnungen/Rechnungen 2026/003.odt'

I don't see this new file in the OneDrive cloud via browser access.

This is the first time, OneDrive does nothing, but also doesn't create annoying backups.

So I ran:

$ onedrive --sync --resync
Reading configuration file: /home/praxis/.config/onedrive/config
Configuration file successfully loaded

WARNING: Configured 'threads = 8' exceeds available CPU cores (4).
         This may lead to reduced performance, CPU contention, and instability. For best results, set 'threads' no higher than the number of physical CPU cores.

D-Bus message bus daemon is available; GUI notifications are now enabled

The usage of --resync will delete your local 'onedrive' client state, thus no record of your current 'sync status' will exist.
This has the potential to overwrite local versions of files with perhaps older versions of documents downloaded from OneDrive, resulting in local data loss.
If in doubt, backup your local data before using --resync

Are you sure you wish to proceed with --resync? [Y/N] y

Deleting the saved application sync status ...
Forcing client to use IPv4 connections only
Attempting to contact the Microsoft OneDrive Service
Successfully reached the Microsoft OneDrive Service
Configuring Global Azure AD Endpoints
Fetching items from the OneDrive API for Drive ID: 6496f80a07782055 ............................ 
Processing 10765 applicable JSON items received from Microsoft OneDrive ......... 
Number of items to download from Microsoft OneDrive: 1
Downloading file: ./Personal Vault-T540p-safeBackup-0001.lnk ... done
Syncing this OneDrive Personal Shared Folder: ./Auswahl
Generating a /delta response from the OneDrive API for this Drive ID: 686f16b6fec63819 and Item ID: 686F16B6FEC63819!768900 . 
Finished processing self generated /delta JSON response from the OneDrive API
Processing 29 applicable JSON items received from Microsoft OneDrive .. 
Performing a database consistency and integrity check on locally stored data ..... 
Scanning the local file system '~/OneDrive' for new data to upload ... 
New directories to create on Microsoft OneDrive: 1
New items to upload to Microsoft OneDrive: 2
Uploading new file: ./Personal Vault-T540p-safeBackup-0002.lnk ... done
Uploading new file: ./Documents/Rechnungen/Rechnungen 2026/003.odt ... done
Performing a last examination of the most recent online data within Microsoft OneDrive to complete the reconciliation process
Fetching items from the OneDrive API for Drive ID: 6496f80a07782055 .. 
Processing 5 applicable JSON items received from Microsoft OneDrive . 
Syncing this OneDrive Personal Shared Folder: ./Auswahl
Generating a /delta response from the OneDrive API for this Drive ID: 686f16b6fec63819 and Item ID: 686F16B6FEC63819!768900 . 
Finished processing self generated /delta JSON response from the OneDrive API
Processing 29 applicable JSON items received from Microsoft OneDrive .. 

Sync with Microsoft OneDrive is complete
Attempting to perform a database vacuum to optimise database
Database vacuum is complete

Now the missing file was uploaded. Fine!
No annoying backups were created. Fine!
.... except ./Personal Vault-T540p-safeBackup-0002.lnk. I don't understand why this happens, now I see in the OneDrive cloud:

./Personal Vault        (folder with gray icon instead yellow)
./Personal Vault-T540p-safeBackup-0001.lnk
./Personal Vault-T540p-safeBackup-0002.lnk
./Persönlicher Tresor.lnk

Locally the gray coloured folder ./Personal Vault doesn't appear, but it's backups.

Fortunately the onedrive.service now keeps running after:

systemctl --user start onedrive.service

The --resync action seems to have fixed the situation.
I also have deleted the ./Personal Vault backups.
Hopefully now all is running right next days.

[CoSoCo]

You can fix this by reversing the steps you took to disable it.

I don't see with what action I could have disabled the automatic start of onedrive.service.
So what is to reverse?

Please read the documentation to assist you.

I already had searched in the documentation, how to automatically start the onedrive.service after reboot. Unfortunately I didn't find the right record. Can you give me a hint?

As you can see in my last post, the situation seems fixed now. Hopefully the onedrive.service starts automatically on next reboot.

Should I now remove the following settings again from the configuration?

ip_protocol_version = "1"
force_http_11 = "true"

Anyway: Big thanks for your patience and the extensive instructions.

[CoSoCo]

After a reboot today all now works fine.
Thanks for your great work.