How to troubleshoot systemd automount error?

Question

I have written the following automount unit for systemd:

/etc/systemd/user/home-federico-Cloud-unipg.automount
-----------------------------------------------------
[Unit]
Description="automount"

[Automount]
Where=/home/federico/Cloud/unipg

[Install]
WantedBy=default.target

The mount unit is:

/etc/systemd/user/home-federico-Cloud-unipg.mount
-------------------------------------------------
[Unit]
Description="mount"

[Mount]
Type=rclone
What=unipg:
Where=/home/federico/Cloud/unipg
Options=vfs-cache-mode=full,config=/home/federico/.config/rclone/rclone.conf,cache-dir=/var/rclone

---

After --user reloading the systemd daemon, I run the command systemctl --user enable --now home-federico-Cloud-unipg.automount and I get the following error in systemctl status:

home-federico-Cloud-unipg.automount: Failed with result 'resources'.
Failed to set up automount "automount".

The command journalctl -xe is not helpful since it says:

A start job for unit UNIT has finished with a failure.

---

The mount unit is working because if I run systemctl --user start home-federico-Cloud-unipg.mount I get the storage correctly mounted, so the problem is somewhere in the automount part.

Moreover, if I repeat the process as a system instance instead of user instance (replacing default.target with multi-user.target) I get the thing to work, even though the mountpoint is not accessible to user.

Can somebody help me to troubleshoot this?

Answer 1

Your 'user' service manager runs unprivileged and is not allowed to mount most things. Overall it has the same privileges as you, so it can do FUSE-based mounts, but not most types of kernel mounts – which means it cannot establish the magic autofs mounts, either.

Use a system-level mount+automount, with the FUSE allow_other mount option (which will need to be enabled via /etc/fuse.conf before you can use it), together with the rclone uid= option so that the filesystem's contents become accessible by you.

Raising the service manager's log level (systemctl --user log-level debug) would be the usual first step to troubleshooting issues – the same applies to any other service; most of them have the option to enable verbose logging.

But sometimes you may need to do things like attach strace -p <pid> to the service (the systemd --user process) and look for "EPERM" and similar errors.