Source
r/synology•
binaryvisions

Duplicacy container is not saving my settings... what am I missing?

I'm running a Duplicacy Web container in my docker-compose configuration.

The Docker config seems fine - the container starts up, it populates files into the config and cache volumes that I've mounted. If I go into Settings and change values there, then hit Save, I see the settings.json file change on the Synology filesystem.

However, duplicacy.json contains nothing but {} and all of my other settings (storage, backup jobs, schedules, even my master encryption password) live and die with the container. That file is stored in the same directory as the settings.json file, though, which is changing when I save updates, so it's not a mount point or permissions issue.

My storage and backup config is retained (even through container restarts) until I tear down my container, and then they disappear. So it's getting persisted somewhere, just not in duplicacy.json.

Any ideas?

Posted Apr 10, 2021, 9:28 PM UTC

35
ssps•

Try this shameless plug instead: https://hub.docker.com/r/saspus/duplicacy-web. Eric’s container uses different approach to managing config files by using individual symlinks into binds as opposed to entire config folder and may behave differently.

If you still continue having issues it’s best to ask at forum.duplicacy.com as this is definitely not a Synology question

5
binaryvisionsOP•

Thanks. This seems to work straight off, or at least all of my settings are being persisted in duplicacy.json correctly.

Can't for the life of me figure out what's happening with the other container.

1
quorn23•

Post a snippet of your docker-compose file (duplicacy part). I'm using the hotio container (see hotio.dev) without any issues

1
binaryvisionsOP•

Well I fixed it straight away using the other container cited above, and everything controlled by the docker-compose file seemed to be working (i.e. container could write to the config directory, could read from my other mounts, etc), but here is what I was using:

duplicacy:
  image: erichough/duplicacy
  container_name: duplicacy
  hostname: duplicacy
  restart: always
  ports:
    - 3875:3875
  cap_drop:
    - ALL
  environment:
    TZ: America/New_York
    MACHINE_ID: [obfuscated]
  volumes:
    - /volume1/docker/duplicacy/config:/etc/duplicacy
    - /volume1/docker/duplicacy/cache:/var/cache/duplicacy
    - /volume1/storage/onedrive:/backup/onedrive:ro
    - /volume1/photos:/backup/photos:ro
    - /volume1/storage/backups:/backup/backups:ro
1
quorn23•

Oh, I see, good that the change fixed it! Yeah your compose looks fine, if I had to make a wild (tired 4am) guess, the other image might make use of one of the file manipulations you lock down with the cap_drop all.

Edit: having a quick look at the dockerfile, nope, without digging into the logs, no idea. Might be as simple as a permission issue to the image being broken and not actually use the mounted config. Comes down to how hard you want to find out what the issue there is :D

1