Mount an NFS share on Linux with mount -t nfs server:/path /mnt/local for a one-off, and add it to /etc/fstab with _netdev and nofail for a persistent mount that survives reboot. The two options are mandatory. _netdev waits for the network. nofail prevents boot hangs if the server is unreachable. The team that has both options has a reliable mount.
Table of contents
- The right mount command
- The right fstab entry
- The _netdev and nofail options
- NFSv3 vs NFSv4 syntax
- Setting the right timeout values
- Verifying the mount is working
- FAQ
The right mount command
The right command to mount an NFS share:
sudo mkdir -p /mnt/nfs
sudo mount -t nfs server.example.com:/export/data /mnt/nfsThe -t nfs flag tells the kernel to use the NFS filesystem driver. The server:/path is the NFS server hostname and the export path. The /mnt/nfs is the local mount point.
The right answer for NFSv4 is -t nfs4 and a single leading slash:
sudo mount -t nfs4 server.example.com:/ /mnt/nfsNFSv4 changes the path format — the export root is just / on the server, and subdirectories are accessed normally. The right answer for a new server is to use NFSv4 unless the server only supports NFSv3.
The right fstab entry
The right fstab entry for a persistent NFS mount:
server.example.com:/export/data /mnt/nfs nfs defaults,_netdev,nofail,timeo=900,retrans=5 0 0The fields are: source, mountpoint, filesystem type, options, dump, pass. The right answer for the source is the server hostname (resolved through DNS) and the export path. The right answer for the type is nfs (or nfs4 for NFSv4 only). The right answer for the options includes _netdev and nofail.
After editing fstab, test the config without rebooting:
sudo mount -aThis mounts everything in fstab that is not already mounted. The right answer is to verify with mount | grep nfs that the share is mounted. The wrong answer is to reboot to test — if the config is wrong, the boot hangs.
The _netdev and nofail options
The _netdev option tells the kernel to wait for the network before attempting the mount. Without it, the mount tries to run before the network is ready, fails, and marks the mount as failed in fstab.
The nofail option tells systemd to continue boot even if the mount fails. Without it, a failed mount drops the system into emergency mode, which is a five-minute detour into the console for the operator.
The right answer for a production mount is to have both. The right answer for a development box where the share is critical is to use nofail anyway, because the alternative is a hard-to-debug boot hang.
NFSv3 vs NFSv4 syntax
NFSv3 mount syntax:
server.example.com:/export/data /mnt/nfs nfs defaults 0 0NFSv4 mount syntax:
server.example.com:/ /mnt/nfs nfs4 defaults 0 0The right answer for new deployments is to use NFSv4 unless you have a specific reason to use NFSv3. NFSv4 is more efficient (single connection), more secure (built-in Kerberos), and simpler (port 2049 only). The wrong answer is to leave the version unspecified and let the client and server negotiate — the negotiation sometimes picks NFSv3 if the server has both enabled, and the result is harder to debug.
Setting the right timeout values
The right NFS timeout is 90 seconds with 5 retries. The defaults are 7 seconds and 3 retries, which is too aggressive for most modern networks. The right way to set them is via the timeo and retrans options in fstab:
server:/export /mnt/nfs nfs defaults,timeo=900,retrans=5 0 0The timeo=900 is in deciseconds (900 = 90 seconds). The retrans=5 is the number of retries before the client gives up. The right answer is to set them higher than the defaults for reliability.
Verifying the mount is working
The right verification is three commands:
mount | grep nfs
df -h /mnt/nfs
ls -la /mnt/nfsmount | grep nfs shows the active mounts. df -h /mnt/nfs shows the disk space. ls -la /mnt/nfs shows the files. The right answer is to write a test file and read it back:
echo test | sudo tee /mnt/nfs/testfile
cat /mnt/nfs/testfile
sudo rm /mnt/nfs/testfileThe right answer for a network problem is to check dmesg | grep nfs for kernel-level errors, or journalctl -u nfs-client.target for systemd-level errors.
FAQ
Why is my mount not appearing after a reboot?
The most common cause is a missing _netdev option. The right fix is to add it. If the mount still does not appear, check systemctl status mnt-nfs.mount for the error.
Can I mount NFS as a non-root user?
Yes, but only if the mount point is owned by that user or if the user has the right permissions. The right answer is to use the user option in fstab to allow non-root mount.
How do I check what is currently mounted?
mount | grep nfs for NFS mounts specifically. findmnt for all mounts. findmnt /mnt/nfs for a specific mount.
What is hard vs soft mount?
Hard: client retries indefinitely if the server is unreachable. Soft: client returns an error after a timeout. The right answer is hard (the default). The wrong answer is soft, which can corrupt data.
How do I unmount?
sudo umount /mnt/nfs for normal. sudo umount -l /mnt/nfs for lazy. sudo umount -f /mnt/nfs for force, but only as a last resort.
Is NFS encrypted?
No. The right answer for encryption is NFSv4 with Kerberos or to mount over a VPN.
What is the performance difference vs iSCSI?
NFS is faster for file-level access. iSCSI is faster for block-level access. The right answer for a file server is NFS. The right answer for a block device is iSCSI.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: