Failed to connect: Error: TrustFailure (Authentication failed, see inner exception.)

getting the following error on ubuntu 20.04 Duplicati when setting up a backup destination to backblaze b2 storage. Failed to connect: Error: TrustFailure (Authentication failed, see inner exception.)

I have done the following: Removed Duplicati and mono and reinstalled and still getting the same error.

See this thread:

I’ve got the same problem. Has anyone found a solution?

Thanks.

Exactly the same as below? A fix can be operating-system specific. Destination might matter less though.

If your system is truly the same, let’s ask @Patrick_Domingues to see if there is an update on solution.

A System.Net.WebException: Error: TrustFailure error occurs has a certmgr line that may help diagnosis.
Make sure your system is up to date on its software updates. I had thought that Ubuntu had fixed this one.

Ubuntu
ca-certificates package
Distrust "DST Root CA X3"

I have the exact same problem; using Duplicati in Docker and has, unknowingly, received the same TrustFailure as @Patrick_Domingues Does anyone know of a solution?

The short answer is to delete a certain certificate from the docker container, per this post here: Http send report errors / duplicati-monitoring - #16 by hairlesshobo

Basically delete this file:

/usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt

And the run:

update-ca-certificates

Presumably the next release of the official Duplicati docker image will not require this extra step.

2 Likes

Thanks! A little more reading in the linked forum post lead me to update the certificates via (apt install) ca-certificates, which then appears to have updated the needed certs automatically. Great!
Now, however, I get a 401 - unauthorized back instead. Even updating the application key from Backblaze gives the same error. Since it was not a problem before I guess it is related. Any ideas on why this happens?

Interesting, I’m not sure if it’s related or just coincidental. What happens when you “edit” the backup job, go to the Destination page, and click the Test Connection button? Same error?

Yes, same error unfortunately.

Did you restart the Duplicati container? I don’t remember if that’s required after updating certs.

What was happening before? When you had a TrustFailure at the encrypted connection level, that would prevent the server from giving you a higher-level HTTP error. Was this working completely and recently?

Make sure the B2 keyid is in Duplicati B2 Application ID field and the B2 key is in B2 Application Key field.
These are kind of like username and password. Visually, you might notice that only the key gets * hidden.

Before everything was chugging along nicely, and had been since I set it up this summer. Duplicati reports that the last successful backup was on 9th December, which should coincide with the reported certificate renewal above.

Yes, regarding the API ID and Key, they have been working perfectly before – I believe I have them put them in the right place.

The timing doesn’t fit perfectly. The Dec 4 report linked from here saw a Nov 30 certificate, still in use now, which seems like it should have caused the TrustFailure problem on your Dec 9 backup. So that’s strange.

Ignoring that, your new 401 - unauthorized isn’t being reported elsewhere that I’ve seen, so might be some configuration (or was there a configuration change?) on your system. Backblaze themselves have posted Quickstart Guide for Duplicati and Backblaze B2 Cloud Storage which unfortunately doesn’t say precisely what to put where, but at least indicates they might be willing to take a followup support question if needed.

You could test some other Backblaze B2 client to see whether you can get it authenticated, and you could look more closely at your Duplicati setting using Export As Command-line which will make it clearer which field is which, spot inadvertent characters, etc. Mine contains “auth-password=K” … Does a K mean key?

I just wanted to get back to this thread with what issue I was facing, and how I solved it (in case a future Googler lands here):

While the initial Trust Failure was successfully resolved with the method @drwtsn32 suggested, I had an additional 401 - Unauthorized error appearing. The error message was quite confusing, as 401 normally indicates an HTTP(S) error, but in fact the unauthorized error I got was from when trying to access files over SMB. At some point I must have changed some permission setting, making Duplicati unable to access the mounted /source directory. It was just unfortunate that those two errors came after one another.

2 Likes

Just upgraded my system from Debian 10 to 11 and encountered the same issue. The @drwtsn32 fix seems to have worked.

1 Like