NFS, the Network File System, is a file-level network storage protocol that lets a client machine mount a directory exported by a remote server and read and write its files as if they were on a local disk. In server storage, NFS is the standard way for Linux and Unix servers to share one file tree among many hosts, and it is the native protocol of most NAS appliances in Unix environments.
Unlike block storage protocols such as iSCSI, NFS does not hand the client a raw disk. The server keeps control of the file system, and clients send operations such as open, read, write and rename over the network. This design makes concurrent access by many clients straightforward, at the cost of network latency on every metadata operation.
How NFS serves files over the network
NFS works as a client-server protocol built on remote procedure calls (RPC). The server exports a directory, the client mounts it at a local path, and the kernel’s virtual file system layer translates ordinary system calls into NFS requests. Applications see no difference: a call to open() or read() on /mnt/data becomes a network request handled by the server.
Files are identified by opaque file handles that the server issues, not by path names, so a client can keep working with a file even while other clients rename directories around it. To reduce round trips, clients cache file data and attributes for a short time, which is why NFS offers close-to-open consistency rather than strict real-time consistency: a client sees another client’s changes reliably after that client closes the file and the reader opens it again.
Exports are defined on the server, traditionally in /etc/exports, with options that control which hosts may mount, whether access is read-only, and how the root user is mapped. Clients mount with commands such as mount -t nfs server:/export /mnt/data or through entries in /etc/fstab and automount maps.
NFS versions and their differences
The protocol has evolved through three major versions in active use, and the version determines security, firewall behavior and locking. The table below summarizes what changed between them.
| Version | Transport and ports | State and locking | Security model |
|---|---|---|---|
| NFSv3 | UDP or TCP, port 2049 plus rpcbind and helper ports | Stateless server, separate NLM lock protocol | Host-based trust, numeric UID and GID |
| NFSv4.0 | TCP only, single port 2049 | Stateful, locking built into the protocol | Kerberos via RPCSEC_GSS, name-based identities |
| NFSv4.1 | TCP, sessions over one or more connections | Sessions with exactly-once semantics | Kerberos, optional pNFS layouts |
| NFSv4.2 | TCP, port 2049 | Adds server-side copy and sparse files | Kerberos, security labels |
For new deployments, NFSv4.1 or NFSv4.2 is the sensible default. A single TCP port simplifies firewalls, integrated locking avoids the fragile side protocols of NFSv3, and parallel NFS (pNFS) in version 4.1 lets clients read data directly from several storage nodes while metadata still flows through one server. NFSv3 remains common in hypervisor datastores and legacy appliances because it is simple and very widely supported.
Key mount and export parameters
Most NFS performance and reliability problems trace back to a handful of mount and export options. Defaults on modern Linux kernels are reasonable, but administrators should understand what each option changes.
| Option | Typical value | What it controls |
|---|---|---|
| rsize and wsize | Up to 1 MiB, negotiated | Maximum bytes per read or write request |
| hard or soft | hard | Whether operations retry forever or fail after timeouts |
| timeo and retrans | 600 deciseconds and 2 on TCP | Retry timing before the client reports a problem |
| actimeo | 3 to 60 seconds by default range | How long cached attributes are trusted |
| sync or async export | sync | Whether the server confirms writes before they reach stable storage |
| root_squash | Enabled | Maps the client root user to an unprivileged account |
| sec | sys, krb5, krb5i or krb5p | Authentication, integrity or full encryption |
Two options deserve special care. Soft mounts can silently corrupt data, because an application may receive an I/O error in the middle of a write sequence; hard mounts are the safe choice for anything that writes. An async export is fast but unsafe, since a server crash can lose writes that clients believe were committed.
NFS compared with other storage protocols
NFS is one of several ways to put storage on the network, and the right choice depends on whether clients need shared files or a private disk. The comparison below places NFS among its neighbors in server storage.
| Method | Access level | Typical clients | Best fit |
|---|---|---|---|
| NFS | File | Linux, Unix, hypervisors | Shared directories, home folders, web content |
| SMB | File | Windows, macOS, mixed offices | Desktop file shares with Windows permissions |
| iSCSI | Block | One host per volume | Databases and VM disks needing a private disk |
| Ceph file system | File on distributed objects | Large Linux clusters | Scale-out storage without a single head |
The essential distinction is that block protocols move disk sectors and leave the file system to the client, while file protocols move file operations and keep the file system on the server. Putting a single-writer database on NFS is possible with careful tuning, but many database vendors prefer block storage for predictable latency and IOPS.
Common pitfalls and how to avoid them
NFS problems usually appear as hangs, permission errors or stale data rather than clear failures. The following table maps typical symptoms to their causes.
| Symptom | Likely cause | Remedy |
|---|---|---|
| Processes stuck in D state | Server unreachable on a hard mount | Restore the server or network, then let I/O resume |
| Files owned by nobody | Identity mapping mismatch in NFSv4 | Align the idmapd domain or use consistent UIDs |
| Stale file handle errors | Export changed or file deleted on the server | Remount and avoid re-creating exports in place |
| Slow builds on many small files | Metadata round trips dominate | Use local scratch space or larger attribute caches |
The NFS server is also a classic single point of failure: if it stops, every client that mounts it stalls. Production designs therefore put exports on highly available NAS clusters or failover pairs, and they keep NFS traffic on a dedicated or isolated network because the default sec=sys mode trusts client-reported user IDs without verification.
A non-technical view
NFS is a way for computers to share a folder over the network. One machine holds the files, and other machines connect to that folder and use it as if it were their own drive. When one of them saves a file, the others can open the same file a moment later.
Think of it as a shared filing cabinet in a central room. Everyone works at their own desk, but the documents live in one place, so nobody has to send copies around. The catch is that if the room is locked, nobody can reach the documents.
A concrete example
A company runs its website on six Linux web servers behind a load balancer. Visitors upload images, and any of the six servers might receive a given upload. Storing uploads on each server’s local disk would leave images visible on one server and missing on the others.
The team creates an export on a highly available NAS and mounts it on all six servers with NFSv4.2, hard mounts and a 1 MiB read and write size. Every server writes uploads to /srv/uploads, which is the same directory everywhere. The application code itself stays unchanged, and adding a seventh web server only requires one more mount entry. The result is consistent content across the whole cluster without copying files between machines.