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 the nfs type, the _netdev option, and nofail for a persistent mount. The _netdev option tells systemd to wait for the network before mounting. The nofail option prevents boot hangs if the NFS server is unreachable. The team that has both options has a reliable mount that does not break boot.
Table of contents
- The right fstab entry for NFS
- Mounting temporarily with the mount command
- The _netdev and nofail options explained
- The right NFS server-side config
- Troubleshooting the access denied error
- NFSv4 vs NFSv3 in 2026
- FAQ
The right fstab entry for NFS
The right fstab entry for an NFS share looks like this:
server.example.com:/export/data /mnt/nfs nfs defaults,_netdev,nofail,x-systemd.automount,timeo=900,retrans=5 0 0The fields are: source, mountpoint, filesystem type, options, dump, pass. The source is the server hostname and the export path. The mountpoint is the local directory. The type is nfs (or nfs4 for NFSv4 only). The options include _netdev (wait for the network) and nofail (do not fail boot if the mount is unavailable).
The timeo=900 and retrans=5 options set the NFS timeout to 90 seconds and 5 retries. The defaults are 7 and 3, which is too aggressive for most modern networks and produces spurious mount failures. The right answer is to set them higher.
The x-systemd.automount option is the modern way to handle NFS. It tells systemd to mount the share on first access, not at boot. The right answer for a frequently-used share is to use automount; the right answer for a critical share that must be available at boot is to use a regular mount.
Mounting temporarily with the mount command
The right way to mount a share without editing fstab is the mount command:
sudo mount -t nfs server.example.com:/export/data /mnt/nfsThis is a one-off mount. The right answer is to use it to verify the share is accessible and the mount point is right before adding the entry to fstab. The wrong answer is to skip this step and go straight to fstab — the right answer for a new share is to verify it manually first, then automate.
The right NFSv4 invocation is:
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 _netdev and nofail options explained
The _netdev option is documented in the mount man page. It tells the mount command to wait for the network to be up before attempting the mount. The wrong answer is to omit it on a system with a slow network — without _netdev, the mount tries to run before the network is ready, fails, and marks the mount as failed in fstab.
The nofail option is documented in the systemd.mount man page. It tells systemd to continue boot even if the mount fails. The wrong answer is to omit it — without nofail, a failed mount will drop 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 _netdev and nofail. 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.
A common question is whether to use x-systemd.automount instead of _netdev. The answer is that x-systemd.automount is the modern preferred approach, and it does the job of both — the share is mounted on first access, and systemd handles the network-waiting for you. The right answer for new mounts is x-systemd.automount; the right answer for existing mounts that work is to leave them alone.
The right NFS server-side config
The right way to export a directory from an NFS server is to add it to /etc/exports:
/export/data 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)The fields are: directory, allowed clients, options. The right answer for a home network is to allow the whole subnet. The right answer for a production network is to allow specific IPs.
The rw option allows read-write. The sync option forces synchronous writes (safer but slower; for performance, use async but accept the risk of data loss on a crash). The no_subtree_check option disables subtree checking, which is the right answer for almost every case — subtree checking is a performance hit for little benefit.
The no_root_squash option is the security-relevant one. The default is root_squash, which maps the client’s root user to the anonymous user (nobody) on the server. The right answer for most shares is to leave root_squash on. The wrong answer is to set no_root_squash for a share that the client needs to write to as root — the right answer is to use a non-root user on the client and let the squashing map that user to a specific UID on the server.
After editing /etc/exports, run:
sudo exportfs -aThis re-reads the exports file. The wrong answer is to restart the NFS server — exportfs -a is enough.
Troubleshooting the access denied error
The most common NFS error is access denied by server while mounting. The right answer is to check the server-side log first. On the NFS server:
sudo journalctl -u nfs-serverThe log shows the exact reason for the rejection. The most common causes:
- The client IP is not in
/etc/exports. The right answer is to add it andexportfs -a. - The client and server are using different NFS versions. The right answer is to specify the version on the client with
-o vers=3orvers=4.1. - The firewall is blocking the NFS traffic. NFS uses port 2049 plus a few others (rpcbind on 111, mountd, statd, lockd). The right answer is to open these on the server firewall.
- The client and server clocks are too far out of sync. NFS uses timestamps for cache validation. The right answer is to run NTP on both.
A common pitfall is that the firewall allows port 2049 but not the auxiliary ports. The right answer is to allow the entire nfs and mountd services in firewalld or to allow the port range that the kernel is using (which is dynamic and can change between reboots).
The right answer for a permanent fix is to use NFSv4 only, which uses port 2049 exclusively and removes the auxiliary port requirements.
NFSv4 vs NFSv3 in 2026
NFSv4 is the modern default. The right answer is to use NFSv4 unless you have a specific reason to use NFSv3. NFSv4 is more efficient (single connection, not multiple), more secure (built-in Kerberos support), and simpler (port 2049 only, no auxiliary ports).
The right way to force NFSv4 on the client is the nfsvers=4 (or vers=4) option:
server.example.com:/export/data /mnt/nfs nfs4 defaults,_netdev,nofail 0 0The wrong answer is to leave the version unspecified and assume the client and server will negotiate. They will, but the negotiation sometimes picks NFSv3 if the server has both enabled, and the result is harder to debug than just specifying the version.
The right answer for new deployments is to disable NFSv3 on the server entirely. The way to do this in /etc/nfs.conf:
nfsdvers=4.2This restricts the server to NFSv4.2. The right answer for legacy clients is to leave NFSv3 enabled until the legacy clients are retired.
FAQ
Why is my mount not appearing after a reboot?
The most common cause is a missing _netdev option. Without it, systemd tries to mount the share before the network is up, fails, and marks the mount as failed. The right fix is to add _netdev to the options. If the mount still does not appear, check systemctl status mnt-nfs.mount (or whatever the mount unit is named) 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 wrong answer is to set the mount to be world-writable. The right answer is to mount the share as root, then use uid and gid options in fstab to map the share to a specific user:
server:/export /mnt/nfs nfs defaults,uid=1000,gid=1000 0 0The right answer for a per-user mount is x-systemd.automount and the user option, which lets a non-root user mount the share on demand.
How do I check what is currently mounted?
The right answer is mount | grep nfs for NFS mounts specifically, or findmnt for all mounts. The right answer for a specific mount is findmnt /mnt/nfs.
What is the difference between hard and soft mounts?
Hard mount: the client retries indefinitely if the server is unreachable. Soft mount: the client returns an error after a timeout. The right answer for almost every case is hard (the default), which is what the timeo=900,retrans=5 options configure. The wrong answer is soft, which can produce data corruption if a write is interrupted. The right answer for soft is a read-only mount or a non-critical cache mount.
How do I unmount?
sudo umount /mnt/nfs for a normal unmount. If the share is busy (a process has files open), sudo umount -l /mnt/nfs does a lazy unmount — it detaches the filesystem from the mount tree and waits for the process to release the files. The right answer for a hung mount is sudo umount -f /mnt/nfs (force) or sudo umount -fl /mnt/nfs (force + lazy), but these should be last resorts because they can produce data corruption.
Is NFS encrypted?
NFS itself is not encrypted. The right answer for encryption is to use NFSv4 with Kerberos (sec=krb5p for privacy, sec=krb5 for integrity only, sec=krb5i for both), or to mount the NFS share over a VPN (WireGuard, Tailscale, OpenVPN). The wrong answer is to assume NFS over a private network is safe — packet capture on the wire is a real attack vector.
What is the performance difference vs iSCSI or SMB?
NFS is faster than SMB for Linux-to-Linux file serving. iSCSI is faster for block-level access (it presents a raw block device, not a filesystem). The right answer for a file server is NFS on Linux. The right answer for a block device is iSCSI. The right answer for Windows file sharing is SMB. The right answer for a small office is to use SMB because it is built into every Windows machine and does not require additional client software.
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: