Random job failures due to unknown certificate authority

Support
#1

For about the last 3 weeks I have been seeing random failures of backup, prune and check jobs using Duplicacy Web-UI. Both manual and scheduled jobs have failed. There doesn’t seem to be a determinable pattern, but the error is always the same:

2020-01-18 03:05:25.686 ERROR STORAGE_CONFIG Failed to download the configuration file from the storage: Head https://f002.backblazeb2.com/bucket name removed/config: x509: certificate signed by unknown authority

Our remote storage are Backblaze B2 buckets. This has happened on multiple buckets as well. It is very random. If a scheduled job fails one time, the next time the schedule runs it usually succeeds. I have had manual jobs fail 2-3 in a row and them work on the 4th time.

Is any one else having this happen? Any thoughts/guidance on diagnosing the issue?
Thanks,

#2

A similar issue is here: Maximum backoff reached

When this happens again, try to access https://hostname/1b/b2api/v1/b2_upload_file/2568b8213d5e79405bc9051b/c001_v0001041_t0005 on the same computer in a browser to see if you can reproduce the certificate error.

#3

So, I believe that I figured out what was happening on my installation. I am running duplicacy web on Debian 9.

During the initial install/config, I used the linux “setcap” command to grant the cap_dac_read_search capability to the duplicacy binary file so that it could bypass file read permission checks and successfully backup all files. ( I am not running duplicacy web as root, which is why this was needed). At the time of install the CLI version was 2.2.3.

When CLI 2.3.0 was released, duplicacy web automatically downloaded and started using the new version. However, the new binary did not have the cap_dac_read_search capability applied, so it was not able to read some files. This also meant some files were not being backed up, which I wasn’t immediately aware of. I’m not exactly sure why this was throwing a certificate error, but once I applied the capability to the 2.3.0 binary the problem has stopped.

@gchen, I saw mention in another post about setting the cli_version key in the duplicacy.json file to prevent auto-updating, but it was not clear to me what the key needs to be set to. Should I simply set it to “2.3.0”? I’d like if it did not update automatically.

#4

Right, it should be:

{
...
"cli_version": "2.3.0",
...
}