Network File System (NFS): A secure guide for remote access

The Network File System (NFS) provides multiple computers with an easy way to access the same remote folders through their regular filesystems. This article explains how NFS does that, the different versions of NFS, and how to set it up. You’ll also learn how it compares to similar solutions and which one is the best option for your situation.

What is the Network File System (NFS)?

NFS is a protocol that lets a computer use files stored on a remote server as if they were on its own hard drive. Instead of copying data back and forth between machines, it simply shares the remote server’s filesystem over the network.

Key concepts and definitions

• NFS server: The machine that hosts the actual files and shares its directories with clients.
• NFS client: A computer that mounts a shared directory from the server and uses it like part of its own filesystem.
• Export: A folder or filesystem that the server makes available to clients, controlled by server-side permissions.
• Mounting: The process of attaching an exported folder to the client’s local filesystem so it appears as a regular directory.
• File handles: Unique identifiers that the server gives clients so they can locate and access specific files or directories.
• Remote procedure call (RPC): The mechanism NFS uses to let clients request operations from the server, such as reading or writing a file.
• Stateless protocol: A protocol design where the server processes each request independently of the ones before or after it. Each request includes all the details needed to complete the operation. Older NFS versions are stateless.
• Stateful protocol: A protocol design where the server keeps some information about the client between requests. Newer NFS versions are stateful because holding session information enables stronger security features (such as better authentication and access control) and more advanced operations.

Why use the Network File System?

NFS is useful whenever several computers need to work from the same central set of files.

• Simple file sharing: NFS lets multiple computers access and edit files on a shared server without having to copy them locally.
• Centralized storage: All files stay in one place, making backups, updates, and management easier.
• Efficient data use: Only the requested data travels over the network, reducing load and speeding up access.
• Cross-platform support: NFS supports Linux, macOS, and Windows, making it ideal for mixed environments and remote setups.

How NFS works

NFS works by combining a few key services and processes that connect devices on the same network to shared directories.

Services and components required for NFS

To make NFS work, both the server and the client rely on a few simple components. These pieces define what gets shared, who can access it, and how the connection between the two systems stays active.

• Exports file (/etc/exports): A small configuration file on the server that lists which folders it shares and which computers can use them.
• NFS client tools: The software on the client that connects to the server and mounts the shared folders so they appear like standard directories.
• Network connection: The link that carries NFS traffic between the client and server, typically over Transmission Control Protocol (TCP) / Internet Protocol (IP) on port 2049.

NFS client and server workflow

Once the components are in place, the server exports a directory, marking the folder as shareable and setting rules for who can use it. The client then mounts that exported directory, making it show up like a normal folder on the client’s system.

From that point on, any file action the client performs inside it, such as reading, writing, modifying, or listing, is translated into an RPC and sent to the server through the NFS protocol. The server processes each RPC request, performs the actual file operations on its own storage, and returns the results.

NFS versions explained

NFS has gone through several versions since its first release, with each new version improving speed, reliability, and security.

NFS v2: Legacy overview

NFS version 2 launched in 1989 with a simple, stateless design that made it easy to set up and reliable on small networks. It supported basic file sharing but had strict technical limits: files couldn’t exceed about 4GB due to 32-bit addressing, and each read or write was capped at 8KB. These constraints made larger workloads difficult.

NFS v3: Performance improvements

NFS version 3 introduced significant performance gains. It expanded to 64-bit file sizes, removing the old 4GB limit and allowing much larger files. It improved write handling and caching, which made transfers faster and more consistent.

This version also supported both TCP and User Datagram Protocol (UDP), giving administrators flexibility in how data was transmitted across the network. It added a requirement to write data to stable storage before confirming a write, improving reliability. However, this depends on server configuration, for example, sync vs. async.

NFS v4: Modern security and functionality

NFS version 4 focused on security and interoperability. It introduced built-in authentication and optional Kerberos encryption, along with detailed permission controls via access control lists (ACLs). It also standardized behavior across different operating systems, which improved compatibility with environments that include Linux, UNIX, macOS, and Windows. Later revisions (v4.1 and v4.2) further refined the protocol and addressed issues from the initial release.

Key features of NFS v4.1 and v4.2

NFS vs. SMB: Key comparisons

NFS and Server Message Block (SMB) are file-sharing protocols, but they were built for different systems and handle communication in other ways. Unlike NFS, SMB creates and maintains a session between the client and the server and tracks connection details.

NFS vs SMB: Technical differences

Flexibility, speed, and performance metrics

NFS stays lightweight, which makes it fast and reliable for shared folders where you want simple, direct file access without a lot of extra features. It’s popular in environments where people just need a shared directory that behaves predictably and stays out of the way. SMB offers more built-in user features, such as detailed permissions, file versioning, and desktop sharing tools. This makes it feel more natural in Windows-heavy setups where those extras matter.

In terms of speed, NFS usually performs better because it only sends the information needed to read or write data. This makes it well-suited for continuous reads and writes, or for workloads that push a lot of traffic through the same shared storage. SMB can be fast too, especially in newer versions that improve caching and session handling, but its extra features introduce more overhead.

NFS and NAS: Architecture and use cases

NFS is a protocol that defines how a client accesses files on a remote system, while network attached storage (NAS) is the actual device that provides that storage. A NAS unit usually runs a lightweight operating system and exposes shared folders over one or more protocols, with NFS being one of the most common.

In practice, NFS enables a NAS to behave like a shared directory for servers, workstations, or virtual machines (VMs). It’s a good fit for setups where several machines need to read and write to the same storage without maintaining their own local copies. NAS devices that support NFS are often used for centralized home directories, shared project spaces, media storage, and backup targets.

Common challenges with NFS

Security risks and vulnerabilities

NFS was initially designed for trusted local networks. Without the proper safeguards, attackers can spoof client machines, read data in transit, or access exported directories that were never meant to be public. Modern NFS versions improve this, but security still depends heavily on how the server is configured and what the network allows.

Encryption, authentication, and port security

• No encryption in NFSv2 and NFSv3: These versions send file contents, file names, and metadata in plain text. Anyone who can capture network traffic can read or alter the data without detection.
• Optional encryption in NFSv4: NFSv4 supports encrypted traffic, but only if the administrator enables it through Kerberos. If it’s not enabled, NFSv4 also sends data unprotected.
• Host-based authentication in NFSv2 and NFSv3: Access is granted based on the client’s IP address. An attacker who spoofs that address can trick the server into believing they are a trusted machine.
• User identity can be forged: The client tells the server which user is making the request by sending numeric IDs. Without Kerberos, the server has no way to confirm that those IDs are legitimate.
• Fixed port makes the service easy to find: NFS listens on port 2049. If this port is reachable from the internet, attackers can quickly identify the server and probe for misconfigurations or unprotected exports.
• Open exposure leads to data theft or corruption: When port 2049 is left unfiltered, attackers can intercept file operations, replay old requests, or attempt to mount exported file systems directly.

Performance bottlenecks and input/output (I/O) limits

NFS performance is closely tied to how quickly the server can handle metadata and file operations. Workloads that constantly check file attributes, open large numbers of small files, or generate many synchronous writes can overwhelm the server with RPC calls. This creates delays even if the network itself is healthy.

Storage speed also plays a major role. If the server uses slow disks, limited caching, or insufficient input/output capacity, NFS clients will feel that slowdown immediately because every operation depends on the server’s response time. Inconsistent or high-latency networks amplify these delays, since each file action must complete before the next one begins.

Configuration and compatibility issues

NFS depends on the server and client agreeing on a long list of settings, and even minor mismatches can cause unexpected behavior. One common issue is alignment between user ID (UID) and group ID (GID): NFS relies on numeric user and group IDs, so if those IDs don’t match across systems, users may see the wrong permissions or lose access entirely.

Export options can also create problems. Settings like root_squash, read/write flags, or version-specific features can affect how a shared directory behaves, and a single incorrect line in the exports file can prevent clients from mounting or writing to it.

Version differences add another layer of complexity. NFSv3 and NFSv4 handle locking, permissions, and path structures differently, so a client using one version may not behave the same way as a client using another. Cross-platform setups introduce even more variation, since Linux, Berkeley Software Distribution (BSD), macOS, and commercial NAS systems each implement certain features slightly differently. These inconsistencies can lead to slow mounts, missing permissions, or intermittent “stale file handle” errors that are difficult to diagnose.

How to set up an NFS server and client

Step-by-step NFS server configuration

1. On the NFS server, install the NFS service package. This adds the software that lets the server share folders over the network. To do that, you’ll need to run the following commands:

• Ubuntu or Debian: sudo apt install nfs-kernel-server
• CentOS or RHEL: sudo dnf install nfs-utils

Note: If you don’t yet have a server environment, you may find our guide to setting up a home server from scratch useful before configuring NFS.

2. Next, create the folder you want to share or select a directory to share. If you're creating a new one, run this command: sudo mkdir -p /srv/nfs/shared. This makes a directory at /srv/nfs/shared that you’ll share with clients. Then, set a safe default owner by running the command that matches your system: sudo chown nobody:nogroup /srv/nfs/shared.
3. Add the folder to the exports file so the server knows what to share. Open the exports file by running: sudo nano /etc/exports. Inside the file, add this line to share the directory with your local network: /srv/nfs/shared 192.168.1.0/24(rw,sync,no_subtree_check). Then, apply the updated export rules by running the following command: sudo exportfs -ra.
4. Next, start and enable the NFS server service. This ensures the NFS service is running and ready to accept connections.

• Ubuntu or Debian: sudo systemctl start nfs-kernel-server
• CentOS or RHEL: sudo systemctl enable --now nfs-server

Mounting NFS shares on clients

1. To install the NFS client tools on the client machine, run these commands to install NFS client tools:

• Ubuntu or Debian: sudo apt install nfs-common
• CentOS or RHEL: sudo dnf install nfs-utils

2. Then, create a mount point where the remote folder will appear. This is the directory where the NFS share will be accessible locally. Run: sudo mkdir -p /mnt/nfs/shared.
3. Mount the shared folder with this command, replacing server-ip with the IP address of your NFS server: sudo mount -t nfs -o vers=4 server-ip:/srv/nfs/shared /mnt/nfs/shared.
4. Finally, confirm that the mount works with the following commands: df -h or mount | grep nfs.

NFS firewall and port rules

NFS needs specific network ports open so the client and server can talk to each other. Which ports you open depends on which version of NFS you’re using.

• For NFSv4: NFSv4 uses only one port for all communication: TCP 2049. To allow devices on your local network to reach the server, run: sudo ufw allow from 192.168.1.0/24 to any port 2049 proto tcp.
• For NFSv3 and earlier: NFSv3 uses several ports instead of a single one. It always needs port 111 for rpcbind, and it uses additional ports for services like mount and lock management. These extra ports can change unless you set them to fixed values. To allow basic NFSv3 traffic from your local network, run:
  sudo ufw allow from 192.168.1.0/24 to any port 111 proto tcp
  sudo ufw allow from 192.168.1.0/24 to any port 111 proto udp
  sudo ufw allow from 192.168.1.0/24 to any port 2049 proto tcp
  sudo ufw allow from 192.168.1.0/24 to any port 2049 proto udp

To check active NFS ports, the command is sudo rpcinfo -p.

Tip: Use NFSv4 whenever possible. It needs fewer open ports and supports stronger encryption.

How to secure your NFS deployment

NFS security depends on using the correct version, limiting who can connect, and controlling what clients can do once they’re connected.

NFS hardening best practices

These practices help protect both the data and the server:

Use NFSv4 or newer

NFSv4 includes stronger security mechanisms, such as Kerberos-based authentication and support for encrypted traffic. Older versions send data and user IDs in clear text, which makes them risky on untrusted networks.

Restrict access to trusted systems

Only export directories to specific IP addresses or subnets, and keep shares read-only unless clients genuinely need write access. The smaller the access list, the smaller the attack surface.

Enable root_squash

root_squash maps client root requests to an unprivileged user on the server. This prevents someone with root access on a client system from having root access to server files. Avoid disabling it with options like no_root_squash.

Keep NFS traffic on private networks

NFS should run inside a trusted environment, such as a local area network (LAN) or virtual LAN (VLAN). Exposing NFS directly to the internet allows attackers to scan port 2049 and probe for misconfigurations.

Use a corporate VPN if the connection travels over the internet

If you need to access NFS shares from outside your organization’s network, always route that traffic through your corporate VPN. A corporate VPN is managed by your organization and connects you directly to its internal network, so that NFS traffic is encrypted end to end and protected by company security policies.

This is very different from a commercial/consumer VPN, which routes traffic through a third-party service and does not provide access to internal systems. For NFS, only a corporate VPN offers the secure, trusted path required to prevent eavesdropping, tampering, and exposure of the client’s real IP address.

Monitoring tools and audit trails

Regular monitoring helps you catch problems before they turn into breaches. Use built-in Linux tools, such as auditd, to track file access, mounts, and permission changes. Review your configuration file (/etc/exports) regularly and use commands like showmount -e to check which clients are connected.

If you use enterprise storage or NAS devices, turn on file access auditing to log who reads, edits, or deletes files. You can also connect NFS logs to your security information and event management (SIEM) system or intrusion detection software to alert you to unusual mount activity or data movement.

Mitigating common NFS attack vectors

Older authentication methods, such as AUTH_SYS, trust information provided by the client, which attackers can fake. Using Kerberos (RPCSEC_GSS) prevents this by verifying identities securely. You should also avoid exposing NFS directly to the public internet. Any remote access should use a corporate VPN or Secure Shell (SSH) tunnel to protect traffic and block unauthorized connections.

Advanced use cases and applications of NFS

Using NFS in hybrid cloud environments

A hybrid cloud is a mix of on-premises infrastructure, such as servers, and public cloud storage or computing. NFS makes it easy for these two environments to share files. Whether you store files on your computer or in the cloud, you get a consistent way to access them without copying them.

Some companies use NFS to move storage to the cloud for backups and archiving. It lets local systems access cloud storage as if it were on-premises. NFS also works well with a corporate VPN, which encrypts data to keep it safe as it moves.

NFS for virtualization and containers

VMs and containers need fast, consistent shared storage. NFS gives them a common data store that multiple nodes can read and write to at the same time. It fits well with VMware, Proxmox, and Kubernetes, where workloads must access the same files across hosts.

NFS also simplifies ops. Instead of giving each VM or container its own disk, point them to a single NFS share. You cut storage use, reduce costs, and scale your cluster by adding nodes without reworking storage.

With NFSv4.1 and NFSv4.2, features like pNFS and smarter cache controls keep performance steady under heavy load. That makes NFS a reliable base for large virtual environments and container platforms.

Integrating NFS with backup and disaster recovery

Many organizations use NFS for snapshot-based backups. This lets them capture a moment-in-time copy of files without stopping systems or affecting performance. If something goes wrong, restoring data from an NFS share is fast and straightforward.

It works with most major backup tools and cloud storage platforms. This helps create a flexible recovery plan that fits both local and hybrid environments. It also supports encryption and access controls, keeping your backups private and protecting them from unauthorized access.