Thank you. I removed the container and image, rebuilt everything, and it seems to be working now. I’m not sure what I did differently, but recreating the volume mappings per your post seems to have done the trick. Thanks for helping!
@saspus - The only heartburn I’m having with the image may be hard to get around. Do you by chance do an Disk backup to an External device? I don’t know how the app handles the situation when a storage isn’t available, I presume it just errors but continues running everything else. The problem is, no matter how I try mapping the external drive, the Duplicacy container goes down completely if the USB device is removed (because a mounted volume is removed). Any ideas?
I actually have an issue from the other end – container refuses to start if mounted volume is missing.
However thinking about this – it is actually a desirable behavior. There is no good way to handle disappearing volume in flight – what’s supposed to happen with backup in progress? If it is destination - OK, just handle like any other media failure, but if the volume is a source – do we backup the absence of files?
There is a workaround of course – mount parent folder to container instead of a mount itself. Then it becomes duplicacy’s job to deal with disappearing destination; it would just refuse to work if disk is missing in the beginning (with “Storage has not been initialized” error) and if it is yanked mid-backup – well, it’s just like any other network interruption.
------8<------ //offtopic here
What bothers me here however (and this is another off topic can of worms) is the use of USB drive as a backup destination in the first place: abysmal reliability, write-hole due to sudden disconnects and questionable controller behavior, and more importantly – bit-rot. Duplicacy will probably detect corruption during restore but not until restore is performed, and unless you use BTRFS with DUP for both data and metadata on it – that won’t help either – data would be unrecoverable. And likely using Btrfs/ZFS on it is also not a great idea - due to the same write-hole and USB controller doing crazy things between the filesystem and actual disk.
I’ve noticed and was about to ask if I was the only one. I have another issue, however:
When most of my (other) services that run in docker die, swarm recreates them with ease. When the NAS is restarted, docker is restarted along with the apps that were running before, without a hiccup. I have alerting ready should duplicacy go down, or not come up after reboot, but I never get paged because the container is running, but (I guess) I’ve not re-logged in? Not sure why we couldn’t get this to run in a daemon mode such that it resume the previously scheduled backup schedule a up as soon as it wakes back up, but I think the app may need the ability to start without user input.
By the way, I’m not using a USB “Drive” - I am fully aware of all the concerns you have listed. I am using a USB 3.1 connected HDD. Does that mitigate any of your cautions/concerns?
Unrelated but more importantly, when the container first starts up it does not run any scheduled backups until/unless I’ve manually logged into the Web UI (and I presume, run them.) I presume because I haven’t tried just logging in and back out and seeing if my backups are running then. Is there something in the container that would be causing this behavior? Or is this part of the app design?
I noticed you updated the container to the new Web UI. Any chance it will pass the DWE_PASSWORD environment variable through to Duplicacy to make it work on a headless box without the password: Trouble with the encryption password on a headless Linux box
Ah, awesome feature. Yes, of course, I will add it, test it, and push the update later today. Thank you for the tip!
Thinking about this — I don’t think any changes are needed in the container: you can just pass the environment variable to the container via -e params: e.g. -e DWE_PASSWORD="Password"
Long timer lurker, first time calling in. 
Any chance you can add the Arm build for this Docker image?
Good idea. Ill think how best to do it. Maybe just an environment variable that can be overridden.
-
How does it look for the latest release? I.e. how does duplicacy_web know the URL for the current duplicacy CLI? Is there an URL alias that always points to a current version?
-
Any chance to redirect where the duplicacy_web looks for duplciacy_cli? The ~/.duplciacy-web folder is a reasonable place to keep data that needs to be persisted (config, stats, etc) and is a good candidate for a docker volume but I don’t think it’s an appropriate place for helper executables. Those are not configuration but rather part of software bundle; I’d rather build them into the image as opposed to keeping them dangling in the under data directories and relying on duplicacy to download them. Users may not have an internet connection on the machine with docker so I would be a good idea to have complete image pre-baked; but I would not want to litter in config folder.
Like this: One Liner to Download the Latest Release from Github Repo · GitHub, plus the names of the executable files are standardised there so they can just be constants in 
-web code.
That’s what I’m was actually trying to understand. If new CLI is released will the existing duplicay_web download a new one or will it keep using the existing one, the one that was current when _web was published?
And if it does download the new one – how often does it check for the new one? Only when the CLI is missing? Never? Every Launch? Every hour?
Duplicacy Web Edition checks this url https://api.github.com/repos/gilbertchen/duplicacy/releases/latest to find out the latest CLI version. It only does this on start. But, you can fix the CLI version by setting cli_version in ~/.duplicacy-web/duplicacy.json. For example "cli_version": "2.2.0" will instruct Duplicacy Web Edition to run CLI 2.2.0 without checking the latest version on github.
2 Likes
How do you actually apply a license in the docker container?
I have purchased a license, and have an “activation code”
I have specified the --hostname and can see that there is a licenses.json file in the config, but the strings in it are much bigger than my activation code. I have tried putting it in the “license id”
in duplicacy.json but that doesn’t work. What do I do?
Go to the Backup page. On the left top corner you’ll see a link next to the localhost text that says Trial. Click on that link and you can enter your license code.
Ah thanks, that worked.
May I suggest something on the settings page about this as that’s where I would expect to see license status and a link to activate a new license.
1 Like
I’m having trouble with the duplicacy scheduler just stopping after a while. I just got back from vacation and found it hadn’t run since the day December 22. Checking the log I see this:
2019/12/22 04:13:09 Failed to get the value from the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: dbus: DBUS_SESSION_BUS_ADDRESS not set
2019/12/22 04:13:09 Failed to decrypt the testing data using the password from KeyChain/Keyring: crypto/aes: invalid key size 0
2019/12/22 04:13:09 Temporary directory set to /cache
2019/12/22 04:13:09 Schedule DailyBackup next run time: 2019-1223 03:00
2019/12/22 04:13:09 Duplicacy Web Edition 1.1.0 (818F2B)
2019/12/22 04:13:10 Duplicacy CLI 2.3.0
2019/12/23 03:00:01 Skipping schedule DailyBackup at time 2019-1223 03:00 as no encryption password has been provided
2019/12/23 03:00:01 Please open the web browser at 0.0.0.0:3875 to enter the encryption password
2019/12/23 03:00:02 Schedule DailyBackup next run time: 2019-1224 03:00
And then the last 3 lines repeated daily until now.
I’ve noticed this before, but then its started working again, presumably because I logged into the UI.
Ideally I’d like to make my duplicacy container run without me having to periodically log in to the UI. Is there something I can change?
Thanks!
You can pass the encryption password in an environment variable DWE_PASSWORD before running the web GUI.