OTOthoTools
Language
enen-AUen-GBen-CAdede-CHithipt-BRnlno
↔

NFS Entry Builder

Generate resilient mount entries
Resultfstab
10.20.0.15:/srv/shared  /mnt/shared  nfs  rw,hard,_netdev,nofail,x-systemd.automount,nfsvers=4.2,timeo=600,retrans=2  0  0
  • ✓hard prevents silent data corruption during server interruptions.
  • ✓_netdev and systemd automount avoid early-boot mount failures.

Introduction

The NFS Entry Builder produces an fstab line for an NFS share using options that make the mount resilient: hard instead of soft, _netdev so boot waits for networking, nofail so a missing share does not block boot, and x-systemd.automount for on-demand mounting.

Hard mounts retry requests until the server answers; soft mounts can return errors that applications misread as real I/O failures, which is why hard is the recommended default for most workloads.

Objective

  • Generate a correct, complete fstab line from server, export, mount point and NFS version.
  • Apply production-oriented defaults: hard, _netdev, nofail, automount, timeo and retrans.
  • Warn when NFSv3 is chosen, since it requires rpcbind and extra firewall rules.

Inputs

  • NFS server hostname or IP.
  • Export path on the server (for example /srv/shared).
  • Local mount point (for example /mnt/shared).
  • NFS version: 4.2, 4.1, 4 or 3.

How it works

The tool assembles the six fstab fields: server:export as the device, the mount point, the filesystem type nfs, the option list, 0 for dump and 0 for fsck pass.

The option list is built from the inputs: rw, hard, _netdev, nofail, x-systemd.automount, nfsvers=<version>, timeo=600 and retrans=2. timeo and retrans tune how long the client waits and how often it retries before giving up.

If NFSv3 is selected, a warning is added because NFSv3 relies on rpcbind and opens additional ports on the server firewall; NFSv4 is preferred when the server supports it.

Testable example

Try it — the analysis runs locally in your browser.

Example

Server: 10.20.0.15
Export: /srv/shared
Mount:  /mnt/shared
Version: 4.2

Expected output

10.20.0.15:/srv/shared  /mnt/shared  nfs  rw,hard,_netdev,nofail,x-systemd.automount,nfsvers=4.2,timeo=600,retrans=2  0  0
Result: no critical issue detected.

Reading the output

  • The generated line can be appended to /etc/fstab as-is, then mounted with sudo mount -a.
  • The good findings confirm that hard and _netdev are present — those two options prevent the two most common NFS failure modes.
  • If a warning about NFSv3 appears, check whether the server supports NFSv4 before accepting it.

Risks

  • hard mounts never give up: if the server disappears permanently, processes can hang until the server returns or the mount is unmounted.
  • Automounting defers the mount until first access, which changes behaviour for services that expect the path at boot.
  • Pasting a generated line into /etc/fstab without testing can break boot on a production server.

Limitations

  • The tool does not test connectivity, exports or authentication (NFSv4 Kerberos, for example).
  • Options are a sensible baseline, not a universal best practice — high-latency or special workloads may need different timeo/retrans values.
  • It does not generate /etc/exports entries for the server side.

Official references

FAQ

Why hard instead of soft?

A soft mount can return an error after a timeout even when the server is merely slow, and applications often treat that error as real I/O failure. Hard mounts keep retrying, which is safer for data integrity in most cases.

What does nofail do?

nofail tells the system to continue booting even if this mount fails, instead of dropping into emergency mode. It is essential for optional shares.

What is x-systemd.automount?

It makes systemd mount the share on first access rather than at boot, so a slow or unavailable server does not delay boot. The mount point exists immediately; the actual mount happens lazily.