Issues with SystemD Automount for NFS Shares

[JFrahm]

I used autofs for a several years to mount local network NFS shares. That would get things going on a new machine or fresh install with a small amount of work, but once set up it was rock solid and I never had any issues.

Not too long ago, autofs moved from the official repositories to the AUR. Still worked fine. Then this year, the AUR package started dropping unverified PGP signature errors when trying to update. I left it unupdated for a while, but figured that was a sign that I should probably be migrating to newer systemd automounts.

I got a new machine a while ago, and still got the error trying to install autofs from the AUR. So I looked into systemd automount via fstab. Here’s an example line:

Server:/media/Server/Download  /media/Server/Downloads  nfs  noauto,x-systemd.automount 0 0

That works generally well, and is faster/easier to set up on a new machine or fresh install. However, if “Server” is powered off, or if the client machine has no network access, I get some problems. There is a hang of roughly 10 seconds on login (boot seems fine) compared to login/boot with those fstab entries commented out. Starting up a file manager (I’m in gnome, so nautilus) for the first time after login takes much longer than usual – roughly 30 seconds to 1 minute compared to instant without those fstab entries. And nautilus will also include “filesystem root” and “home” partitions listed in the left panel along with network shares.

With autofs, I had no problems like that. It manages the mounting so that the system doesn’t even try to mount them until/unless I cd or navigate the file manager into the mount points. That is much better behavior even for desktop machines that are almost always on, and basically required for a laptop that I take to other locations where the local “Server” IPs aren’t available, etc.

I thought that the “noauto” line in the fstab entry was supposed to mount only when the mountpoint is accessed, ala autofs, but it seems that is wrong? Arch wiki mentions _netdev option so that systemd knows that the mount is network dependent, but I don’t seem to have problems at boot, so it seems like that isn’t the answer? Maybe I need to add x-systemd.mount-timeout=1s or something, but then I’m not sure if it will try to mount again if I navigate to the mountpoint later (as autofs did)?

I also tried migrating the fstab entries into systemd modules in /usr/lib/systemd/system with one .mount and one .automount module, and systemctl enable-ing only the .automount module (which was suggested in another forum after some google searching), but that seemed to result in the same behavior as the fstab entries.

Anyone know what I need to do to get the better behavior that I had with autofs in addition to the ease and convenience of the systemd automount fstab entries? Thanks!

[linux-aarhus]

I had similiar headaches until I migrated fstab entries to mount units.

• [root tip] Use systemd to mount ANY device
• [root tip] systemd mount unit samples

[Mirdarthos]

Hi @JFrahm, and welcome!

Please see [root tip] Use systemd to mount ANY device and [root tip] systemd mount unit samples.

I, myself, have used them to great effect!

Hope it helps!

[JFrahm]

OK, I set up those mount units before but was getting the same behavior as with stab entries. However, I think my modules don’t have exactly the same options as in those links you sent – I will try editing them to match and get back to you - thanks.

I also just tried a different fstab line that had the same problems:

Server:/media/Server/NAS  /media/Xuande/NAS  nfs  nofail,x-systemd.automount,x-systemd.device-timeout=50ms,_netdev 0 0

So the nofail, very short timeout, and netdev didn’t do the trick.

[linux-aarhus]

Yes I know - everyone thinks I’m crazy - because you can do the same in fstab.

The weird thing is - systemd converts the fstab entries to mount units - yet you are supposed to figure out a complicated set of options which because only (,) is allowd as separator - quickly becomes unreadable and the possibility of errors is very likely if you are not 30year master of fstab.

With network shares I had a hard time figuring out the right set of options to avoid errors on system start and to mount the shares when network was up and the shares available and accessible on demand.

When I found out about mount units - it became a walk in the park.

The mount unit defines the mount - the real options it takes for the share to be accessible (don’t think automount here).

When the share works - when you start the unit - then you can supplement the mount unit with an automount unit - and the magic happens.

[JFrahm]

I’m still getting the same weird behavior at login with everything in mount and automount units. The way I had the units set up before, I had just copied the fstab options, so: (filename media-Yuanzhi-teaching.mount)

[Unit]
Description=Mount Yuanzhi/Teaching
# After=network-online.target
# Wants=network-online.target

[Mount]
What=Yuanzhi:/media/Yuanzhi/Teaching
Where=/media/Yuanzhi/Teaching
Type=nfs
Options=noauto,x-systemd.automount

[Install]
WantedBy=multi-user.target

To match the links, I only needed to change the Options line: (same file)

Options=_netdev,auto

That will mount the share fine with a systemctl start media-Yuanzhi-Teaching.mount , but if I enable the .automount unit (systemctl enable media-Yuanzhi-Teaching.automount – the .mount unit is disabled so it doesn’t run at boot) and the server machine (Yuanzhi) is powered down/unavailable, I get the same slowdown/weirdness at login. The .automount units are just like in your links, except that I comment out the TimeoutIdleSec=10, because I want the shares to stay mounted indefinitely. For example (filename media-Yuanzhi-Teaching.automount):

[Unit]
Description=Automount Yuanzhi/Teaching
ConditionPathExists=/media/Yuanzhi/Teaching

[Automount]
Where=/media/Yuanzhi/Teaching
#TimeoutIdleSec=10

[Install]
WantedBy=multi-user.target

What am I doing wrong?

[linux-aarhus]

The mount unit cannot be enabled at the same time as the automount unit.

If it is - the automount unit will fail.

The automount unit will enable the mount unit on demaind - that is what the automount unit is for.

Don’t set the the x-systemd.automount in your mount unit - that is an error

Options=_netdev,auto

[Unit]
Description=Data

[Mount]
What=nas.net.nix.dk:/volume1/data
Where=/data/nfs/data
Type=nfs
Options=_netdev,vers=4,rsize=32768,wsize=32768
TimeoutSec=30

[Install]
WantedBy=multi-user.target

[Unit]
Description=Automount data share
ConditionPathExists=/data/nfs/data

[Automount]
Where=/data/nfs/data
TimeoutIdleSec=60

[Install]
WantedBy=multi-user.target

_netdev option implies that network is up and systemd will delay the mount until network is up and running.

.automount unit enables .mount unit on demand - so only enable .automount unit for network shares

[JFrahm]

Yep, I figured that noauto,x-systemd.automount were incorrect in the .mount unit Options line – I did edit them to be _netdev,auto but was/am still getting the same slowdown. However, I will change the options to closer to your example (_netdev,vers=4) and add TimeoutSec=1 (local shares, so 1 second should be plenty) and see how that goes.

Thanks again, I do appreciate the assistance and bearing with me! I will give that a go after a reboot.

[JFrahm]

I think that did the trick! I tried updating the mount unit and automount unit for 2 separate shares, 1 that is currently powered on, and 1 that is currently powered off. Basic gist of the files for anyone coming here later via search:

Mount unit (Filename $YOUR_MOUNT_PATH.mount) in /usr/lib/systemd/system/:

[Unit]
Description=Mount ($SHARENAME)

[Mount]
What=$SERVER:$SHAREPATH
#Can get $SHAREPATH from showmount -e $SERVER
Where=$YOUR_MOUNT_PATH
Type=nfs
Options=_netdev,vers=4
TimeoutSec=1

[Install]
WantedBy=multi-user.target

And Automount unit (Filename $YOUR_MOUNT_PATH.automount) in /usr/lib/systemd/system/:

[Unit]
Description=Automount $SHARENAME
ConditionPathExists=$YOUR_MOUNT_PATH

[Automount]
Where=$YOUR_MOUNT_PATH
TimeoutIdleSec=60
#Can change TimeoutIdleSec
#Nautilus will have 1 link to the share before navigating to the share or after timeout
#Nautilus will have 2 links to the share while it is actively mounted by the module

[Install]
WantedBy=multi-user.target

Then enable the automount unit (sudo systemctl enable $YOUR_MOUNT_PATH.automount) but NOT the mount unit (the file must sit in /usr/lib/systemd/system but remain disabled).

With that setup for the 2 shares (1 powered on and 1 powered off), I can boot and login normally, without the delay at login or the 1st time running a file manager, and without the weird extra links to “Filesystem root” and “home” (local partitions) showing up in the file manager.

I am guessing that adding the TimeoutSec and/or adding vers=4 to the Options line in the mount unit was what fixed the issues I was having. Anyway, seems to be all good now, so I will mark your post as the solution. Thanks much!

[linux-aarhus]

Great

You don’t have to place the unit in /usr - /etc/systemd/system suffice for local units

[JFrahm]

Ah, good to know. I was doing that before, but another forum post I found when trying to troubleshoot this said that the /usr path was correct. I’ll move them into /etc like I was used to before.