[systemd-devel] Stacked automount dependencies

[Kenneth Porter]

I need to automount a couple cifs shares on a NAS box, with one share
mounted to a directory within another share:

/srv/share0/share1

I've created the unit files for .mount and .automount for the two shares,
with mount disabled and automount enabled and started. This seems to work
fine once the system is booted. But the share1 automount fails to start on
boot with the error "dependency". The share0 automount is started and works
when the mount point is later accessed, but not the share1 automount.

I don't know what to add to satisfy the boot-time dependency of
srv-share0-share1.automount.

From the boot log, it looks like the system is trying to actually mount

these shares. But the server they're being mounted from may not be up yet
when both are powering up together. That's why I'm using an automount.

Mar 26 18:29:14 saruman kernel: CIFS VFS: Error connecting to socket.
Aborting operation.
Mar 26 18:29:14 saruman kernel: CIFS VFS: cifs_mount failed w/return code =
-113
Mar 26 18:29:14 saruman mount: Unable to find suitable address.
Mar 26 18:29:14 saruman systemd: srv-share0.mount mount process exited,
code=exited status=32
Mar 26 18:29:14 saruman systemd: Failed to mount NAS1 share0.
Mar 26 18:29:14 saruman systemd: Dependency failed for Automount NAS1
share1.
Mar 26 18:29:14 saruman systemd: Job srv-share0-share1.automount/start
failed with result 'dependency'.

[Michael Chapman]

I need to automount a couple cifs shares on a NAS box, with one share mounted
/srv/share0/share1

This probably isn't going to work the way you want. Starting the share1
automount will itself cause share0 to be mounted, since systemd needs to
ensure that the share1 directory exists, and to mount an autofs
filesystem at this directory.

If you stack automounts in this way, the "inner" automount essentially
keeps the "outer" mount permanently in use.

I've created the unit files for .mount and .automount for the two shares,
with mount disabled and automount enabled and started. This seems to work
fine once the system is booted. But the share1 automount fails to start on
boot with the error "dependency". The share0 automount is started and works
when the mount point is later accessed, but not the share1 automount.
I don't know what to add to satisfy the boot-time dependency of
srv-share0-share1.automount.

From the boot log, it looks like the system is trying to actually mount

these shares. But the server they're being mounted from may not be up yet
when both are powering up together. That's why I'm using an automount.
Mar 26 18:29:14 saruman kernel: CIFS VFS: Error connecting to socket.
Aborting operation.
Mar 26 18:29:14 saruman kernel: CIFS VFS: cifs_mount failed w/return code =
-113
Mar 26 18:29:14 saruman mount: Unable to find suitable address.
Mar 26 18:29:14 saruman systemd: srv-share0.mount mount process exited,
code=exited status=32
Mar 26 18:29:14 saruman systemd: Failed to mount NAS1 share0.

So what's happening here is that systemd is trying to mount share0, which
is failing...

Mar 26 18:29:14 saruman systemd: Dependency failed for Automount NAS1 share1.
Mar 26 18:29:14 saruman systemd: Job srv-share0-share1.automount/start failed
with result 'dependency'.

... which means it can't start the automount inside it.

[Kenneth Porter]

--On Friday, March 30, 2018 2:25 PM +1100 Michael Chapman

Post by Michael Chapman
This probably isn't going to work the way you want. Starting the share1
automount will itself cause share0 to be mounted, since systemd needs to
ensure that the share1 directory exists, and to mount an autofs
filesystem at this directory.
If you stack automounts in this way, the "inner" automount essentially
keeps the "outer" mount permanently in use.

That makes sense. So what I really need is a way to start the nested
automount unit when the outer mount unit starts. The app will touch the
outer mountpoint causing it to mount and starting the inner automount unit.
The app may then navigate to the inner mountpoint and cause it to mount.
But I don't need the inner automount unit to start at boot. It just needs
to start when the outer mount completes.

So what can I put in either the outer mount unit or inner automount unit to
make the inner automount start when the outer mount completes?

[Andrei Borzenkov]

Post by Kenneth Porter
--On Friday, March 30, 2018 2:25 PM +1100 Michael Chapman

Post by Michael Chapman
This probably isn't going to work the way you want. Starting the share1
automount will itself cause share0 to be mounted, since systemd needs to
ensure that the share1 directory exists, and to mount an autofs
filesystem at this directory.
If you stack automounts in this way, the "inner" automount essentially
keeps the "outer" mount permanently in use.

That makes sense. So what I really need is a way to start the nested
automount unit when the outer mount unit starts.

Much easier is to use symlinks on outer filesystem that points into
auto-mounted inner filesystem.

Post by Kenneth Porter
The app will touch the
outer mountpoint causing it to mount and starting the inner automount unit.
The app may then navigate to the inner mountpoint and cause it to mount. But
I don't need the inner automount unit to start at boot. It just needs to
start when the outer mount completes.

What's wrong with *automount* started on boot? How are you going to
trigger mounting if automount is not available?

Post by Kenneth Porter
So what can I put in either the outer mount unit or inner automount unit to
make the inner automount start when the outer mount completes?

automount /outer
automount /inner
ln -s /outer/inner -> /inner

Again - what's wrong with it?