I would like to handle following message at startup:
27. Febr. 2025 10:02: No database encryption key was found. The database will be stored unencrypted. Supply an encryption key via the environment variable SETTINGS_ENCRYPTION_KEY or disable database encryption with the option --disable-db-encryption
Looking at several posts in the forum, the message is about the server DB encryption key missing. I don’t want to store the passphrase for that in plain text and thus thought about using Windows credential manager. As I have never actively used that tool before, could you confirm how to set up the key properly?
My assumptions are based on following posts and documentation resources: Securing the database, Using the secret provider, Announcement of secrets with example
What I think I should do:
Windows Credentials → Generic Credentials → Add a generic credential → Enter info for fields internet or network address, Username, Password:
internet or network address: localhost:8200 (host name of the running duplicati application)
Username: duplicati-server (username to be referred to in argument --settings-encryption-key)
Password: <password to be set and subsequently used>
From then on, always start Duplicati using command line arguments and referring to the stored credentials:
Is this how it works? Specifically, does Duplicati use the --settings-encryption-key-value as mapping for the Username in credentials manager or for the internet or network address field?
From what I recall the “Internet or network address” is mislabelled in the Windows UI as it is actually called “TargetName” in the Windows API and can be any string. This is the name that you refer to with the secret manager.
Yes, that is how it works.
The translation will look for $duplicati-server and check the Windows Credentials for an entry with the “internet or network address” value “duplicati-server”, and then replace it with the password. The username is not currently used by Duplicati.
If any of the values cannot be resolved, the start will fail.
For a slightly better testing experience, you can use the commandline and then:
Duplicati.CommandLine.SecretTool.exe test wincred:// duplicati-server
Perfect, many thanks, that already answered my follow-up questions about verifying whether the passphrase could be resolved!
I managed to configure it appropriately and can see that the Duplicati-server.sqlite now features some encrypted columns (with enc: prefix in the value) in the tables Backup and Option.
Just for your information: The wrong configuration I previously proposed did not raise any visible error in the server logs UI (About → Log → Live → Verbose) and the warning about the missing database encryption key did no more occur (2.1.0.2_beta_2024-11-29). The server just started normally when running Duplicati.GUI.TrayIcon.exe. However, I did not test starting a backup, maybe the failure would occur later?
This tool indeed reported that the previous configuration was wrong (KeyNotFoundException raised) and that the corrected one works as intended.
That sounds bad. That would imply that it is using the literal string $duplicati-server as the encryption key. The database is checked on startup, so this is where it will fail.
However, if you managed to get it started with a wrong key, it should be encrypted, and fixing the input should then fail (as the key has changed). Did that happen?
I even had created a copy of the Duplicati-server.sqlite before moving on from the “wrong” to the “correct” configuration, but I’m afraid I already deleted it after seeing the encryption being successfully applied. I think (but am not sure and can no more verify) that the database tables did not have encrypted column values at the time of the “wrong” configuration being active.
I did not see any error message in the Server logs after correcting the configuration and a test backup also went successfully.
If I can help you reproduce that behavior anyhow (e.g., by removing encryption and then testing the “wrong” configuration again), let me know.
One idea could be that the command line parameters were ignored for some reason at the time of the “wrong” configuration (even though I would expect the warning message of the missing database encryption key to appear in the verbose Server log then). I use different ways to start the Duplicati.GUI.TrayIcon.exe (registry entry for auto start vs shortcut for manual start) but both have the command line parameters set identically and in the current state, using either one of both options leads to a successful start of Duplicati, so I would not suspect an issue in any of them.
Note that I updated Duplicati to 2.1.0.4_stable_2025-01-31 after the successful encryption, so the setup might have changed a little for any subsequent tests.