Duplicati - Dropbox Backup - Short lived token expires

Hi all,

I’m using Duplicati for my backups currently and I want to change y destination from Gdrive to Dropbox.

However it turns out, that apprently the OAUTH from Duplicati to Dropbox is not implemented properly as it only returns a SL (short-lived) token that expires after a couple of hours.

I haven’t found a way to replace it with a proper token that doesn’t expire. There is no config option in Duplicati itself and I tried to create my own app via Dropbox App Console.

I can hardly imagine that this behaviour is as expected? It would basically mean that there is no one out there, using Duplicati + Dropbox?

Autorisation mit dem OAuth Service ist fehlgeschlagen: {“error_summary”: “expired_access_token/.”, “error”: {".tag": “expired_access_token”}}.

Version: Aktuell wird Duplicati - verwendet

Any help is much appreciated.


(feel free to reply in GER or ENG)


Welcome to the forum @revq


In the past, the Dropbox API used only long-lived access tokens.

might be part of the problem. I don’t have Dropbox to test with, but somehow other people are using it.


monthly stats by backend show a slight dropoff in Dropbox backups, like 71 thousand to 58 thousand.
Maybe the Dropbox change lets existing user access tokens stay long-lived, but new ones are short?
P.S. Looks that way

On September 30th, 2021, Dropbox will retire the creation of long-lived access tokens

You could help out by looking for.evidence (besides yours – thanks for the heads-up) that they did that.

My concern about the new Dropbox plan is this:

How we get along with OAuth explains the usual Duplicati processing, if refresh tokens can be obtained.

I don’t think you can get Duplicati to use it. It manages its own tokens, but Dropbox changed their OAuth.

Can any other Dropbox users report seeing the problem or not? If it works, are you an old user or a new?


I’m having this issue with Dropbox as well. It started a few days ago after I deleted and re-set-up my backup configuration in Duplicati. My guess is the new token I got is short-lived unlike the long-lived token I had previously.

I don’t know how the current Dropbox authentication works, but it looks like maybe Duplicati is storing and using the access token directly, instead of storing the refresh token and using that to fetch a new access token when running backups. If that’s the case, then hopefully this issue can be rectified by updating the authentication to use the refresh token flow described in the Duplicati oauth doc

Dropbox might also need this documented change, which I didn’t see any other OAuth service needing:

Note: you’ll need to include token_access_type=offline as a parameter on your Authorization URL in order to return a refresh_token inside your access token payload.

Are you able to open an Issue so that the developers can figure out how to handle this? It’s not often that oauth-handler project (separate from duplicati project) gets changes, and the language is different too…

Thanks for adding to the suspicion that the documented Dropbox change is the reason for this problem.
Can you try your old AuthID to see whether its old long-lived access token is still working and long-lived?


Refresh token is not returned from Dropbox API when using grant_type=refresh_token
clarifies when token_access_type=offline is needed. It’s not clear if it’s harmful if used at other times.

1 Like

Created an issue here https://github.com/duplicati/duplicati/issues/4667.

Unfortunately I don’t have the old AuthID anymore. I do have another computer with Duplicati without having its authentication reset and it’s still running Dropbox backups without any problems. As such I do think the issue is caused by the Dropbox access token change and people will probably start running into this problem when they generate new tokens for any reason.

1 Like

Is there any manual workaround known as of now?

Are you doing your first backup to rclone? If not, do you have an old backup to test that old AuthID?

If you followed good practice and safely preserved old Export To file, the AuthID is possibly in there.
AES Crypt or Duplicati’s included SharpAESCrypt.exe CLI command can decrypt the file if needed.

I suppose you could ask Dropbox support if they can set your account to old behavior for awhile…

Possible awkward workaround is to see if rclone can use Dropbox, then have Duplicati use rclone.

For rclone help, they also have a forum. I do see some varying posts about their Dropbox situation.

dropbox: support new oauth scheme #4792 looks like they at least tried to fix this before the cutoff.

Dropbox token expiring how to create non expiring token. is kind of unclear. Maybe title is off-target.

If you have other storage available, Duplicati destinations can be moved, then edit backup to use it.
Duplicati won’t do a location-to-location transfer, but there are other tools around that can be used.

1 Like

Thank you SO MUCH for reminding me the AuthID is in the exported config file. I swapped out the AuthID of the new backup task with the AuthID from the config file and all’s working again.


@uildvek @revq @ts678 I have updated the OAuth server to fit. This was caused by a change with Dropbox (they had announced the change) where they are now more compliant with the OAuth standard and returning refresh tokens.

In short, if you create a new AuthID it should not expire.


Hi, so what do we need to do to receive the fix? Is it going to be included in a new release?
I’m creating a new AuthID and it’s still expiring shortly (will work at the same time, but doesn’t last for my nightly backup to run)

1 Like

Welcome to the forum @serkef

The earlier thought above was that this could be done entirely server-side, with no Duplicati changes.
This turned out not to be the case, so a new release will be needed with details TBD, but last update:

This likely means the server change was removed until Duplicati change can be released. Tech detail.

Typically a leisurely fix rollout would turn into a Canary release, then Experimental, then finally a Beta.
This time, I’m wondering if it will be done as a hotfix to current Beta, but as I said, the details are TBD.

Meanwhile, the best bet for anyone who has a long lived token in an old job or job export is – use that.
An AuthID can be used for as many backups as you like (provided it’s on the right account, of course).


@ts678: has the fix been rolled out yet? If yes, in which release? Haven’t tried it since.

but there has not yet been a Beta with it. Try it if you dare run on Canary.


There are newer Canary too, and I haven’t heard issues from early users.
One never knows, because Canary is only tested by the automated tests.
Generally anyone using a Canary for important work shouldn’t go in early.

I can confirm that it works smoothly with the current Canary version.
Thanks for the fix!