2 zimaOS boxes experiencing similar if not same issues with remote login

Insight & Feedback
42

Why your previous attempts didn’t work

I believe this happened because:

  • Duplicati was first started without a valid SETTINGS_ENCRYPTION_KEY
  • That created an incomplete / invalid settings database
  • Changing env vars afterwards does not fix an already-created DB
  • So the container keeps restarting and the UI shows Service Unavailable

This is normal Duplicati behaviour, not a ZimaOS bug.

The correct fix (safe and simple)

I suggest doing a clean reset of the Duplicati config only and recreating the container once with a proper key.

Step 1 – Stop and remove the container (safe)

This does not delete your backups.

sudo docker rm -f duplicati

Step 2 – Remove ONLY the config database

Safety note:
Do not touch /DATA/Duplicati/backups or your source folders.
Only remove the config folder.

sudo rm -rf /DATA/AppData/duplicati/config/*

This removes the broken settings DB so Duplicati can recreate it cleanly.

Step 3 – Recreate Duplicati with a real encryption key

I suggest using the ZimaOS App UI or CLI, but not both.

If using environment variables, make sure they are exactly:

  • SETTINGS_ENCRYPTION_KEY (no typos)
  • Any non-trivial string (not 1234)

Example (CLI reference):

-e SETTINGS_ENCRYPTION_KEY=ThisIsMyDuplicatiKey123

You can also omit DUPLICATI__DISABLE_DB_ENCRYPTION entirely — the default encrypted DB is fine.

After restart

Once the container starts again:

  • Open http://<zima-ip>:8200
  • The setup wizard should load immediately
  • No more “Service Unavailable”

Extra safety clarification

  • The encryption key is only for the internal settings database
  • It is not your backup password
  • Losing it only affects the UI config, not your backup files

If it still doesn’t come up after that, the next step would simply be:

sudo docker logs duplicati

but I believe this reset will resolve it cleanly.

43

Thanks, I got in. The log in password is set to some random combination when the docker is created so using the tools and tips you provided above I was able to figure out how to set that.

Thanks much!

Now I just have to figure out how to use duplicati properly haha

1 Like
44

Since you asked about using Duplicati properly, here’s a clear, safe way to think about it on ZimaOS.

1) First: how to think about Duplicati (important)

I believe the biggest mental shift is this:

Duplicati is not a file mirror.
It creates an encrypted backup database made of blocks + metadata.

That means:

  • the destination will not look like normal folders
  • restores are done through Duplicati, not by browsing the NAS
  • this is expected and correct behaviour

Once that clicks, Duplicati makes a lot more sense.

2) Recommended NAS backup layout (very important)

I believe most long-term issues come from messy destinations, so I suggest keeping it boring and isolated.

On the NAS (backup destination)

I suggest a layout like this:

/Backups
  /zimaos
    /duplicati
      /data

How to use this in Duplicati:

  • Destination folder:
    /Backups/zimaos/duplicati/data
  • One ZimaOS machine → one Duplicati folder
  • Do not mix multiple machines in the same destination

This avoids database conflicts and restore issues later.

3) What to back up on ZimaOS (and what not to)

I believe this is where many people get into trouble.

Good backup sources (user data only)

I suggest backing up things like:

/media/Zima/Documents
/media/Zima/Photos
/media/Zima/Projects
/media/Zima/Media

Do NOT back up these paths

I strongly suggest not backing up:

/DATA/AppData
/var/lib/docker
/media/ZimaOS-HD
/media/*/.trash

Reason:

  • Docker apps should be re-created, not restored file-by-file
  • Backing up AppData and system paths often causes instability on restore

4) ZimaOS + Duplicati best-practice setup

This is the “template” you can reuse.

One container only

  • Install Duplicati via App Store or CLI, not both
  • One container, one config path

Config location

/DATA/AppData/duplicati/config

Do not manually edit files once running.

Destination rules

  • One destination per machine
  • One Duplicati folder per machine
  • Never reuse destinations across devices

Encryption

  • Enable backup encryption
  • Store the password securely
  • Losing it = backups unrecoverable
    (This is separate from the UI password and settings DB key.)

5) Sensible default settings

I suggest starting with:

  • Backup type: Incremental
  • Compression: On
  • Volume size: 50–100 MB
  • Schedule: Daily
  • Retention: Keep all backups (refine later)

Avoid aggressive cleanup or “smart” retention until you’re confident.

6) Test restores early (non-negotiable)

I believe this is the most important rule:

  • Restore a single file
  • Restore a whole folder
  • Do it early, not “one day”

A backup that hasn’t been restored is unproven.

7) Extra safety notes

  • Don’t mix UI and CLI workflows
  • Don’t manually delete files inside the Duplicati config folder
  • Keep Duplicati isolated from Docker/AppData backups
  • Watch warnings in logs, not just green ticks

One-line takeaway

I believe Duplicati works best on ZimaOS when you keep sources clean, destinations isolated, treat it as a backup database (not a file mirror), and test restores early.

1 Like
45

Ideally, I’d like duplicati to back up to the WD mycloud on the same network, but I’ve having trouble connecting to it in duplicati through webdav or ftp / sftp. This I believe is more an issue with the WD but not 100% certain.

I should be able to mount 192.168.0.81 again, but if not mistaken that will add it to /media and then I might have the same issue with space correct? Also, would I need to mount the drive in case of reboot or powerfailure?