What is NFS (Network File System)?
NFS, or Network File System, is a protocol that lets a computer access files and directories held on another computer through its own file tree. An NFS server exports a directory; a client mounts it at a local path. Applications then use familiar file operations while the client handles communication with the server.
That local-looking path does not make the storage local. Access still depends on the server, permissions and network. In a home lab, a wired connection to a NAS can keep traffic entirely inside your LAN. Accessing that NAS from another location adds broadband capacity, routing and protection of the remote connection to the picture.
The Techie Broadband terminology guide connects NFS with the surrounding networking and storage concepts. This guide focuses on what actually happens when a mounted directory is used, and how to separate access, performance and recovery problems.
What does an NFS mount actually do?
A mount attaches a filesystem to a location in the client's directory tree. For example, a server may share data from /srv/share while the client sees it beneath /mnt/nfs. The paths need not match. With NFSv4, the path presented to clients can also differ from the server's underlying path because of its exported namespace.
A mount is not an automatic offline copy. Nor is it a synchronisation service that keeps independent folders reconciled. Think of it as a route through which file operations reach shared storage, with client caching where appropriate.
Component | Role | What it does not prove |
|---|---|---|
Server export | Makes an authorised directory available | Every user can read or write every file |
Client mount point | Places the share in the client's file tree | Files have been copied to local storage |
Network connection | Carries requests and replies | The server has spare storage performance |
Application | Opens, reads and modifies files | Concurrent edits are coordinated correctly |
How NFS requests reach the stored files
Consider an application opening /mnt/nfs/projects/report.txt. The operating system recognises that this path belongs to an NFS mount. Where server communication is needed, the client sends remote procedure calls describing the operation. The server checks access, performs the work against its filesystem and returns a result.
Filehandles identify server-side objects in protocol operations. They are not simply copies of the pathname typed into the application. A read request identifies the file and requested range of bytes; the reply carries data or an error. A write travels in the opposite direction, with its own acknowledgement and stability semantics.
NFSv4 can combine operations in a COMPOUND request, reducing separate network exchanges for some work. The IETF's NFSv4.1 specification, RFC 8881, published in August 2020, describes this mechanism and the protocol's session and caching model. Combining operations reduces avoidable exchanges; it does not remove the network or turn every application action into one request.
The infographic below separates the export, local mount, request path and access checks. Its local and remote examples matter because only the latter necessarily crosses a broadband connection.
NFSv3, NFSv4.0, NFSv4.1 and NFSv4.2
Version compatibility is a property of the actual client and server. A NAS supporting NFSv4 does not establish which minor versions, security modes or optional features a particular client can use.
Version | Important distinction | Practical check |
|---|---|---|
NFSv3 | Core file operations with separate supporting services, including mounting and locking | Check the auxiliary services and firewall configuration |
NFSv4.0 | Integrated opening and locking, COMPOUND operations and an exported namespace | Check identity mapping and client compatibility |
NFSv4.1 | Adds sessions and parallel NFS mechanisms | Check the negotiated version and implementation support |
NFSv4.2 | Adds optional operations such as server-side copying and sparse-file support | Confirm the particular feature is supported and used |
RFC 7862, published in November 2016, defines the NFSv4.2 additions as optional features. Merely negotiating 4.2 is not proof that an application copy is offloaded to the server. Likewise, parallel NFS, or pNFS, requires a suitable deployment; it is not a guaranteed speed multiplier for a home NAS.
For conventional TCP NFSv4 access, port 2049 is the normal service port. NFSv3 can involve rpcbind, mountd and locking-related services with additional ports. An NFSv4-only server need not expose a separate MOUNT service to clients. Consequently, an unsuccessful showmount query alone does not establish that NFSv4 is unavailable.
NFS compared with other storage choices
Choose around the application's access model, rather than expecting one protocol to win every speed comparison.
Technology | What the client accesses | Suitable question to ask |
|---|---|---|
NFS | Shared files and directories | Does the application support this network filesystem and its locking behaviour? |
SMB | Shared files and directories | Does the client estate need Windows-oriented sharing and identity integration? |
Block storage | Addressed blocks, usually with a filesystem managed by the consumer | Which system owns the filesystem, and is multi-host access supported safely? |
Object storage | Objects accessed through an API | Can the application work with object keys and API operations? |
File synchronisation | Separate local copies reconciled by a service | Is offline access more important than a live shared mount? |
An NFS server can store its files on block storage. That describes the layer underneath the shared filesystem. It does not make an NFS client the owner of the server's disk format.
Similarly, object storage has a different access model. A gateway can present files backed by objects, but its compatibility, caching and failure behaviour require separate assessment. An object bucket does not become a fully compatible NFS filesystem just because filenames resemble keys.
NFS is common in Linux and Unix environments, but it is not restricted to them. Microsoft's Windows Server documentation distinguishes Server for NFS from Client for NFS, with different supported versions. Check the operating system edition and component rather than assuming a Windows NFS client supports every version its server supports.
Why a successful mount can still return permission denied
There are several separate decisions: whether the client can reach the service, whether its host is allowed to use the export, how its user identity is interpreted, and whether that identity has filesystem permission for the requested action.
With AUTH_SYS, requests convey numeric user and group identifiers. Matching account names on two machines are insufficient if their numeric identifiers differ. NFSv4 owner-name mapping introduces another configuration consideration; it does not automatically establish trustworthy authentication.
Linux root squashing maps requests from client UID 0 to an anonymous identity. The Linux exports manual explains this protection. It means sudo on the client may give less access to an export, rather than bypassing its permissions.
Illustrative example: a server file belongs to UID 1000 and permits its owner to write. The client user also called alex has UID 1001. With numeric AUTH_SYS access and no suitable group or ACL grant, the client's write can fail. Renaming either account does not resolve the numeric mismatch. Inspect the identities and intended policy first.
Check the allowed client address or subnet in the export.
Check the negotiated security flavour and relevant identity mapping.
Compare numeric ownership, group membership and ACLs.
Check directory traversal permissions as well as the target file.
Check read-only settings on both the export and client mount.
Avoid fixing this by granting universal write access or disabling root squashing without understanding the trust boundary. A mounted share should grant the access required by the application, not compensate for an unexplained identity problem.
Is NFS encrypted?
NFS version alone does not answer that question. Kerberos options separate authentication, integrity and privacy: krb5 authenticates, krb5i adds integrity protection, and krb5p adds encryption of the protected NFS traffic. They require compatible configuration and supporting identity infrastructure.
RFC 9289 defines RPC-with-TLS, and current Linux documentation describes transport-security settings where supported. This is a separate capability to verify on both endpoints. Do not infer that enabling NFSv4 or using TCP automatically enables encryption.
For remote home-lab access, a properly authenticated, encrypted VPN is often a practical way to keep NFS on a controlled network path. The tunnel does not replace filesystem permissions, server hardening or backups. Restrict which peers can reach the service and verify the addresses actually seen by the server.
CGNAT, public IPv4 availability and IPv6 firewall policy can affect how the remote connection is established. These are connectivity questions, not reasons to expose an ordinary NFS export to everyone on the internet. A static IP alone provides neither encryption nor user authentication.
Why cached NFS files are not always instantly current
Clients cache data, names and attributes to avoid unnecessary server work. That improves responsiveness but creates questions about when another client's changes become visible. Linux documents close-to-open consistency for common sharing patterns: one application writes and closes; another opens and checks the file.
This is not a promise of instantaneous coherence for every pair of applications holding files open. Applications that edit shared data need an appropriate coordination model. Verify locking requirements before placing databases or virtual-machine disks on a generic share.
NFSv4 delegations can let clients perform some work locally until the server recalls that authority. They are not permanent ownership of the file. Disabling caches globally can increase round trips substantially; it should follow a diagnosed consistency requirement rather than a guess about slow performance.
Large transfers and small operations have different limits
A large sequential transfer can keep substantial data in flight. Directory traversal, file opening and synchronous updates can instead depend on repeated replies. Amazon EFS documentation identifies request patterns and small-file behaviour as important performance considerations. Its service-specific settings and limits should not be copied uncritically to a NAS.
Techie Broadband model: dependent round trips
Assume 1,000 operations, each waiting for one network round trip before the next begins. Ignore server processing, payload transfer, caching, batching and retransmissions. The network waiting time is operation count multiplied by RTT.
Assumed RTT | Waiting time for 1,000 serial exchanges | Serial exchange ceiling |
|---|---|---|
1 ms | 1 second | 1,000 per second |
20 ms | 20 seconds | 50 per second |
40 ms | 40 seconds | 25 per second |
These are arithmetic results from a deliberately simplified model, not measured NFS IOPS. Real operations can need different numbers of exchanges, and clients can cache, combine or overlap work. The point is causal: increasing line capacity does not shorten a wait for a reply. Latency and throughput therefore need separate investigation.
Techie Broadband calculation: a 10 GB remote read
Assume a server at home sends a decimal 10 GB file to a remote reader. The file contains 80,000 megabits. Ideal transfer time in seconds is 80,000 divided by the sustained payload rate in Mbps.
Assumed payload rate | Ideal transfer time |
|---|---|
20 Mbps | 66 minutes 40 seconds |
50 Mbps | 26 minutes 40 seconds |
100 Mbps | 13 minutes 20 seconds |
1,000 Mbps | 1 minute 20 seconds |
If those figures are line rates rather than payload rates, treat the times as lower bounds. Protocol overhead, VPN processing, competing traffic, loss, server storage and client limits can lengthen them. Decimal GB is used here, not binary GiB.
A remote read consumes the server connection's upload capacity and the reader connection's download capacity. A remote write reverses the main data direction. For a NAS and client on the same LAN, broadband is outside the direct path unless the traffic is deliberately routed elsewhere.
UK FTTC, FTTP, cable and mobile services can have different upstream and downstream limits. Use the exact product and measured path, not a technology label. A gigabit download headline on either end does not establish gigabit transfers in both directions.
Concurrent readers share the bottleneck
As an illustration, four remote readers sharing 100 Mbps of server upload would average 25 Mbps each under equal sharing, before other limits. Each 10 GB transfer would then take at least 3,200 seconds, or 53 minutes 20 seconds. Real sharing is not guaranteed to be equal.
On a local network, a 1 Gbps interface represents 125 MB/s before overhead. A 2.5 Gbps interface represents 312.5 MB/s. Neither figure guarantees that the NAS disks, processor or workload can sustain that rate. A faster broadband tariff cannot repair a saturated LAN interface.
A Linux client example, with clear boundaries
The following example assumes an existing authorised export presented as /share by an NFSv4.1-capable server at 192.168.1.10. The client uses Ubuntu with nfs-common installed. Replace the address and export path with your actual configuration. These commands are documentation-checked examples, not a claim of an NFS deployment tested by Techie Broadband.
sudo apt install nfs-common
sudo mkdir -p /mnt/nfs
sudo mount -t nfs -o vers=4.1,ro,hard 192.168.1.10:/share /mnt/nfs
findmnt /mnt/nfs
nfsstat -m
The mount is intentionally read-only for inspection. Hard recovery retries requests when the server stops responding, which can leave applications waiting. The Linux NFS client manual warns that soft timeout behaviour can risk corruption in some situations; switching to soft is not a general cure for hangs.
The example does not configure Kerberos or TLS. Read-only access does not encrypt traffic. Confirm the network trust boundary and security flavour before using a real export. Once applications stop using the mount, sudo umount /mnt/nfs removes it; it does not delete the server's files.
For persistent mounts, plan boot dependencies and application behaviour when storage is absent. A backup task writing to an ordinary local directory because the intended share was not mounted is a different failure from slow NFS. Verify the mount explicitly before running dependent work.
Troubleshoot the failing layer first
Confirm the expected mount. Use findmnt and nfsstat -m to inspect the server, path, version and options. Verify that the application is using that location.
Check reachability. Confirm name resolution, routing and firewall policy. A successful ping does not prove the NFS service is reachable; an unsuccessful ping does not prove it is unavailable.
Check the export and identity. On the server, inspect authorised clients and file permissions. Compare the application's actual UID, groups and security mode.
Compare local and remote access. Start with a wired client beside the NAS. Add WiFi or the remote VPN path only after establishing that baseline.
Separate bulk and metadata work. Compare a controlled large-file read with the actual directory or small-file workload. Document cache state and avoid treating a warm-cache result as disk performance.
Inspect resource contention. Check interface negotiation, loss, NAS CPU, disks, free space and other clients. Measure both network and storage rather than blaming broadband first.
Investigate timeouts and stale handles. Check server restarts, export changes and filesystem changes. Coordinate recovery with applications before unmounting or remounting active storage.
Change one justified setting at a time. Record the version, workload and before-and-after evidence. Keep provider-specific tuning separate from generic NFS advice.
Symptom | Useful first distinction |
|---|---|
Mount fails | Connectivity, export path, protocol or security compatibility |
Mount succeeds but writes fail | Read-only configuration, identity or filesystem permission |
Large files are fast but browsing is slow | Metadata workload, round trips and cache behaviour |
Applications hang during outage | Recovery policy and dependency on unavailable storage |
Stale file handle | The server-side object or exported filesystem changed |
Backup finishes in the wrong place | The expected filesystem was not mounted |
Shared storage still needs recovery planning
An NFS mount exposes files; it does not preserve earlier versions, create an independent copy or prove that a restore works. Deleting data through an authorised client can delete the shared server copy. RAID, replication and snapshots each address particular problems and need their own failure-boundary assessment.
Plan backups of the data and the configuration needed to make it usable: ownership, ACLs, exports, identity mapping and application requirements. Test recovery through the intended client. A restored file that exists but cannot be opened by its application is an incomplete recovery.
NFS questions answered
Is NFS the same as a NAS?
No. A NAS is a network-attached storage system. NFS is one protocol it may offer. The same device can expose other services, and NFS can run on an ordinary server.
Does NFS use my broadband connection?
Not for a direct local client-to-server path on the same LAN. It uses broadband when the actual route crosses it, such as accessing home storage remotely.
Is NFSv4 automatically encrypted?
No. Verify the configured security mechanism. Version support alone does not demonstrate Kerberos privacy, RPC-with-TLS or a protected VPN path.
Is NFS faster than SMB?
There is no universal winner. Compare the actual clients, servers, security settings, cache conditions and workload. A large sequential copy does not predict directory or synchronous-write performance.
Why does sudo not fix permission denied?
Client root can be mapped to an anonymous identity by root squashing. Check the intended user, groups, export policy and server permissions rather than assuming client root has server authority.
Can I use NFS as a backup destination?
Yes, where the backup application supports it, but the mount itself is not a backup. Verify the destination is mounted, protect retained copies and test restoration with the required permissions and metadata.
Key takeaway
NFS makes server-held files accessible through a client filesystem. Useful diagnosis follows that whole relationship: mount, identity, permissions, request behaviour, network path, storage and application recovery. Establish which part is limiting the work before changing a protocol setting or buying more broadband capacity.
