I’m running into a problem at writing a systemd unit file to mount a remote storage (webdav/Nextcloud) with rclone. Following command in bash is desired and works as expected:
/usr/bin/rclone mount nextcloud:/ $HOME/.mnt/nextcloud --daemon --vfs-cache-mode full
The resulting systemd unit file resides in ~/.config/systemd/user/rclone-mount-nextcloud.service and looks like this:
[Unit]
Description=Mounts a WebDAV directory with rclone
Documentation=man:rclone(1)
[Service]
Type=notify
ExecStart=/usr/bin/rclone mount nextcloud:/ $HOME/.mnt/nextcloud --daemon --vfs-cache-mode full
ExecStop=/usr/bin/fusermount -u $HOME/.mnt/nextcloud
RestartSec=5
[Install]
WantedBy=default.target
I know, but how do I find out what exactly the command expansion from ExecStart= looks like? I’ve searched in man(5)systemd.service but could only learn what is allowed. And it doesn’t seem I did something forbidden in my unit file. Nevertheless it’s astonishing that two equal (after shell expansion) commands result in different errors - therefore there must be a difference for systemd.
When changing the line to
/usr/bin/rclone mount nextcloud:/ ${HOME}/.mnt/nextcloud --daemon --vfs-cache-mode full
again it exits with
rclone-mount-nextcloud.service: Failed with result 'protocol'.
Obviously “/home/user” equals “${HOME}” equals not “$HOME”.
Sorry, but this can’t help me. Expanding any variables in a PreExecStart through bash is futile (I just tested it to be sure) because they’re expanded by bash which obviously differs from expansion by systemd. Since I can’t read C and lack any programming skills this is a dead end for me.
I’ll try someting else.
Okay, wrapping the command in bash -c ‘command’ again fails with result protocol. Seems to me there’s something amiss with systemd.
Good idea, but indeed it is not. I just solved it by working around it. Which is unsatisfying but at least I have a working and robust solution.
I did the following:
switched $HOME with /home/user
removed the flag –daemon and
removed ExecStop=…
It now works as intended. Problem solved although I can’t tell why exactly because from a bash perspective (which is the only one I have) it still is exactly the same.