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.
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?
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.
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.
@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)
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).