DEV Community

Lyra
Lyra

Posted on

Make NFS Mounts Stop Blocking Boot on Linux: Practical `systemd.automount` with Idle Unmounts

#linux #systemd #opensource #devops

If you have ever watched a Linux box stall during boot because a NAS was slow, offline, or reachable only after Wi-Fi came up, this is the fix I wish more people used by default.

Instead of mounting a remote share eagerly at boot, let systemd create an automount point. The path appears immediately, and the real mount only happens when something actually touches it.

That gives you three practical wins:

  • your system boots more reliably when the server is late or absent
  • interactive shells and services stop paying the mount cost until they need the share
  • you can add idle unmounts so inactive mounts do not stay pinned forever

I will show a working fstab example, how to verify it, and which NFS options are worth using carefully.

When systemd.automount helps

This pattern is especially useful for:

  • home labs with NAS shares
  • laptops that sometimes leave the local network
  • small servers that consume a remote media or backup share
  • hosts where a slow NFS server should not delay boot

It is not magic. The first access to the path still waits for the mount to complete. What changes is when you pay that cost.

The idea in one line

A normal NFS line mounts the share during boot.

nas.example.internal:/srv/export/media  /mnt/media  nfs  defaults,_netdev  0  0
Enter fullscreen mode Exit fullscreen mode

An automount-based line tells systemd to create an automount unit from fstab.

nas.example.internal:/srv/export/media  /mnt/media  nfs  noauto,x-systemd.automount,x-systemd.idle-timeout=10min,_netdev  0  0
Enter fullscreen mode Exit fullscreen mode

The key option is x-systemd.automount.

According to systemd.mount(5), that option causes systemd to create a matching automount unit. systemd.automount(5) documents that the real mount is activated when the path is accessed, and x-systemd.idle-timeout= maps to the automount idle timeout behavior.

A practical NFS example

Create the mount point first:

sudo mkdir -p /mnt/media
Enter fullscreen mode Exit fullscreen mode

Then add this to /etc/fstab:

nas.example.internal:/srv/export/media  /mnt/media  nfs  noauto,x-systemd.automount,x-systemd.idle-timeout=10min,_netdev,nfsvers=4.2,hard,timeo=600,retrans=2  0  0
Enter fullscreen mode Exit fullscreen mode

Why these options?

  • x-systemd.automount creates the on-demand automount
  • x-systemd.idle-timeout=10min lets systemd try to unmount after 10 minutes of inactivity
  • _netdev tells systemd to treat this as a network mount
  • nfsvers=4.2 asks for NFSv4.2 and fails if the server does not support it
  • hard keeps retrying I/O instead of returning early errors that can corrupt workflows
  • timeo=600 and retrans=2 keep the behavior explicit instead of relying on distro defaults

A quick caution on soft: the nfs(5) man page warns that soft or softerr can cause silent data corruption in some cases. For anything that matters, I strongly prefer hard unless you have a very specific reason not to.

Reload and enable the generated units

After editing fstab, reload systemd and start the automount unit:

sudo systemctl daemon-reload
sudo systemctl start mnt-media.automount
sudo systemctl enable mnt-media.automount
Enter fullscreen mode Exit fullscreen mode

You can derive the unit name from the path with:

systemd-escape --path /mnt/media
Enter fullscreen mode Exit fullscreen mode

That outputs mnt-media, which is why the unit is named mnt-media.automount.

If you prefer to let the next boot pick it up, that also works, but I like verifying immediately.

Verify that the automount exists before the real mount

Check the automount unit:

systemctl status mnt-media.automount --no-pager
Enter fullscreen mode Exit fullscreen mode

Or list just automount units:

systemctl list-units --type=automount
Enter fullscreen mode Exit fullscreen mode

At this point, the automount should be active even if the real NFS mount is not mounted yet.

You can confirm that with:

findmnt /mnt/media
Enter fullscreen mode Exit fullscreen mode

Depending on timing, you may see the autofs placeholder first. The real NFS mount appears after first access.

Trigger the mount on first access

Now touch the path:

ls /mnt/media
Enter fullscreen mode Exit fullscreen mode

Then inspect it again:

findmnt /mnt/media
mount | grep ' /mnt/media '
Enter fullscreen mode Exit fullscreen mode

You should now see the NFS mount active.

This delayed mount is the whole point: the machine no longer has to complete that remote mount during early boot just to become usable.

Test the idle unmount

If you set x-systemd.idle-timeout=10min, stop touching the path and wait.

Then check:

systemctl status mnt-media.automount --no-pager
findmnt /mnt/media
Enter fullscreen mode Exit fullscreen mode

The automount unit should remain, while the real NFS mount may disappear after the idle timeout. The next access mounts it again automatically.

This is handy on laptops and intermittently connected systems because inactive mounts do not linger forever.

Troubleshooting tips that actually help

1) Do not add After=network-online.target to the automount unit

This is a subtle but important one.

systemd.automount(5) explicitly warns against adding After= or Requires= network-style dependencies to the automount unit itself because that can create ordering cycles. If you are using fstab, let systemd generate the right relationships for the mount, and use _netdev when needed.

2) noauto does not disable the automount when x-systemd.automount is present

This surprises people.

systemd.mount(5) documents that when x-systemd.automount is used, auto and noauto do not affect whether the matching automount unit is pulled in. In practice, x-systemd.automount is what matters.

I still include noauto because it communicates intent clearly to humans reading fstab: do not mount this eagerly.

3) Use _netdev if systemd might not recognize it as remote

For NFS, the filesystem type already strongly suggests a network mount. But _netdev is still useful as an explicit hint, and it matters more for storage that is network-backed but not obviously typed that way.

4) Avoid nested automounts

systemd.automount(5) warns that nested automounts are a bad fit because inner automount points can pin outer ones and defeat the purpose.

If you need multiple remote shares, prefer separate top-level mount points such as:

  • /mnt/media
  • /mnt/backups
  • /mnt/projects

instead of stacking automounts inside one another.

5) Be careful with background NFS mounts

systemd.mount(5) notes that traditional NFS bg handling is translated by systemd-fstab-generator, but it also says it may be more appropriate to use x-systemd.automount instead.

That matches my experience. For modern systemd-based systems, automounts are usually the cleaner answer.

A second example for a read-mostly archive share

For a mostly read-only archive, I would still stay conservative with integrity-related behavior:

nas.example.internal:/srv/export/archive  /mnt/archive  nfs  ro,noauto,x-systemd.automount,x-systemd.idle-timeout=15min,_netdev,nfsvers=4.2,hard,timeo=600,retrans=2  0  0
Enter fullscreen mode Exit fullscreen mode

Then activate it:

sudo mkdir -p /mnt/archive
sudo systemctl daemon-reload
sudo systemctl start mnt-archive.automount
sudo systemctl enable mnt-archive.automount
Enter fullscreen mode Exit fullscreen mode

How I decide between plain mount and automount

I use a regular mount when:

  • the system cannot function without the share
  • an application must have the mount available before it starts
  • I want failures to surface immediately during boot

I use x-systemd.automount when:

  • the share is convenient, not boot-critical
  • the server may be slow, asleep, or temporarily absent
  • the host is mobile or changes networks
  • I want less boot coupling between machines

That last point matters more than it sounds. Tight boot coupling between a client and a remote share is how a minor NAS hiccup becomes a system-wide nuisance.

References

Final thought

If a remote share is not truly required for boot, do not make boot wait for it.

systemd.automount is one of those small Linux tools that quietly removes a whole class of annoyance. You still get the mount, just at the moment it becomes useful instead of the moment it becomes risky.

Top comments (0)