# Upgrading 2.3.0.3 to 2.3.0.4 causes key missing exception

**URL:** https://forum.duplicati.com/t/upgrading-2-3-0-3-to-2-3-0-4-causes-key-missing-exception/22567
**Category:** Uncategorized
**Created:** [July 21, 2026, 9:00am UTC](https://forum.duplicati.com/t/upgrading-2-3-0-3-to-2-3-0-4-causes-key-missing-exception/22567 "2026-07-21T09:00:10Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![unosd](https://forum.duplicati.com/letter_avatar_proxy/v4/letter/u/fbc32d/32.png) [@unosd](https://forum.duplicati.com/u/unosd)
#### Post date: [July 21, 2026, 9:00am UTC](https://forum.duplicati.com/t/upgrading-2-3-0-3-to-2-3-0-4-causes-key-missing-exception/22567/1 "2026-07-21T09:00:12Z")

</div>

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!

---

<div class="post-metadata">

### Author: ![kenkendk](https://forum.duplicati.com/user_avatar/forum.duplicati.com/kenkendk/32/5305_2.png) [@kenkendk](https://forum.duplicati.com/u/kenkendk)
#### Post date: [July 26, 2026, 3:20pm UTC](https://forum.duplicati.com/t/upgrading-2-3-0-3-to-2-3-0-4-causes-key-missing-exception/22567/2 "2026-07-26T15:20:31Z")

</div>

> [@unosd](#):
>
> Downgrading makes it work again.

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

> [@unosd](#):
>
> 1. What changed in the new version that caused the issue and how do I fix it?

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://`.

> [@unosd](#):
>
> 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?

The fact that Duplicati starts means the key is correct.

> [@unosd](#):
>
> 1. 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?

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.

---

<div class="post-metadata">

### Author: ![unosd](https://forum.duplicati.com/letter_avatar_proxy/v4/letter/u/fbc32d/32.png) [@unosd](https://forum.duplicati.com/u/unosd)
#### Post date: [August 18, 2026, 9:51am UTC](https://forum.duplicati.com/t/upgrading-2-3-0-3-to-2-3-0-4-causes-key-missing-exception/22567/3 "2026-08-18T09:51:50Z")

</div>

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

```plaintext
[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 😄 . 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.

---

<div class="post-metadata">

### Author: ![kenkendk](https://forum.duplicati.com/user_avatar/forum.duplicati.com/kenkendk/32/5305_2.png) [@kenkendk](https://forum.duplicati.com/u/kenkendk)
#### Post date: [August 18, 2026, 10:24am UTC](https://forum.duplicati.com/t/upgrading-2-3-0-3-to-2-3-0-4-causes-key-missing-exception/22567/4 "2026-08-18T10:24:18Z")

</div>

> [@unosd](#):
>
> apologies for the ignorance, but how do I see if I am?

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:

```plaintext
duplicati-secret-tool

```

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

> [@unosd](#):
>
> 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.

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.

---

<div class="post-metadata">

### Author: ![unosd](https://forum.duplicati.com/letter_avatar_proxy/v4/letter/u/fbc32d/32.png) [@unosd](https://forum.duplicati.com/u/unosd)
#### Post date: [August 22, 2026, 7:22am UTC](https://forum.duplicati.com/t/upgrading-2-3-0-3-to-2-3-0-4-causes-key-missing-exception/22567/5 "2026-08-22T07:22:03Z")

</div>

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:

```plaintext
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!

---

<div class="post-metadata">

### Author: ![dferreyra](https://forum.duplicati.com/letter_avatar_proxy/v4/letter/d/3e96dc/32.png) [@dferreyra](https://forum.duplicati.com/u/dferreyra)
#### Post date: [September 10, 2026, 6:08am UTC](https://forum.duplicati.com/t/upgrading-2-3-0-3-to-2-3-0-4-causes-key-missing-exception/22567/6 "2026-09-10T06:08:40Z")

</div>

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:

```bash
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.,

```bash
DUPLICATI_PRELOAD_SETTINGS=C:\ProgramData\Duplicati\preload.json

```

---

<div class="post-metadata">

### Author: ![kenkendk](https://forum.duplicati.com/user_avatar/forum.duplicati.com/kenkendk/32/5305_2.png) [@kenkendk](https://forum.duplicati.com/u/kenkendk)
#### Post date: [September 10, 2026, 7:07am UTC](https://forum.duplicati.com/t/upgrading-2-3-0-3-to-2-3-0-4-causes-key-missing-exception/22567/7 "2026-09-10T07:07:17Z")

</div>

> [@dferreyra](#):
>
> Maybe the new version is no longer picking up the `preload.json` file automatically?

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.
