This is the part that I don’t understand:
(see manual, and remember to replace all of key with your choice for the key)
Where (or how) do I generate the key?
Despite the term “key”, I think (certainly hope so – maybe dev can confirm) that this is a password/passphrase that you just choose per usual advice to reduce guessing attacks.
Possibly the terminology is a holdover from an earlier design intent which had to change:
Regardless, typical encryption methods do need a key, but they make it from user input.
Key derivation function (Wikipedia)
In cryptography, a key derivation function (KDF) is a cryptographic algorithm that derives one or more secret keys from a secret value such as a master key, a password, or a passphrase
So your job is to pick a reasonable secret, and let Duplicati use it to make an internal key.
Okay, so I put that file in and then I get this:
$ duplicati
The database appears to be encrypted, but no key was specified. Opening the database will likely fail. Use the environment variable SETTINGS_ENCRYPTION_KEY to specify the key.
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
Use the environment variable SETTINGS_ENCRYPTION_KEY to specify the key.
Where & how do I do this?
How To Read and Set Environmental and Shell Variables on Linux is a general tutorial.
If you use the bash shell, you can just say:
SETTINGS_ENCRYPTION_KEY=<key> duplicati (replacing <key> with your passphrase)
If you don’t use the bash shell, you might need to put the word env in front of that line.
You can also ignore the rather brief message directions and do:
duplicati --settings-encryption-key=<key> as shown in the built-in help command:
--settings-encryption-key: Use this option to set the encryption key for the settings database. This option can also be set with the environment variable SETTINGS_ENCRYPTION_KEY.
Easiest is to use ~/.config/Duplicati/preload.json file. Did you? Can you read it?
For the config file preload.json, it’s unclear to me what the EXACT format is…
Do I put Quotes around the passphrase, or brackets? Or nothing?
I just simply do not understand and I’ve been using LINUX for 20 years.
Please explain it to me like I’m five years old.
What passphrase? I never set one.
Where does it go?
I’ve made the perload.json file, but it’s not being read.
Do I replace the less-than-sign-KEY-greather-than-sign with a passphrase/password?
Do I use quotes?
If so, when and how does the database get encrypted?
Like I said, the documentation around this is atrocious and nonsensical.
Okay, got it working.
What did not work: The preload.json file did not work.
What did work: Under StartUp programs
env SETTINGS_ENCRYPTION_KEY="password" duplicati
Where password is a proper password.
is me suggesting replacing those five letters with your chosen password/passphrase.
If you do that, it keeps the quotes that are now around <key>. Other ways may exist.
OK, I see it’s getting worse. Next round.
You pick one, just like for any password/passphrase. Duplicati is asking you to set it.
In a file ~/.config/Duplicati/preload.json, using the template from the manual.
Where it shows <key>, replace that with your password.
ls -lu ~/.config/Duplicati/preload.json at duplicati start should be recent time.
If so, it’s being read, but there might be a problem inside.
Yes. Use of angle bracket with description inside is common in computer documentation.
what does angle brackets mean in documentation? [duplicate]
Sometimes documentation uses italics or similar, but sometimes one has only basic text.
There is similar confusion possible in documentation about how to interpret quote marks.
In file docs, one sees angle brackets inside double quotes. One person typed too literally.
IMO it would be helpful (though maybe repeated) to say what to do with a given template.
You can leave existing the quotes that are already there.
When you start Duplicati.
You can do the ls -lu, and check the format of the file. If you like, post the whole thing with you password replaced with REDACTED and everything else left exactly as there.
All works for me, although this is my first use on Linux, so I’m not the ultimately authority.
1 Like
The word “key” is somewhat arbitrary and can be replaced with on of the words: password/passphrase/secret/random-string.
I try to keep consistent terminology to avoid confusing even more:
- Passphrase: the encryption passphrase (not using the word “password” here, as it should be longer than a password)
- Encryption key: the password or secret used to encrypt database fields
- Access password: the password required to access the user interface
- Credentials: information required to access a remote store (usually username+password)
If you enter it directly in the shortcut, you should also be able to provide it as an commandline argument:
duplicati --settings-encryption-key="password"
The reason for the other ways to provide this is that different setups require different levels of protection, and some might not want to have the password written into the shortcut, and environment variables and the preload file is ways to achieve this.
If you have it working, that is fine. The major issue the encryption key is for, is to protect the secrets inside the database, should it ever leave your system.
Why was it made such complicated? Why is it not part of the setup? It would be much more obvious to all users.
Regards
Generally, the goal is never to make it complicated. If you have suggestions for how to improve it, I am listening.
The main issue is “where do we store the encryption key?” If we have strong encryption, but put the key next to the data, there is no protection offered. If the key (or key location) is not known to the user, this might cause problems where the legitimate users cannot access their data.
For now, I am leaning towards using the operating system credential managers (Windows Credentials or macOS KeyChain). Since there is no real default for Linux, it could perhaps be kept as it is now, requiring user interaction.
I have a similar issue which I still could not solve after reading this thread & the documentation:
Win11, 2.2.0.0_stable_2025-10-23
The same popup appears (“database not encrypted”). As the docs suggested I created a preload.json, but it seems to be ignored, meanwhile I have a copy of it in the following locations:
C:\Program Files\Duplicati 2\preload.json
C:\ProgramData\Duplicati\preload.json
C:\Users\All Users\Duplicati\preload.json
C:\Users\[username]\AppData\Local\Duplicati\preload.json
The content is as suggested in the docs:
{
"env": {
"*": {
"SETTINGS_ENCRYPTION_KEY": "******"
}
}
}
Thanks in advance for your help!
Hi @sieglinde05, welcome to the forum 
To clarify: this message appears after changing the Duplicati version (i.e., after an upgrade).
For 2.2, it sticks around until you click “Dismiss”, it does not re-appear after restarts.
For the current canary and the next stable release it will auto-clear the message if the issue was fixed. For now, you need to manually click “Dismiss” to get the message to go away.
Thanks for the update!
Currently I don’t see the message anymore, so maybe I already clicked “dismiss”.
But: How can I see in the frontend, if the database is (now) encrypted or not?
There is no indicator for this in the UI.
You can try:
- Stop Duplicati
- Rename
preload.jsontotemp-preload.json - Start Duplicati
In step 3, it should now crash with a message that it cannot decrypt the database.
Then rename back to preload.json and it starts automatically.
Alternative is to locate the file Duplicati-server.sqlite and then view the contents of the “Setting” table. (You can use something like SQLiteBrowser).
In the “Setting” table, you should see some entries starting with enc-v1:. If you see these, the database is encrypted.
1 Like
I just got this warning after upgrading. Is there a good way to secure the password?
I believe that all of the current mechanisms could be read by a skilled attacker with access to my system, just as much as they could just read the plaintext database? ie: if someone gains access to my local account, they can easily read a plaintext preload.json file, or search my shell history for the ENV var or command line parameters. Obviously takes some work, but all doable.
To be properly secure, wouldn’t you want to prompt the user at startup (although understandably it could not start automatically then), or via the system keychain as you just mentioned?
For reference, I’m on Fedora Linux, so would be interested in an option there.
HI. You invite suggestions for how to improve it - I too have no clue what I’m doing but the reason to add the key made sense. I suggest adding extra baby steps for those of us who don’t speak programming language (and maybe some pictures?), like, 1) find your sql database location (how to find that was clearly explained). Open a txt file program (eg Notepad on Windows system), paste this text (same useful box to copy as is currently in the help file)… Replace with a strong password you choose (keep the “ at the beginning and end) eg “Sfh3g9%y4”. Click save as…. Navigate to the folder where your sql file is saved, In the file name box type preload.json In file type choose ‘all files’. Save. NOTE somewhere safe the password you chose for future reference!!
After doing this I quit Duplicati so I could restart it and see if it worked. Duplicati lost connection to the server (gulp) and my tray icon vanished. I searched for Duplicati in the start menu and added Duplicati back to my taskbar. I clicked ‘open’ and if did (phew). The ‘need encryption’ message has gone. Hopefully restarting my computer will retain the success! Thanks for all the good work!
1 Like
I have added a new auto-password feature that will be in the next canary release:
This works by using the default secret provider for the current system (Windows Credential Manager, MacOS KeyChain, LibSecret/Pass for Linux).
If a working secret provider is found, generate a random password, store it in the secret provider, and use it to encrypt/decrypt the database. This should make it a lot easier in the future as most systems will be able to use this and auto-encrypt the database.
Please provide clear info in relevant release notices and (later?) user manual.
Automatic random GUI password confuses locked-out users who never set it,
however at least that can probably migrate to new system. Unsure of this one.
EDIT 1:
I’d guess migration between accounts on the same system is also a use case.
EDIT 2:
Also OS reinstall on the same system from an image backup or vendor media.
The downside of any automatic encryption is if a legitimate use case is denied.
What information do you need?
Yes, that is quite annoying. I think we can still improve the message here, so the user knows that they should open from the TrayIcon. Another solution is to make a small window with an embedded browser tab, so the user’s regular browser is not used.
This would allow us to log in automatically without compromising security.
Yes, if the secrets are not migrated as well, then it does not really work.
That depends on the restore I think.
If you re-install the system image, it is (in most cases) the same as migrating to a new system.
You cannot generally just copy in everything in AppData and assume it works on the new system?
Yes, that is what we need to mitigate as well as possible.
However, I don’t consider the server database a thing that should be the primary backup of settings. It is a working copy of settings and can be kept for convenience, but it should not be the primary source. Encryption passphrases should be stored elsewhere in case the system is lost, and if they are, the database is not critical IMO.
Happy to hear other arguments.