Duplicati on CasaOS Loads but Login Fails

Most likely fix: current Duplicati Docker uses DUPLICATI__WEBSERVICE_PASSWORD—double underscore—for the UI password. SETTINGS_ENCRYPTION_KEY encrypts sensitive settings in the database; it is not the password you type into the browser.

Use the two variables for different jobs

environment:
  SETTINGS_ENCRYPTION_KEY: "long-random-key"
  DUPLICATI__WEBSERVICE_PASSWORD: "your-ui-password"

Duplicati's Docker secret variables document that separation.

Recreate after editing environment

A running container keeps the environment it started with. Recreate it after changing compose values:

docker compose up -d --force-recreate

Then verify the variable names without publishing the secret values:

docker inspect duplicati --format '{{range .Config.Env}}{{println .}}{{end}}' | grep -E 'DUPLICATI|SETTINGS'

Check hostname protection

If direct IP access works but a hostname/reverse proxy fails, configure allowed hostnames:

DUPLICATI__WEBSERVICE_ALLOWED_HOSTNAMES=backup.example.com

A wildcard * disables the protection and is not the preferred default.

Do not confuse encryption with authentication

SETTINGS_ENCRYPTION_KEY protects credentials stored in Duplicati's database. Back it up securely because losing the key can make encrypted settings unavailable after migration.

If login still fails

check for an old conflicting password variable;
read container logs after recreation;
test direct LAN IP before the proxy;
confirm the browser reaches the expected container/port;
do not delete the Duplicati database as a first step.

The backup and sync workflow helps distinguish backup from synchronization. The ZimaOS app catalog helps compare backup tools.

For multi-drive backup storage, ZimaCube 2 is a relevant hardware platform.

Why the double underscore matters

Duplicati maps command-line options into environment variables by replacing the option prefix with DUPLICATI__. A superficially similar variable with a single underscore is not the same setting. This is a common container problem because the UI still loads even when the intended authentication option was never applied.

Verify the active container, not only the CasaOS form

CasaOS may show the values you entered, but the decisive evidence is the environment inside the created container. Inspect the running configuration and then restart/recreate only after the expected variable name appears.

Watch logs while attempting login

docker logs -f duplicati

Try one login and watch for hostname rejection, authentication failure, database errors, or startup warnings. This separates a wrong password from a proxy/host-header problem.

Test direct IP before reverse proxy

Temporarily access Duplicati by the CasaOS host's LAN IP and published port. If that works while the domain does not, focus on allowed hostnames and reverse-proxy headers rather than resetting credentials.

Preserve the encryption key during migration

The encryption key protects stored settings such as backend credentials. Save it in a password manager or other secure backup independent of the server. A backup system whose own secret is stored only on the machine it protects creates a recovery trap.

Avoid destructive password “fixes” first

Deleting Duplicati's database can remove backup-job configuration and history. Confirm environment variables, active container state, hostnames, and logs before considering database reset or reinstallation.

FAQ

Is SETTINGS_ENCRYPTION_KEY my login password?

No. Use DUPLICATI__WEBSERVICE_PASSWORD for web UI authentication.

Why did my changed password not take effect?

The old container may still have its previous environment. Recreate it.