Hello - I have Duplicati working but have an issue with Docker. When Docker starts it appears the volumes are not ready, so the container fails. If I start it later it will come up just fine with all of my mounts there. I have used it and it works, but after a reboot the container doesn’t come up. I’m tried messing with systemd unit settings to tie Docker to the mounting of these shares (not all listed below). This didn’t work, and really I don’t want my entire Docker stack to fail for this share as other containers aren’t dependent on it. I’ve also tried using static volumes in docker mounted to the shares (instead of to a locally mounted folder for the shares). Both scenarios result in the same thing.
Again after I reboot the container doesn’t start. I’ve tried tying the docker daemon to require the mounts but then since they’re not ready when Docker starts the daemon doesn’t start. Of course I can use systemctl start docker and it will come up and all is well, including Duplicati. But on reboot, I can’t get Duplicati to start automatically.
I’m on openSUSE Tumbleweed, so it’s a systemd system. Can anyone help me sort this so a reboot doesn’t cause Duplicati to not start until I manually start it? Below are the two compose files I’ve tried using, both work when started, but fail to start on reboot I suspect because the SMB shares are not available.
Mostly I can offer is sympathy as I, too, have failed in all my attempts to fix some systemd dependencies. However a couple of other thoughts:
Just guessing, but are these shares coming from a Synology NAS? (everything but /mnt/praetorian?) One option is you could run docker Duplicati on the NAS instead. I do that, and run another Duplicati instance on another PC. Both backup to the same remote (different buckets). Yeah, it means managing two Duplicati instances, but it’s also nice to not drag all that data over the network.
I’m not sure this would solve your real problem, but it my at least get docker up and running on reboot - make all the directories in your /mnt tree. I assume right now, /mnt is empty unless you’ve mounted the shares. With nothing mounted, you could make “/mnt/volume1” then “/mnt/volume1/homes”, “/mnt/volume/Media” etc. That way, when docker starts up it will see the directories, they will just be empty. Again, that might lead to a problem with Duplicati coming up and thinking the directories are now empty, but maybe your share mounts happen quickly enough that it wouldn’t be an issue? Or maybe Duplicati’s behavior in the case where it does catch it before the shares are mounted will be ok. I know, shallow on details, but the idea might lead you to a viable workaround.
Thanks for the tips. Note I do have /mnt/volume1/homes created, and I’ve mounted my shares there. They are mounted using /etc/fstab but from what I understand systemd creates automounts from these “at boot” so they are systemd mounts, just using the “old” style of doing it. AND - you are right the “volume1” business is the SMB share to my Synology NAS “volume2” is the local storage on the Duplicati machine that I’m using to backup my NAS. The whole goal of this machine, and Duplicati, is to backup my NAS.
I have pulled my hair out with modifying the unit file Docker to include a /bin/sleep command (didn’t work) and RequiresMountsFor (didn’t work). The latter just caused the entire docker service to not start as the mounts apparently weren’t available when Docker was starting. I am really at a loss… I thought for sure the static volumes mounted VIA docker (so only available to docker containers) would work but I guess they aren’t ready when the container comes up. Sooo… I am lost.
What is it that causes docker to fail to come up? If the directories exist on the host machine, I don’t see how docker would know or care that they happened to be empty. The container should at least come up. Clearly I’m missing something.
Docker will fail to start because of a failed dependency if I try to add any mount dependencies to the systemd unit file (using systemctl edit docker.service). I tried each of the three below methods that I could find. WantsMountsFor and Requires both will cause docker to fail with a missing dependency (so it’s not waiting for the share, it’s just not finding it and then failing). The After directive appears to have no effect. This is Docker itself not starting, and I’d rather not have all of docker down because of this one container so I removed the systemd unit overrides and just live with this one container not starting, and I manually start it. All works as expected once started, but if there’s ever a reboot I’d like the backups to start up unattended.
(I tried all three of the below unit file dependency modifiers)
It is really strange that I’m coming up blank on successfull ways to handle this. I’ve used systemd unit file changes to get other things to work right (for instance, I had to make sure the automounts were tied to the network adapter otherwise they would fail because the network wasn’t ready and I’d have to use mount -a to mount them once logged in. Now I don’t have to because I added After= to the automount unit files)
Also - as to the “empty” folders. I tried to mount /mnt/volume1 originally just to have one mount point. BUT, the /homes, /Media and /Photo sub-directories were there, but when I tried to navigate to them they were not populated even when going thru the CLI the shares clearly did mount. I didn’t realize this at the time but I suspect it was because at the instant the container started the subdirs were not mounted. I tried restarting and still no dice, but when I used docker-compose to add the volume /mnt/volume1/homes:/mnt/volume1/homes suddenly it worked. This is the first time I have really tried to use remote volumes. I ran into a similar problem when trying to run Plex on a remote machine. When it was on a Windows 10 machine all was good (not in docker) but when I put it in a docker container on a machine and tried to SMB the directories it wouldn’t work and I’d have to restart plex. I gave up then and put plex on my NAS. But since I’m now trying to back up my NAS I really need to figure this out. For now I just hope I remember to always restart the container. I may even try to make a cron job (or systemd.timer) to restart the container before midnight when my backup tasks run but even then that’s not a good thing because what if a backup is running. I can’t be the first person to run into this, if not with Docker with something else.
I can’t help with the specific issue, but I think it is more Docker specific, so maybe Stack Overflow or something similar has a better audience for it?
What I can offer is to suggest the new feature where you can have CIFS/SMB shares as sources, which was added to 2.1.0.110:
It is a bit clunky because the UI does not support it yet, but if you use the ngax UI, you can manually edit the source paths and type in the new format.
Using this, you do not need the folders to be pre-mounted, as the connection is done directly from Duplicati when the backup runs.
Step 3: Edit /etc/crontab to include the following:
@reboot root /usr/bin/startduplicati.sh
That’s it. I could probably change the sleep time to something less, but I’m okay with leaving it as it. I just want it to come up. Adding the /bin/sleep to the docker systemd unit file didn’t work so I suspect there’s some kind of timing issue going on with docker itself starting and the container accessing the SMB share. I’m happy, all is good, I’m leaving this here for anyone else since this problem has 100’s of posts and few with fixes and none of them worked for me.
“volume2” is the local storage on the Duplicati machine that I’m using to backup my NAS. The whole goal of this machine, and Duplicati, is to backup my NAS.