By page 3, this long support thread was no longer mainly about remote login. The actionable problem had become a Duplicati container that was running but opened as Service Unavailable. Its log gave the key clue: the settings database had been created without a valid SETTINGS_ENCRYPTION_KEY, and changing environment variables afterward had not repaired the already-created configuration state.
The community fix was deliberately narrow: remove/recreate the Duplicati container, clear only its configuration database, keep the backup destination and source folders untouched, then recreate Duplicati once with a real settings-encryption key. The original poster later replied, “I got in,” confirming that the recovery path restored access.
The Duplicati Log Identified the Missing Settings Encryption Key
The source log ended with:
Missing encryption key, unable to encrypt your settings database
Please set a value for SETTINGS_ENCRYPTION_KEY and recreate the containerThat is much stronger evidence than guessing at ports or ZimaOS remote access. The failure was inside the Duplicati application/configuration layer.
The Settings Key Is Not the Same as the Backup Encryption Password
-
SETTINGS_ENCRYPTION_KEYprotects Duplicati's local settings database; - the backup encryption password protects backup content;
- the WebUI login password is another separate credential.
Keep these secrets documented in a password manager rather than reusing a weak test value such as 1234.
Do Not Delete the Backup Destination
The source explicitly warned not to touch backup data or source folders. The reset targeted only the Duplicati config database under the AppData configuration path. Container removal does not automatically mean backup deletion when backup data is stored in a separate mapped host folder.
Recreate the Container with a Valid Key
- stop/remove the broken Duplicati container;
- back up then clear only the Duplicati config database;
- set a strong
SETTINGS_ENCRYPTION_KEY; - recreate the container once;
- open the WebUI and verify setup starts normally.
Because this is community troubleshooting, review the actual current volume mappings before deleting any config directory.
Do Not Mix App Store and Manual Docker Installs
Earlier in the same thread, the user accidentally created a second Duplicati container manually while also using the App Store. That created port and configuration ambiguity. Pick one deployment method and keep one authoritative config path.
Duplicati Is an Archive Backup, Not a Browseable Mirror
The source discussion later clarified that Duplicati stores blocks plus metadata. The destination is not expected to look like a normal copy of every source folder; restores are performed through Duplicati.
Test both a single-file restore and a folder restore before trusting the backup for production data.
Do Not Confuse Duplicati with ZimaOS Backup
ZimaOS also has its own scheduled/versioned Backup system. Duplicati is useful when you specifically want Duplicati's encrypted archive format and destination support; the built-in Backup app is simpler when its supported sources/destinations match the requirement.
Use the current ZimaOS Backup workflow.
Duplicati Service Unavailable FAQ
Did the source user confirm access was restored?
Yes. After the config/key troubleshooting, the original poster said they got into Duplicati.
Should I delete my Duplicati backup files to fix the WebUI?
No. The source fix targeted only the broken configuration database, not the backup destination or source data.
Is SETTINGS_ENCRYPTION_KEY the backup password?
No. It protects Duplicati's local settings database and is separate from backup-content encryption.
