Make systemd automount wait for tmpfiles

[shrewd perch]

My system is an immutable system based on definitions that build an image every night (using cleanroom )

I have a number of directories that are automounted by systemd as they are required. These are then symlinked into users home directories e.g. ~/documents/video -> /mnt/video

The client fstab line for that looks like:

<server>:/opt/video/ /mnt/video nfs nfsvers=3,users,noauto,nolock,x-systemd.automount,x-systemd.mount-timeout=10,timeo=14,_netdev 0 0

The problem is that, after login, it takes a good minute or two for these directories to become available and anything that uses them early on in a user session hangs until they become available.

My suspicion is that this is happening due to a race between systemd.automount and tmpfiles being created. The output of "systemctl status systemd-tmpfiles-setup.service" includes messages like:

Sep 06 14:40:48 <hostname> systemd-tmpfiles[520]: Skipping /mnt/video```

Is there a simple way to make sure that the automount/fstab stuff doesn't happen until after the tmpfiles are created? Or the other way round if that's the issue...

[clever basin]

i know that if you have mounts that aren't absolutely required, you can make it so that the boot process doesn't wait on those mounts before continuing
nofail mount option does this

idk if that would help

with nofail the mounts will still be done but there's no guarantee if it succeeds or when it occurs in the boot process

[shrewd perch]

That's not exactly what the problem is - the issue is that having systemd.automount (which I defaintely want) seems to cause a delay to being able to mount these drives for a couple of minutes and that causes freezing on a couple of apps that access them shortly after login. Having said all that - you did make me think it might be worth having the one most used automount which will, if all goes well, make it available straight away and, while not fixing the problem, make it not a problem...

[shrewd perch]

Having one of the shares automount at boot just cause the boot to take more than a minute longer than normal. In every other way it works as expected, but that's too long a boot...