When systemd.automount helps

The idea in one line

A practical NFS example

Reload and enable the generated units

Verify that the automount exists before the real mount

Trigger the mount on first access

Test the idle unmount

Troubleshooting tips that actually help

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

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

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

4) Avoid nested automounts

5) Be careful with background NFS mounts

A second example for a read-mostly archive share

How I decide between plain mount and automount

References

Final thought 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: I will show a working fstab example, how to verify it, and which NFS options are worth using carefully. This pattern is especially useful for: 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. A normal NFS line mounts the share during boot. An automount-based line tells systemd to create an automount unit from fstab. 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. Create the mount point first: Then add this to /etc/fstab: 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. After editing fstab, reload systemd and start the automount unit: You can derive the unit name from the path with: 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. Check the automount unit: Or list just automount units: At this point, the automount should be active even if the real NFS mount is not mounted yet. You can confirm that with: Depending on timing, you may see the autofs placeholder first. The real NFS mount appears after first access. Then inspect it again: 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. If you set x-systemd.idle-timeout=10min, stop touching the path and wait. 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. 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. 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. 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. 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: instead of stacking automounts inside one another. 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. For a mostly read-only archive, I would still stay conservative with integrity-related behavior: I use a regular mount when: I use x-systemd.automount when: 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. 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. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse