Upgrading 2.3.0.3 to 2.3.0.4 causes key missing exception

Uncategorized
1

hi all,

I have just upgraded and Duplicati fails to start (SettingsEncryptionKeyMissingException). I can’t honestly remember if/how I specified the key before somewhere, but nonetheless before the upgrade it was finding it and after it’s missing. Downgrading makes it work again.

I tried specifying it in the systemd service, but the result was that it claims the key is incorrect.

  1. How can I safely verify if I have a key set up and if the one I believe it’s it it’s correct?
  2. What changed in the new version that caused the issue and how do I fix it?
  3. If I need to set up the key, what’s the best way to add it without putting it in plain text in the systemd service?

Thank you!

2

That indicates that the key is present in your system somewhere.

It sounds like this is on Linux and using a service to run it?
Are you using pass by any chance?

I decided to remove pass from the default secret provider as it seems to be unmaintained.
If so, you need to add --secret-provider=pass:// or the set environment variable DUPLICATI__SECRET_PROVIDER=pass://.

The fact that Duplicati starts means the key is correct.

That is problematic, because the service should start without user interaction, yet not have a password written on disk. On Windows we use the Windows Credential Manager which is also available to a service, but on Linux the password managers are connected to the desktop which is not available for a service.

You can use an encrypted file (similar to how pass works), but then you need to supply that key in the service file.

3

thank you for the feedback @kenkendk and apologies for the delay; it sounds like I am not getting email notifications for the replies and I rolled back to the previous version and forgot about it for a while.

Are you using pass by any chance?

apologies for the ignorance, but how do I see if I am?

I tried adding

[Service]
Environment="DUPLICATI__SECRET_PROVIDER=pass://"

with systemctl --user edit duplicati.service
but it didn’t work, so I presume I am not using that.

Yes, I am on Arch Linux. I’ll forget about the plain text password for a second, it’s going to be a promblem for tomorrow’s @unosd :smile: . For now I would just like to upgrade to the latest version not to remain behind.

Can you suggest a way to figure out where is it taking the key? Maybe enabling debug logs? I’m not sure if I can show it somehow from the UI.

Thank you.

4

This is automatic, so there are no direct places to see this.
If you can run pass on the commandline, that suggests you have it installed and the Duplicati can use it (assuming it is configured as well).

You can start the secret tool, as it will report the default provider:

duplicati-secret-tool

But you need to run it with the same account as you run Duplicati with.

I would suggest lauching Duplicati once with --disable-db-encryption on the old version. This will decrypt the fields in the database (since the key is apparently available). You can then configure DUPLICATI__SECRET_PROVIDER=file:// with the encryption key, and start again without the --disable-db-encryption switch to have it encrypted with the new key.

After that, you can upgrade to the latest version, and it will use the file.

Sadly, this does not reveal where the key was in the first place.

5

once again, apologies for the delay, still not getting notified.

This is automatic, so there are no direct places to see this.
If you can run pass on the commandline, that suggests you have it installed and the Duplicati can use it (assuming it is configured as well).

I can confirm that pass is not installed, the command does not exist in my environment

You can start the secret tool, as it will report the default provider:

sudo -u duplicati /opt/duplicati/duplicati-secret-tool info
Supported secret providers on Linux:
  env - Secrets from environment variables
  file-secret - Secrets from a file
  awssm - Secrets from AWS Secrets Manager
  hcv - Secrets from HashiCorp Vault
  gcsm - Secrets from Google Cloud Storage Secret Manager
  azkv - Secrets from Azure Key Vault
  pass - Secrets from Unix pass (not supported)
Authorization required, but no authorization protocol specified

  libsecret - Secrets from libsecret

No information found for secret provider '': path

I would suggest lauching Duplicati once with --disable-db-encryption on the old version. This will decrypt the fields in the database (since the key is apparently available). You can then configure DUPLICATI__SECRET_PROVIDER=file:// with the encryption key, and start again without the --disable-db-encryption switch to have it encrypted with the new key.

After that, you can upgrade to the latest version, and it will use the file.

Sadly, this does not reveal where the key was in the first place.

Thank you, I ran it with --disable-db-encryption but, to prevent other issues I decided not to re-encrypt the DB. Given it’s a single-user workstation running Duplicati and the filesystem where the DB lives is LUKS encrypted, I think that’s pretty safe (feel free to disagree if you advise to re-encrypt it, I’ll do it). I can re-encrypt, but I’m not sure what’s the best way/best long-term solution.

Thanks again for the help!

6

I had a similar problem on a couple of machines.

In Ubuntu, I had the settings encryption key stored in /etc/duplicati/preload.json. After upgrading, I got the same error reported in this post. Maybe the new version is no longer picking up the preload.json file automatically? The fix for me was to update my /etc/default/duplicati file to add this line:

DUPLICATI_PRELOAD_SETTINGS=/etc/duplicati/preload.json

Eventually I got the same error on our Windows 11 machines. The fix there was to add a system environment variable pointing to the preload.json file in Windows; e.g.,

DUPLICATI_PRELOAD_SETTINGS=C:\ProgramData\Duplicati\preload.json
7

Yes, that is correct. After reviewing a few different systems, we did not feel confident that the folders were correctly secured on all systems. As a result, we decided not to default trust those folders.

The datafolder (assuming correct permissions) and the installation folder (with the binaries) are now the only two default-trusted locations for preload.json.

The environment variable is an appropriate way to specify that the file is secured when placed in a different path and avoid having a config file with the binaries.