Thanks for resolving. My backups run fine now 
Thanks for this quick fix! System running fine again.
cheers thanks for fixing it works i love you guys
Thank you for fixing it!
Hello,
I’m still having the exact same issue as the other people were describing here.
What must I do to apply the fix? Will this be pushed through the standard update pipeline? When can I expect the service to work again? I’m using Fedora 36
Welcome to the forum @meyou69
No. This issue was in the Internet-hosted Duplicati OAuth handler service.
It was caused by a June 12 change and fixed in a June 13 change above.
It also only affects OAuth-using storage types, where you have an AuthID.
This topic consolidates many reports that began on June 13, so is generic.
Please see the linked reports for description if you think you’re seeing this.
Also, give your specifics. As you see here, this fix solved numerous cases.
Never mind, I didn’t know I had to regenerate an AuthID for Google Drive AND copy paste the new AuthID to a different configuration page.
I just did this tonight and Duplicati finally works again. The two step process isn’t intuitive at all but at least I understand how it works now.
Thank you for your answer! My issue is solved now!
Still doesn’t work for me. Tried google drive, Dropbox, OneDrive. All fail in the exact same way—I get the oauth token, but the test option never succeeds. Any suggestions?
works for me (just now, with OneDrive V2)
Try harder.
Welcome to the forum @Ken_Getz
Please describe how that looks, for example the message seen.
Other ways to look for more information would need saving the job and doing one of the following.
Export As Command-line and use that URL for a Duplicati.CommandLine.BackendTool.exe list.
Have a tab at About → Show log → Live → Retry to watch job’s Verify files. Click useful lines.
Thanks. Working on it. Here’s what I see once I have finished the authentication:
I have Duplicati installed in a Docker container, if that matters.
After I click Test Connection, the dialog box appears for a long time (4 or 5 minutes) before displaying this alert:
Of course, I have tried what the dialog box suggests, with no more luck. I have tried this with Google Drive (limited), Google Drive (full), DropBox, and OneDrive. In each case, I can authenticate and retrieve a token, but the Test Connection button fails. And backups never run. Thanks.
Though behavior seems a little inconsistent NameResolutionFailure sounds like a DNS failure.
When you try what the box says, are you going to the URL there inside or outside of the Docker?
Does that host name resolve inside of Docker? I’m not sure what commands it has, but pick one.
Typical ones would be host or nslookup for just the address, but others, e.g. ping have lookups.
I did create the command line, but I don’t see any issues. I can’t run the command-line tools as I don’t have Duplicati installed in a Windows environment–it’s running in a Docker container, and I have only a Mac computer here. I’m wondering if there’s some sort of firewall issue that causes every backend to fail? I can authenticate in each of these, yet Duplicati cannot connect. Any suggestions appreciated.
From within the Docker image, at a command prompt, I typed:
ping https://duplicati-oauth-handler.appspot.com
The result is:
ping: bad port '//duplicati-oauth-handler.appspot.com'
When I try that same thing from outside the Docker container, I get:
ping: socket: Operation not permitted
Perhaps I’m doing the wrong thing? Sorry for being dense, but it wasn’t clear what URL you were suggesting that I ping. Thanks. – Ken
A URL is not a host name, and tools like ping deal with the host name. So just grab that portion and try:
ping duplicati-oauth-handler.appspot.com
Thanks. nslookup succeeds both from outside and inside the container.
Ping from outside the container requires me to run as root (sudo ping…) Ping inside the container does not. Both work fine with the duplicati URL.
I appreciate your efforts to help. Thanks. – Ken
Command line tools are typically available inside the Docker (whose is this?) by duplicati-cli.
This should be fun. I don’t have either Docker or Mac. Regardless, something seems bad in DNS.
It’s not totally clear which DNS query it was though, e.g. how OAuth server would report the issue.
EDIT:
In case the hint wasn’t clear, anyone with Docker OR Mac (ideally both) is welcome to join in here.
Thanks. Mac really isn’t an issue–the docker container is running on the Synology NAS (a DS718+ running DSM 7.1, for what it’s worth). The Mac is just the client I’m using to access it, so shouldn’t play any part in the puzzle.
I logged into the terminal in the Docker container for Duplicati, using this command from an SSH terminal (obviously, “duplicati” is the name of the container):
docker exec -it duplicati bash
Attempting to run duplicati-cli fails (command not found). Do I need to move to a specific directory? Thanks!
(mono is definitely available, however.)
On a Linux system, there are typically /usr/bin/duplicati* shortcuts that run mono to run Duplicati code.
This might be different in Docker, and multiple suppliers provide Duplicati Docker, which one is yours?
Regardless, you can try ps -ef | grep Duplicati to see if you can get the lines showing its folder.
Duplicati /usr/lib/duplicati/Duplicati.GUI.TrayIcon.exe
/usr/bin/mono-sgen /usr/lib/duplicati/Duplicati.GUI.TrayIcon.exe
In the folder you can do your own mono Duplicati.CommandLine.exe to replace the duplicati-cli script.
$ cat /usr/bin/duplicati-cli
#!/bin/bash
INSTALLDIR=/usr/lib/duplicati
export LD_LIBRARY_PATH="${INSTALLDIR}${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
export MONO_PATH=$MONO_PATH:${INSTALLDIR}
EXE_FILE=${INSTALLDIR}/Duplicati.CommandLine.exe
APP_NAME=Duplicati.CommandLine
exec -a "$APP_NAME" mono "$EXE_FILE" "$@"
$