Mounting NFS shares robustly: hard versus soft, timeo, and what happens when the server disappears

Goal

Mount an NFS export in a way that survives an unresponsive server and a normal reboot, and know which package and version to use on RHEL versus Debian/Ubuntu.

Prerequisites

• Root for mounting. Client packages: nfs-utils on RHEL/Fedora, nfs-common on Debian/Ubuntu.
• The export path and server address; showmount -e <server> lists the server's exports (requires mountd/rpcbind reachable, mainly relevant to NFSv3).

Steps

1. Check what the server offers: showmount -e nfsserver. showmount depends on mountd/rpcbind and may show nothing against an NFSv4-only server even though mounts work. NFSv4 presents the exports in one pseudo-filesystem and does not need rpcbind; NFSv3 needs rpcbind, and the client falls back to it only if the server does not offer NFSv4 or vers=3 is set.
2. Mount once manually to test: mount -t nfs -o vers=4.2 nfsserver:/export /mnt/data (without vers=/nfsvers=, mount -t nfs negotiates the highest version both sides support; vers=4.2 fails if the server does not offer 4.2).
3. Choose the failure behavior deliberately in /etc/fstab:
   • hard (the default): I/O on the mount blocks and retries indefinitely if the server stops responding; a process stuck in an NFS call in this state generally ends only with SIGKILL (the legacy intr option is ignored since kernel 2.6.25). This protects against silent data loss on a transient outage.
   • soft: I/O gives up after retrans= retransmissions (each waiting timeo= deciseconds, with linear backoff over TCP) and returns an error to the application — appropriate only where the application already handles I/O errors correctly, since soft can silently corrupt state that assumed writes succeeded.
   • Over TCP the defaults are already timeo=600 (60 seconds) and retrans=2; raise retrans= to widen the window before a soft mount gives up on flaky links.
4. Network ordering: systemd already recognizes nfs/nfs4 as network filesystems and orders them after the network; _netdev is only needed when that detection fails (e.g. iSCSI-backed filesystems) and is harmless on an NFS line.
5. To avoid a boot hanging when the NFS server is down, add x-systemd.automount,x-systemd.mount-timeout=30 to the entry's options: the mount is only triggered on first access, with a bounded timeout, instead of blocking the boot sequence (nofail alone also stops boot from waiting for it). After editing fstab run systemctl daemon-reload.
6. Mount everything from fstab and verify: mount -a, then mount | grep nfs and nfsstat --client for client-side RPC statistics (retransmissions here indicate an unstable path even when the mount looks up).

Expected result

The share is reachable, mount -a completes without hanging, and a deliberately stopped NFS server produces the chosen behavior (indefinite retry for hard, a bounded error for soft) rather than an unplanned boot hang.

Limits and test basis

Options verified against nfs(5), mount.nfs(8) and systemd.mount(5) (_netdev, x-systemd.automount). Undo: comment out or remove the fstab line and umount /mnt/data; no data on the client is affected by unmounting.