NFS exports and mounts that fail safely

NFS is one of the oldest tools in a Linux operator's kit, and one of the easiest to get almost right. A share that mounts is not the same as a share that behaves well when the network blinks, when a client misbehaves or when the filer reboots. Here are the settings and checks that make the difference, on both sides of the mount.

Why shared files go wrong

The usual reason for NFS is a group of web or application servers that must see the same files: uploaded media, generated assets, a shared document tree. It gets set up quickly, often by copying an example, and it works on the first try. The problems show up later. An export open to a whole network lets a forgotten test machine write to production content. A client mounted with options that give up on errors silently loses writes. A server that cannot reach its filer at boot hangs for minutes instead of starting without the share. None of these is visible on the day it is configured.

On the filer: export to names, squash root

Export each share to the hosts that need it, by name, with the narrowest rights that work:

# /etc/exports
/export/web   web1.example.internal(rw,sync,root_squash,no_subtree_check) \
              web2.example.internal(rw,sync,root_squash,no_subtree_check)
/export/media media-reader.example.internal(ro,sync,root_squash,no_subtree_check)

Named hosts, not networks. A wildcard or a whole subnet means every machine that ever lands on that network can mount the share. Listing hosts makes each client a deliberate decision.

root_squash. Root on a client becomes an unprivileged user on the filer. Without it, anyone with root on any client owns every file on the share.

sync. The server acknowledges a write only after it is committed to stable storage. The faster alternative acknowledges writes that a power loss could still erase.

Apply and check what is actually exported, which is not always what you think you wrote:

exportfs -ra
exportfs -v

Then restrict the service at the host firewall to the same clients. With firewalld, a dedicated zone keeps it readable:

firewall-cmd --permanent --new-zone=nfsclients
firewall-cmd --permanent --zone=nfsclients --add-source=<client address>
firewall-cmd --permanent --zone=nfsclients --add-service=nfs
firewall-cmd --reload

Exports and firewall rules are two independent locks. Use both.

On the client: hard mounts that do not hang the boot

The client side decides what happens when the filer is slow or briefly unreachable:

# /etc/fstab
filer.example.internal:/export/web  /srv/web  nfs  hard,proto=tcp,timeo=600,retrans=2,_netdev,nofail,x-systemd.mount-timeout=30  0 0

hard, not soft. A hard mount retries until the server answers. A soft mount returns an error after a number of retries, and many applications do not check that error on write, so data can be lost without anyone being told. If a share holds anything you care about, mount it hard. The price is that a process touching the share waits while the filer is away, which is the honest behaviour.

_netdev and nofail. The mount waits for the network, and a missing filer does not stop the server from booting. Combined with a mount timeout, the machine comes up, the application can report the missing share clearly, and the mount completes when the filer returns.

Pin the protocol you tested. Clients and servers negotiate a protocol version. Set the one you tested explicitly (nfsvers= or vers=) so an update on either side cannot quietly change locking and caching behaviour under you.

Check what was actually negotiated, not what you asked for:

nfsstat -m
findmnt -t nfs,nfs4
mountstats /srv/web

mountstats shows per operation counts, retransmissions and round trip times. A growing retransmission count is the early warning that the network path or the filer needs attention.

Redundancy on the wire, snapshots on the disk

A filer is only as available as its network links. Connect it with bonded links into a pair of switches, hash the bond on addresses and ports so both links carry traffic, and keep filer and clients on the same Layer 2 segment where you can. A switched path has fewer moving parts than a routed one and keeps file traffic inside the private network.

On the storage side, a checksumming filesystem with snapshots changes how you handle mistakes. With ZFS, for example:

zfs snapshot tank/web@before-deploy
zfs list -t snapshot
ls /export/web/.zfs/snapshot/before-deploy/

A snapshot before every deployment or bulk change makes a bad change reversible in seconds, and a hidden snapshot directory lets an administrator copy back a single file without a restore job.

When a file share is the wrong answer

NFS is excellent for content written occasionally and read by many. It is a poor home for a database's data files, for workloads that lock heavily across clients, or for millions of tiny files rewritten constantly. Those belong on block storage. When a library outgrows file serving, move it, count and checksum every file on both sides before cutover, and keep the original as the rollback until the new copy has been proven in use.

A short checklist for your own shares

• exportfs -v lists only named hosts, with root_squash and sync.
• The firewall allows NFS only from those hosts.
• Every client mount is hard, with _netdev, nofail and a pinned protocol version.
• nfsstat -m on each client shows the options you intended.
• Retransmissions in mountstats are near zero and not growing.
• The filer has redundant links, and you have tested losing one.
• Snapshots exist, and backups are pulled separately.

How we do it

Our file services run on ZFS over volumes from our all-flash SAN, connect over bonded links into a switch pair on the same private segment as their clients, and are updated into a new boot environment so the previous one stays bootable until the update is proven.

If your shared storage was set up quickly and has never been looked at since, we are happy to review it with you.

Talk to an engineer

Related: NAS file services, NFS and SMB · Enterprise SAN storage on HPE 3PAR, all-flash · Disaster recovery and cross-site replicas