Thanks, i was using the latest tag on docker but looks was not updated enought on the official image neither on the linuxserver managed image
i’ve used the canary image tagged and the new oauth token format looks is accepted
duplicati/duplicati:2.0.6.102_canary_2022-04-06 so seems we just need to wait until the latest image get updated
Nice information. It looks like for Duplicati Docker build, latest matches beta, and canary is a Canary which is sort of an unknown – first public view complete with the new code, with anything that got worse. Please report any breakages so that they can hopefully be addressed before the problem affects others.
Settings in Duplicati explains the channels concept, but it doesn’t fit Docker well because the containers typically get replaced with an updated container rather than letting Duplicati’s autoupdater update an old container to a new Duplicati content. If you see an offer for update, try grabbing a new container instead.
Eventually (I hope), there will be another Beta release after Canary proves itself, and settles down some. There is also a need for Duplicati volunteers (who allow Duplicati to exist) for code, test, documentation, forum – and making releases. There is a release manager needed now. Lack of one makes plans vague.
surely i can say is that settings looks are lost and i’ve not found where is the location to persist settings…
i’ve mounted the settings volume in the same /config dir on the container but going to the webui it will ask again for a first config (if is a local machine or a shared one and i want to set the password…)
It’s documented at https://hub.docker.com/r/duplicati/duplicati under “Preserving configuration”
https://hub.docker.com/r/linuxserver/duplicati has similar directions. Which Docker are you on?
Do you see any databases in the host volume? The settings would be in Duplicati-server.sqlite.
There are generally random-named job databases there too. I don’t use Docker myself though.
Any Docker experts out there, feel free to join in.
looks like the issue was that the linuxserver image was storing in the root of the volume while the official image (or more probably the canary) in the /Duplicati folder (so /data/Duplicati)
for now i’ve just reconfigured, idk if can be a future issue for the official docker image,
I’ve had the same problem, this post also helpful for me.
Hi All!
Today I installed Duplicati (on Ubuntu 16.04 LTS) intended for backup on Dropbox and immideately ran in to the OAuth 2 connection error discussed here.
I followed install instructions from “Installation - Duplicati 2 User's Manual” which led me to take the URL from “https://www.duplicati.com/download” to install the package. This gave me version “2.0.6.3_beta_2021-06-17” which is definitely not the correct version to mitigate the issue (as I take from the discussion).
What is the correct version to get a working Dropbox connection and how to upgrade/install?
Regards!
========================
Update. I figured-out where to download the canary 103 version and successfully installed this. A test backup on dropbox is running as we speak. This version, however, gave me an “internal server error” on testing the connection. Is this a problem?
And this is a production environment. Given the warnings about canary versions I would feel a bit more comfortable with a regular version. What version could I use, or is this version considered ‘stable’?
Regards, Menno.
I remember dimly having seen a backend where this happened, connection test was not working but backup yes. Could be Dropbox but I don’t remember (don’t use Dropbox). So it could be a normal error I guess 
a beta version is the equivalent of a stable version for a more usually versioned project (Duplicati 2 is in beta since the polished byte age). Betas come roughly yearly (this year it’s a bit late).
canary is the equivalent of unstable. Basically it’s the result of a bunch of contributions, merged and passing the unit tests. It sure has more potential for nasty regressions.
That can mean varied things. Don’t bet your business on any one backup. Run two, one offsite.
Need for long-term archiving (versus short term recovery) might also guide your stability needs.
Yep. If it’s a Canary, it’s for users who pick the new features and fixes, along with any new bugs.
You can get some sense of whether anything bad escaped by watching releases category notes.
You can browse Canary history there. The current one is a month and a half old and seems well.
Other times, you will see a succession of faster respins. A better chronological view is in GitHub.
is the typical Test connection, just a file list as a basic sanity check to see if destination works.
There are usually list operations done before and after backups, so I don’t know why button fails.
Possibly you’ll discover patterns, or if you want to hunt, Export As Command-line and test a URL.
Just checking in on this issue - I’ve been running Canary via the linuxserver.io docker image, solely because it addresses this Dropbox issue, but I’m keen to revert to a beta/latest build when possible once it incorporates this fix. I tried the linuxserver duplicati container just now, and I’m still getting the issue. Is there any rough idea of timeline as to when this fix might be incorporated into the beta/latest release? Thanks.
Welcome to the forum @NeeWii
None that I know. The person who does them has no time. We’ll see if some comes unexpectedly.
Jottacloud Error 401 (Unauthorized) was a post on this 7 days ago. They don’t even have Canary.
Beta is just a Canary that’s been around long enough that it seems OK. Experimental has been to demonstrate that infrequent updates (e.g. by autoupdater) work. After that, same code turns Beta.
It reduces risks of Canary breakage hurting you, but you can avoid that by seeing how it does first.
What would be good for Dropbox users would be for current Canary to go Experimental then Beta.
Jottacloud users might prefer a newer Canary first. Their fix is committed already but in no release officially released. They’re one of several groups using unofficial builds from community volunteers.
Perhaps the right person from the community will step into more official development/release work.
I’m getting error Message: “Failed to connect: Non-json response: Error in call to API function “files/list_folder”: The given OAuth 2 access token is malformed.”
When trying to set up Dropbox backup, I don’t have a backup of older version that worked
Hello together!
I also get the following error when trying to connect Dropbox:
Failed to connect: Non-json response: Error in call to API function “files/list_folder”: The given OAuth 2 access token is malformed
Could it be, that Duplicati is actually generating an OAuth1 token and using it like an OAuth2 token? The generated token from Duplicati looks like this:
xxxxx:xxxxx
An OAuth2 token generated on Dropbox API Explorer looks like this:
sl.xxxxxx
If needed, I can provide additional information. I hope someone can help me
Welcome to the forum @Icephoenix
Which Duplicati release? You can read the About screen for the number and date of release.
This recent fix is not in the old Beta, but is in the Canary test releases from 2.0.6.102 and on.
Canary releases have the latest fixes and possibly any latest breakages, so be careful with it.
Thank you for your quick reply! The bug seems to be fixed in the latest canary release! As it is already a few months old, I think the basic features should be stable.
2.0.6.104 seems quite good. The risk is what might break in a future one. Maybe wait and watch awhile, unless system is unimportant enough that a backup problem wouldn’t cause any great hardships to you.