Sudden repeated "Server crashed on startup"

Uncategorized
1

Longtime Duplicati user. On a Windows 10 machine, 2.3.0.1_stable_2026-04-24 was running for months with no apparent issues. Then I noticed tray icon was missing. Tried restarting Duplicati ->didn’t work. Tried rebooting → didn’t work. Downloaded and installed latest 2.3.0.4, thinking it might have fixed something. But it still wouldn’t start. Digging deeper now, looked at crash log and it starts with this:

Duplicati.Library.Interface.UserInformationException: Server crashed on startup
—> System.Exception: A serious error occurred in Duplicati: Duplicati.Library.Interface.SettingsEncryptionKeyMismatchException: Encryption key used to encrypt target settings does not match current key.

Note that no configuration or anything was intentionally changed between everything working and it failing.

I never explicitly encrypted the database, but I see in the release notes that 2.3.0.0 adds a default secret provider, and sure enough, when I look in the Windows Credential Manager, there is an entry for duplicati-server-encryption-key.

So I tried launching Duplicati.GUI.TrayIcon.exe with the --disable-db-encryption, but it fails with the exact same output.

Other than doing a fresh install, I’m now at a loss as to what to do next to get it working again.

2

This message means that Duplicati found an encryption key, but it was not the right one.

Did you by any chance run a “cleaner” program?
I am aware that some cleaner programs have a setting for “remove intranet credentials” or similar wording, that will actually wipe the Windows Credential Manager for all credentials.

Duplicati prior to 2.3.0.4 had a logic bug where it would create a new key if it could not decrypt the database. While this did not break anything directly, it can be really confusing if the real key was wiped, as you would see a key, but it would not be the right one.

Yes, without the key, the database cannot be decrypted.

If you have the backup configurations exported, you can rename the Duplicati-server.sqlite file to get a clean slate.

I will try to add a wipe-encryption method that will purge the database of encrypted content so you could run that first, and then go and manually enter the things that were wiped (encryption passphrase, destination url, etc).

3

No, nothing was done on this machine that I might suspect would modify the Credential Manager.

Unfortunately, I didn’t export it first.

That would be fantastic. Alternatively, is it straightforward enough for me to use a sqilte DB editor to replace the “enc-v1” fields in there with their plaintext versions (unless the format has changed recently, I can look at one of the backup server DBs for examples), delete the key in WCM, and relaunch? (I do see a lot of encrypted fields in the Option table that I know nothing about and wouldn’t touch, though, e.g. jwt-config, pbkdf-config…)

Thanks for your help. (Honored to be receiving it from duplicati’s creator).

4

@kenkendk Update: Duplicati is working again for me after using your new wipe-encryption command (from 2.3.0.108_canary) and then resetting the passphrase and target URL. I still have no idea how there ever was an encryption key mismatch, but thank you so much for the convenient tool to fix it!!

5

Same problem here. I don‘t have the time right now to dig deeper into it (will have this evening) but the facts are:

  • Relatively recent windows duplicati release
  • did change nothing (but rebootet)
  • runs with the gui tray, not as a service
  • I have another backup so recovering a key should be no problem

So how should I start to repair that?

Just get the key from a backup and compare it?

How to?

6

I think the problem happend because of a wipe of the windows credentials manager…
I’ll try the “wipe-encryption” way.

7

Just as a data point I would like to say this occurred for me yesterday (2026-08-09) running 2.3.0.107-1 Canary build on CachyOS (Arch Linux) therefore this is not just a Windows issue. I rebooted my computer and duplicati went from running fine to showing a crash error (upon automatic startup of the Tray service at user login). Error message is the same:

`Duplicati.Library.Interface.UserInformationException: Server crashed on startup
—> System.Exception: A serious error occurred in Duplicati: Duplicati.Library.Interface.SettingsEncryptionKeyMissingException: Encryption key is missing`

I have the backup configuration saved so I will just attempt an erase and reinstall as a solution. But thought you would want to know in attempting to trace the cause.

8

I am unsure of your solution. So if you could say the methods you used, I would be grateful. I happen to be on Windows, and I happen to have another Post alive in here about my upgrade troubles.

My question is what you mean by a backup configuration.

I have kept copies of my database (about 6 GB) and my Duplicati-server.sqlite (configuration) files. I think the former one is the thing that is encrypted and the latter is the one that some people are editing manually, others are copying from a backup.

But Ken said to delete Duplicati-server.sqlite, which seems backwards to me. How can it do anything without the configuration? My gut is that it (the Duplicati-server.sqlite) may be able to be rebuilt from my external duplicati backup. Can anyone confirm?

All I did was what I thought was an easy upgrade to a new stable, and had two issues: the new user restrictions of the Windows service (detailed in my other post) and the database encryption issue (that you and several others have had).

Thanks everyone.

9

The server database

All configuration data, logs and settings are stored inside the file Duplicati-server.sqlite.

Securing the database

To protect the database, Duplicati has support for a field-level encryption password. When activated, any setting that is deemed sensitive will be encrypted before being written to the database. This method ensures that the SQLite database itself is still readable, but the secrets are not readable without the encryption passphrase.

The local database is the per-job one, and can get large. I don’t think it needs any encryption.

Are you talking about this from above? If so, please note the words in front of the suggestion:

If something else, please give context, link, quote, etc. From job exports, you can then do this:

Import configuration

This will get the backup configurations restored. You do lose some history, but it’s pretty good.
Problem is that if you never got job exports, you can’t import, so your configs are in database.

I would prefer that the developer give detailed advice, but I can quote from the release notice:

Added wipe-encryption to database tool

The database tool now supports a wipe-encryption command that can be used to remove all encrypted fields from a server database. With this command it is possible to get an encrypted database back into a state where it can be opened again. After encrypted fields are wiped, the user can then edit backups and settings to replace the lost data.

Theory sounds like your secrets should be in a password saver or somewhere. Get non-secret
configuration parts out of database with a key that no longer works, then manually add secrets.

EDIT 1:

Actually wipe-encryption was described above before it was done, so you can also read that.