unable to re-auth

[Paruccone]

any clue on how to troubleshoot this?
onedrive --reauth executes correctly but despite that, this what I get in syslog after restart:

2025-11-11T00:46:17.105544+01:00 rpi systemd[3534]: Starting onedrive.service - OneDrive Client for Linux...
2025-11-11T00:46:17.112712+01:00 rpi (sh)[3550]: onedrive.service: ProtectHostname=yes is configured, but UTS namespace setup is prohibited (container manager?), ignoring namespace setup.
2025-11-11T00:46:46.880018+01:00 rpi systemd[3534]: Started onedrive.service - OneDrive Client for Linux.
2025-11-11T00:46:46.881120+01:00 rpi (onedrive)[3593]: onedrive.service: ProtectHostname=yes is configured, but UTS namespace setup is prohibited (container manager?), ignoring namespace setup.
2025-11-11T00:46:47.272325+01:00 rpi onedrive[3593]: Reading configuration file: /home/XXXX/.config/onedrive/config
2025-11-11T00:46:47.275597+01:00 rpi onedrive[3593]: Configuration file successfully loaded
2025-11-11T00:46:47.296079+01:00 rpi onedrive[3593]: WARNING: Configured 'threads = 8' exceeds available CPU cores (4).
2025-11-11T00:46:47.296212+01:00 rpi onedrive[3593]:          This may lead to reduced performance, CPU contention, and instability. For best results, set 'threads' no higher than the number of physical CPU cores.
2025-11-11T00:46:47.333725+01:00 rpi onedrive[3593]: WARNING: D-Bus message bus daemon is not available; GUI notifications are disabled
2025-11-11T00:46:47.337390+01:00 rpi onedrive[3593]: WARNING: Your cURL/libcurl version (7.88.1) has known HTTP/2 bugs that impact the use of this client.
2025-11-11T00:46:47.337717+01:00 rpi onedrive[3593]:          Please report this to your distribution, requesting an update to a newer cURL version, or consider upgrading it yourself for optimal stability.
2025-11-11T00:46:47.337792+01:00 rpi onedrive[3593]:          Downgrading all client operations to use HTTP/1.1 to ensure maximum operational stability.
2025-11-11T00:46:47.337839+01:00 rpi onedrive[3593]:          Please read https://github.com/abraunegg/onedrive/blob/master/docs/usage.md#compatibility-with-curl for more information.
2025-11-11T00:46:47.352793+01:00 rpi onedrive[3593]: Using IPv4 and IPv6 (if configured) for all network operations
2025-11-11T00:46:47.361853+01:00 rpi onedrive[3593]: Attempting to contact the Microsoft OneDrive Service
2025-11-11T00:46:47.659627+01:00 rpi onedrive[3593]: Successfully reached the Microsoft OneDrive Service
2025-11-11T00:46:47.871122+01:00 rpi onedrive[3593]: Configuring Global Azure AD Endpoints
2025-11-11T00:46:48.268125+01:00 rpi onedrive[3593]: AADSTS135011: Device used during the authentication is disabled. Trace ID: d4c977ec-10c5-42a8-8804-1803e0d50e00 Correlation ID: edb6b1bc-21ed-4c72-90ea-ee2fc2c9e75b Timestamp: 2025-11-10 23:46:48Z
2025-11-11T00:46:48.268394+01:00 rpi onedrive[3593]: ERROR: You will need to issue a --reauth and re-authorise this client to obtain a fresh auth token.

Thx

[abraunegg]

The key item is this:

AADSTS135011

Without knowing your application configuration, the device you are using to authenticate the client with is disabled by your organisation.

Contributing factors:

• your curl version - you must upgrade your curl version to something more modern

[Paruccone]

ok so let me be more specific: why does onedrive keep issuing this error even after successfully re-authenticating? (and after upgrading curl)

2025-11-11T15:33:02.506212+01:00 rpi systemd[3368]: Starting onedrive.service - OneDrive Client for Linux...
2025-11-11T15:33:48.006316+01:00 rpi systemd[3368]: Started onedrive.service - OneDrive Client for Linux.
2025-11-11T15:33:48.347019+01:00 rpi onedrive[3723]: Reading configuration file: /home/XXXXX/.config/onedrive/config
2025-11-11T15:33:48.352508+01:00 rpi onedrive[3723]: Configuration file successfully loaded
2025-11-11T15:33:48.367111+01:00 rpi onedrive[3723]: WARNING: Configured 'threads = 8' exceeds available CPU cores (4).
2025-11-11T15:33:48.367230+01:00 rpi onedrive[3723]:          This may lead to reduced performance, CPU contention, and instability. For best results, set 'threads' no higher than the number of physical CPU cores.
2025-11-11T15:33:48.372393+01:00 rpi onedrive[3723]: WARNING: D-Bus message bus daemon is not available; GUI notifications are disabled
2025-11-11T15:33:48.380714+01:00 rpi onedrive[3723]: Using IPv4 and IPv6 (if configured) for all network operations
2025-11-11T15:33:48.394125+01:00 rpi onedrive[3723]: Attempting to contact the Microsoft OneDrive Service
2025-11-11T15:33:48.607794+01:00 rpi onedrive[3723]: Successfully reached the Microsoft OneDrive Service
2025-11-11T15:33:48.758185+01:00 rpi onedrive[3723]: Configuring Global Azure AD Endpoints
2025-11-11T15:33:49.071582+01:00 rpi onedrive[3723]: AADSTS135011: Device used during the authentication is disabled. Trace ID: 5a666cce-dd36-40db-9845-e5a1a012a700 Correlation ID: 485e1279-dcbf-40bb-bad3-c12604103172 Timestamp: 2025-11-11 14:33:49Z
2025-11-11T15:33:49.071915+01:00 rpi onedrive[3723]: ERROR: You will need to issue a --reauth and re-authorise this client to obtain a fresh auth token.

[abraunegg]

@Paruccone

Let me be more specific:

1. Without knowing your application configuration, the device you are using to authenticate the client with is disabled by your organisation.
2. Are you performing the --reauth against the correct client instance?

When you setup your 'onedrive' client, are you using the --confdir option (https://github.com/abraunegg/onedrive/blob/master/docs/application-config-options.md#cli-option---confdir) at all?

If you are using --confdir when you perform the --reauth you must also specify the correct configuration directory for the reauth process.

When you perform the --reauth are you stopping the correct systemd service to allow the systemd service to pickup the new auth token?

Understanding the authentication | re-authentication flow

1. The client will present you a URL to visit
2. You visit that URL in a browser, login using your credentials, and the browser will redirect to a blank page, and you copy the changed URI back to the application
3. The application then extracts the refresh token from that URL and saves it in the 'refresh_token' file.
4. When the application next executes it reads the 'refresh_token' as provided.

Please refer to https://github.com/abraunegg/onedrive/blob/master/docs/client-architecture.md for more details.

Your issue

The system where you are performing step 2 from has been disabled by your organisation. This is why you are getting the AADSTS135011.

This is nothing that can be solved here. Please speak to your Azure AD Administrators.

[Paruccone]

Sorry for not providing the details previously: this is not a new setup.
My client was working, I was simply running some maintenance to update packages, noticed a message mentioning a new version was available (I went from 2.5.5 to 2.5.9). The issue didn't appear with the update but was already present.
Most probably I deleted some old machines from my tenant which would explain the problem appearing.
What I've done:

1. updated from 2.5.5 to 2.5.9
2. updated from debian 12 to debian 13 to fix the curl message
3. onedrive reauth, copied the string to the browser in a windows machine that is correctly working and registered with the tenant
4. pasted the post-auth string to onedrive
5. restarted

now, let's assume I deleted from the tenant the machine in which months ago I've done the auth, shouldn't the new auth be linked to the machine I've pasted the link on? If possible I'd like to avoid starting from scratch as I have a VDSL with 32mbps downstream and it would take a while to sync again.

[abraunegg]

You do not have to start from scratch with syncing.

now, let's assume I deleted from the tenant the machine in which months ago I've done the auth, shouldn't the new auth be linked to the machine I've pasted the link on?

Azure AD is very funny / fickle.

You need to look through your Azure AD configuration and see what it thinks your machine states are.

This is nothing that can be solved here ... nothing has changed in the authentication process stream, that specific response is coming back from the Microsoft Graph API that your token was generated on a machine that has been disabled .....

Please research the AADSTS135011 code and research how to resolve, or, as you have Azure AD - most likely paid Microsoft support - raise a bug report / incident ticket with Microsoft for resolution.

Example:

https://www.google.com/search?q=how+to+fix+AADSTS135011&oq=how+to+fix+AADSTS135011&gs_lcrp=EgZjaHJvbWUyBggAEEUYOdIBCDIwMDFqMGo3qAIIsAIB&sourceid=chrome&ie=UTF-8

[Paruccone]

oh thanks! I didn't get that the AD was a code coming from Microsoft! I don't have proper support, I am a single user having a tenant as developer. Not expecting to get help on this but sharing in case this can help others.
I was able to find these under enrta->devices->audit logs:

My only question related to the onedrive is: what makes the auth string be linked to a specific client?
My assumption is that it depends on the client to which I paste the auth link but seems to be a wrong assumption ;)

Plus I find it trivial that the onedrive client states "The application has been successfully authorised, but no extra command options have been specified."

[abraunegg]

Plus I find it trivial that the onedrive client states "The application has been successfully authorised, but no extra command options have been specified."

Because the client received a valid authentication URL (what you pasted) and successfully extracted the access token from that URL.

To the application, that this point - it has been authorised for use ....

[abraunegg]

My only question related to the onedrive is: what makes the auth string be linked to a specific client?

There is nothing in the 'onedrive' application that is tied to your authentication string.

You have the 'application identifier' that you 'approve' to access your data with. What you have is an access token that can then be used with the approved application to access your data.

The problem you have is - the system that you are generating that access token with is disabled in your Azure AD environment.

I would remove all devices and re-add them manually - as per all the help articles on Microsoft regarding this problem suggest.

[Paruccone]

so I went through the disabled devices and enbaled them one by one and restarted the service until I found the right one:

2025-11-11T20:02:50.181479+01:00 rpi onedrive[3739]: Configuring Global Azure AD Endpoints
2025-11-11T20:02:51.393501+01:00 rpi onedrive[3739]: Attempting to enable WebSocket support to monitor Microsoft Graph API changes in near real-time.
2025-11-11T20:02:51.860349+01:00 rpi onedrive[3739]: Enabled WebSocket support to monitor Microsoft Graph API changes in near real-time.
2025-11-11T20:02:51.860742+01:00 rpi onedrive[3739]: OneDrive synchronisation interval (seconds): 300
2025-11-11T20:02:51.860966+01:00 rpi onedrive[3739]: Initialising filesystem inotify monitoring ...
2025-11-11T20:02:54.213347+01:00 rpi onedrive[3739]: Performing initial synchronisation to ensure consistent local state ...
2025-11-11T20:02:54.213700+01:00 rpi onedrive[3739]: Attempting to contact the Microsoft OneDrive Service
2025-11-11T20:02:54.392997+01:00 rpi onedrive[3739]: Successfully reached the Microsoft OneDrive Service
2025-11-11T20:02:54.399589+01:00 rpi onedrive[3739]: Starting a sync with Microsoft OneDrive

It is a mistery to me how the onedrive installation is linked to a device that hasn't been existing/connecting for months.

Thanks for the help!

[abraunegg]

Will be a question for Microsoft

Please also do not close discussions, and use 3 x backticks for code / application output blocks