Introduction

NFS (Network File System) is a distributed file system protocol that allows you to mount remote directories on your server. This lets you manage storage space in a different location and write to that space from multiple clients. NFS provides a relatively standard and performant way to access remote systems over a network and works well in situations where the shared resources must be accessed regularly.

In this guide, we’ll go over how to install the NFS server and client software on Ubuntu, configure NFS exports, set up NFS mount points, and create persistent NFS mounts using fstab entries.

This tutorial has been validated on Ubuntu 20.04, 22.04, and 24.04. The package names, commands, and configuration files described here work consistently across these versions.

Key takeaways

• NFS enables centralized storage by allowing multiple client servers to access directories shared from a single host server over a network.
• You need two packages to set up NFS: nfs-kernel-server on the host and nfs-common on client machines.
• Security is configured through /etc/exports where you specify which directories to share and which client IP addresses can access them.
• Firewall rules are essential to restrict NFS access to authorized clients, typically using UFW to allow port 2049 from specific IP addresses.
• Persistent mounts require /etc/fstab entries so that NFS shares automatically reconnect after system reboots.

For ideal performance, it is recommended to use Premium Dedicated Droplets (PDDs) with 10 Gbit networking for both the NFS server and client(s)

• Using 10gbit networking will allow the NFS performance to come close to the published volume limits.
• Without a 10gbit droplet, performance will cap out at 2gbps

Prerequisites

We will use two servers in this tutorial, with one sharing part of its filesystem with the other. To follow along, you will need:

Two Ubuntu servers. Each of these should have a non-root user with sudo privileges, a firewall set up with UFW, and private networking if it’s available to you.

For assistance setting up a non-root user with sudo privileges and a firewall, follow our Initial Server Setup with Ubuntu guide.

If you’re using DigitalOcean Droplets for your server and client, you can read more about setting up a private network in our documentation on How to Create a VPC. For more information on configuring firewalls, see How to Set Up a Firewall with UFW on Ubuntu.

Throughout this tutorial, we refer to the server that shares its directories as the host and the server that mounts these directories as the client. You will need to know the IP address for both. Be sure to use the private network address, if available.

Throughout this tutorial, we will refer to these IP addresses by the placeholders host_ip and client_ip. Please substitute as needed.

Step 1 — Downloading and Installing the Components

We’ll begin by installing the necessary NFS components on each server.

On the Host

On the host server, install the nfs-kernel-server package, which will allow you to share your directories. Since this is the first operation that you’re performing with apt in this session, refresh your local package index before the installation:

sudo apt update
sudo apt install nfs-kernel-server

Once these packages are installed, switch to the client server.

On the Client

On the client server, we need to install the nfs-common package (also known as nfs-utils), which provides NFS client functionality without including any server components. Again, refresh the local package index prior to installation to ensure that you have up-to-date information:

sudo apt update
sudo apt install nfs-common

Now that both servers have the necessary packages, we can start configuring them.

We’re going to share two separate directories, with different configuration settings, in order to illustrate two key ways that NFS mounts can be configured with respect to superuser access.

Superusers can do anything anywhere on their system. However, NFS-mounted directories are not part of the system on which they are mounted, so by default, the NFS server refuses to perform operations that require superuser privileges. This default restriction means that superusers on the client cannot write files as root, reassign ownership, or perform any other superuser tasks on the NFS mount.

Sometimes, however, there are trusted users on the client system who need to perform these actions on the mounted file system but who have no need for superuser access on the host. You can configure the NFS server to allow this, although it introduces an element of risk, as such a user could gain root access to the entire host system.

Example 1: Exporting a General Purpose Mount

In the first example, we’ll create a general-purpose NFS mount that uses default NFS behaviour to make it difficult for a user with root privileges on the client machine to interact with the host using those client superuser privileges. You might use something like this to store files that were uploaded using a content management system or to create space for users to easily share project files.

First, make the share directory:

sudo mkdir /var/nfs/general -p

Since we’re creating it with sudo, the directory is owned by the host’s root user:

ls -la /var/nfs/general

Outputdrwxr-xr-x 2 root root 4096 May 14 18:36 .

NFS will translate any root operations on the client to the nobody:nogroup credentials as a security measure. Therefore, we need to change the directory ownership to match those credentials.

sudo chown nobody:nogroup /var/nfs/general

You’re now ready to export this directory.

Example 2: Exporting the Home Directory

In our second example, the goal is to make user home directories stored on the host available on client servers, while allowing trusted administrators of those client servers the access they need to conveniently manage users.

To do this, we’ll export the /home directory. Since it already exists, we don’t need to create it. We won’t change the permissions, either. If we did, it could lead to a range of issues for anyone with a home directory on the host machine.

Step 3 — Configuring the NFS Exports on the Host Server

Next, we’ll dive into the NFS configuration file to set up the sharing of these resources.

On the host machine, open the /etc/exports file in your text editor with root privileges:

sudo nano /etc/exports

The file has comments showing the general structure of each configuration line. The syntax is as follows:

/etc/exports

directory_to_share    client(share_option1,...,share_optionN)

We’ll need to create a line for each of the directories that we plan to share. Be sure to change the client_ip placeholder shown here to your actual IP address:

/etc/exports

/var/nfs/general    client_ip(rw,sync,no_subtree_check)
/home               client_ip(rw,sync,no_root_squash,no_subtree_check)

Here, we’re using the same configuration options for both directories with the exception of no_root_squash. Let’s take a look at what each of these options means:

• rw: This option gives the client computer both read and write access to the volume.
• sync: This option forces NFS to write changes to disk before replying. This results in a more stable and consistent environment since the reply reflects the actual state of the remote volume. However, it also reduces the speed of file operations.
• no_subtree_check: This option prevents subtree checking, which is a process where the host must check whether the file is actually still available in the exported tree for every request. This can cause many problems when a file is renamed while the client has it opened. In almost all cases, it is better to disable subtree checking.
• no_root_squash: By default, NFS translates requests from a root user remotely into a non-privileged user on the server. This was intended as security feature to prevent a root account on the client from using the file system of the host as root. no_root_squash disables this behavior for certain shares.

When you are finished making your changes, save and close the file. Then, to make the shares available to the clients that you configured, restart the NFS server with the following command:

sudo systemctl restart nfs-kernel-server

Before you can actually use the new shares, however, you’ll need to be sure that traffic to the shares is permitted by firewall rules.

Step 4 — Adjusting the Firewall on the Host

First, let’s check the firewall status to see if it’s enabled and, if so, to see what’s currently permitted:

sudo ufw status

OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

On our system, only SSH traffic is being allowed through, so we’ll need to add a rule for NFS traffic.

With many applications, you can use sudo ufw app list and enable them by name, but nfs is not one of those. However, because ufw also checks /etc/services for the port and protocol of a service, we can still add NFS by name. Best practice recommends that you enable the most restrictive rule that will still allow the traffic you want to permit, so rather than enabling traffic from just anywhere, we’ll be specific.

Use the following command to open port 2049 on the host, being sure to substitute your client IP address:

sudo ufw allow from client_ip to any port nfs

You can verify the change by typing:

sudo ufw status

You should see traffic allowed from port 2049 in the output:

OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
2049                       ALLOW       203.0.113.24
OpenSSH (v6)               ALLOW       Anywhere (v6)

This confirms that UFW will only allow NFS traffic on port 2049 from our client machine.

Step 5 — Creating Mount Points and Mounting Directories on the Client

Now that the host server is configured and serving its shares, we’ll prepare our client.

In order to make the remote shares available on the client, we need to mount the directories on the host that we want to share to empty directories on the client.

Note: If there are files and directories in your mount point, they will become hidden as soon as you mount the NFS share. To avoid the loss of important files, be sure that if you mount in a directory that already exists that the directory is empty.

We’ll create two directories for our mount locations:

sudo mkdir -p /nfs/general
sudo mkdir -p /nfs/home

Now that we have a location to put the remote shares and we’ve opened the firewall, we can mount the shares using the IP address of our host server:

sudo mount host_ip:/var/nfs/general /nfs/general
sudo mount host_ip:/home /nfs/home

One can use the -o nconnect=n flag when mounting NFS share from the client to boost IOPS for certain workloads. Where “n” is the number of connections to establish between this client and the target NFS Server. The number can be from 1 to 16. You can experiment with different nconnect values that best suit your workload, perhaps starting with a value of 8. Setting the nconnect option may provide a slight boost in IOPS for some workloads - specifically small write operations.

These commands will mount the shares from the host computer onto the client machine. You can double-check that they mounted successfully in several ways. You can check this with a mount or findmnt command, but df -h provides a more readable output:

df -h

OutputFilesystem                       Size  Used Avail Use% Mounted on
udev                             474M     0  474M   0% /dev
tmpfs                             99M  936K   98M   1% /run
/dev/vda1                         25G  1.8G   23G   8% /
tmpfs                            491M     0  491M   0% /dev/shm
tmpfs                            5.0M     0  5.0M   0% /run/lock
tmpfs                            491M     0  491M   0% /sys/fs/cgroup
/dev/vda15                       105M  3.9M  101M   4% /boot/efi
tmpfs                             99M     0   99M   0% /run/user/1000
10.132.212.247:/var/nfs/general   25G  1.8G   23G   8% /nfs/general
10.132.212.247:/home              25G  1.8G   23G   8% /nfs/home

Both of the shares we mounted appear at the bottom. Because they were mounted from the same file system, they show the same disk usage. To see how much space is actually being used under each mount point, use the disk usage command du and the path of the mount. The -s flag provides a summary of usage rather than displaying the usage for every file. The -h prints human-readable output.

For example:

du -sh /nfs/home

Output36K /nfs/home

This shows us that the contents of the entire home directory is using only 36K of the available space.

Step 6 — Testing NFS Access

Next, we will test access to the shares by writing something to both of them.

Example 1: The General Purpose Share

First, write a test file to the /var/nfs/general share:

sudo touch /nfs/general/general.test

Then, check its ownership:

ls -l /nfs/general/general.test

Output-rw-r--r-- 1 nobody nogroup 0 Aug  1 13:31 /nfs/general/general.test

Because we mounted this volume without changing NFS’s default behavior and created the file as the client machine’s root user via the sudo command, ownership of the file defaults to nobody:nogroup. client superusers won’t be able to perform typical administrative actions, like changing the owner of a file or creating a new directory for a group of users, on this NFS-mounted share.

Example 2: The Home Directory Share

To compare the permissions of the General Purpose share with the Home Directory share, create a file in /nfs/home the same way:

sudo touch /nfs/home/home.test

Then look at the ownership of the file:

ls -l /nfs/home/home.test

Output-rw-r--r-- 1 root root 0 Aug  1 13:32 /nfs/home/home.test

We created home.test as root using the sudo command, exactly the same way we created the general.test file. However, in this case it is owned by root because we overrode the default behavior when we specified the no_root_squash option on this mount. This allows our root users on the client machine to act as root and makes the administration of user accounts much more convenient. At the same time, it means we don’t have to give these users root access on the host.

Step 7 — Mounting the Remote NFS Directories at Boot

We can create persistent NFS mounts by adding them to the /etc/fstab file on the client. This ensures that your NFS shares are automatically mounted at boot time.

Open this file with root privileges in your text editor:

sudo nano /etc/fstab

At the bottom of the file, add a line for each of our shares. They will look like this:

/etc/fstab

. . .
host_ip:/var/nfs/general    /nfs/general   nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0
host_ip:/home               /nfs/home      nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

Note: You can find more information about the options we are specifying here in the NFS man page. You can access this by running the following command:

man nfs

The client will automatically mount the remote partitions at boot, although it may take a few moments to establish the connection and for the shares to be available.

If you no longer want the remote directory to be mounted on your system, you can unmount it by moving out of the share’s directory structure and unmounting, like this:

cd ~
sudo umount /nfs/home
sudo umount /nfs/general

Take note that the command is named umount not unmount as you may expect.

This will remove the remote shares, leaving only your local storage accessible:

df -h

OutputFilesystem                       Size  Used Avail Use% Mounted on
udev                             474M     0  474M   0% /dev
tmpfs                             99M  936K   98M   1% /run
/dev/vda1                         25G  1.8G   23G   8% /
tmpfs                            491M     0  491M   0% /dev/shm
tmpfs                            5.0M     0  5.0M   0% /run/lock
tmpfs                            491M     0  491M   0% /sys/fs/cgroup
/dev/vda15                       105M  3.9M  101M   4% /boot/efi
tmpfs                             99M     0   99M   0% /run/user/1000

If you also want to prevent them from being remounted on the next reboot, edit /etc/fstab and either delete the line or comment it out by placing a # character at the beginning of the line. You can also prevent auto-mounting by removing the auto option, which will allow you to still mount it manually.

Additional Considerations for Production Use

When deploying NFS in production environments, consider the following best practices to ensure stability, performance, and security:

For more advanced NFS configurations and use cases, check out our NFS Mount Collection which includes additional guides and best practices.

1. NFS Version Compatibility

Ensure both the client and server are running compatible versions. NFSv4 is recommended for its simplified firewall requirements and improved security features.

To force version usage during mount:

sudo mount -t nfs -o vers=4 host_ip:/path /mountpoint

2. Performance Optimization Flags

In addition to nconnect, consider these options:

• rsize=8192,wsize=8192: Increases the read/write buffer size for better throughput.
• async: Improves write performance but risks data loss on crash.
• actimeo=1800: Reduces attribute caching frequency.

3. Security Enhancements

NFS does not encrypt data by default. To secure your setup:

• Use NFS only over trusted private networks or VPN.
• Apply root_squash unless elevated access is essential.
• Restrict access in /etc/exports to specific IPs.

4. Logging and Monitoring

Monitor NFS activity for auditing or debugging:

tail -f /var/log/syslog | grep nfs

Or use:

journalctl -u nfs-server

Frequently Asked Questions (FAQs)

1. What is an NFS mount in Linux?

An NFS mount allows one system to access directories shared by another over the network. It enables seamless file sharing between Linux/Unix systems, making remote directories appear as if they are local. This is particularly useful for:

• Sharing application data across multiple servers
• Centralizing storage for easier backup and management
• Enabling multiple servers to access the same files
• Creating a distributed file system across your network

2. How do I persist an NFS mount after reboot?

You can edit /etc/fstab on the client and add your mount configuration. Here’s a detailed example:

# Format: host_ip:/shared_directory /mount_point nfs options 0 0
192.168.1.100:/var/nfs/general /nfs/general nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

Major options used with their explanation:

• auto: Mount automatically at boot
• nofail: Don’t halt boot process if mount fails
• noatime: Don’t update access times (improves performance)
• nolock: Disable file locking (useful for certain applications)
• intr: Allow interrupts on hard mounts
• tcp: Use TCP instead of UDP
• actimeo=1800: Cache attributes for 30 minutes

3. What ports are required for NFS to work?

NFS requires several ports for different versions and features:

• Port 2049 (TCP/UDP): Main NFS communication
• Port 111 (TCP/UDP): rpcbind (especially for NFSv3)
• Port 20048 (TCP/UDP): NFS mount daemon
• Port 20049 (TCP/UDP): NFS lock manager

For NFSv4, only port 2049 is required, making it easier to configure firewalls.

4. What are alternatives to NFS?

Several alternatives exist depending on your needs:

SSHFS:

• Encrypted, quick to set up
• Uses SSH for secure file transfer
• Good for occasional access
• Learn how to use SSHFS

Samba (SMB):

• Best for cross-platform (Windows-Linux) sharing
• Native Windows support
• Built-in authentication
• Good for mixed environments

rsync:

• Ideal for one-way or scheduled syncs
• Efficient for large file transfers
• Great for backups
• Can be automated with cron

5. How do I troubleshoot NFS mount issues?

Common troubleshooting steps:

• Check NFS service status:

sudo systemctl status nfs-kernel-server  # On host
sudo systemctl status nfs-common         # On client

• Verify exports:

sudo exportfs -v

• Check mount points:

df -h
mount | grep nfs

• View NFS logs:

tail -f /var/log/syslog | grep nfs

6. How do I secure my NFS setup?

Best practices for NFS security:

• Use NFSv4 for improved security
• Restrict exports to specific IPs in /etc/exports
• Use root_squash to prevent root access
• Implement firewall rules:

sudo ufw allow from client_ip to any port nfs

Use private networks or VPNs

Regular security audits of permissions

7. What performance optimizations are available?

Several options to improve NFS performance:

• Use nconnect for parallel connections:

mount -t nfs -o nconnect=8 host_ip:/share /mountpoint

• Adjust read/write sizes:

mount -t nfs -o rsize=8192,wsize=8192 host_ip:/share /mountpoint

• Use async for better write performance (with caution)
• Implement proper caching with actimeo
• Consider using 10gbit networking for better throughput

8. How do I unmount an NFS share?

To unmount an NFS share:

sudo umount /mountpoint

If the share is busy:

sudo umount -f /mountpoint  # Force unmount
sudo umount -l /mountpoint  # Lazy unmount

Remember to remove or comment out the corresponding line in /etc/fstab if you don’t want it to remount on reboot.

9. What are the differences between NFS versions?

Key differences between NFS versions:

NFSv3:

• Uses multiple ports
• Requires rpcbind
• Better performance than v2
• Still widely used

NFSv4:

• Single port (2049)
• Improved security
• Better performance
• Stateful protocol
• Recommended for new deployments

NFSv4.1:

• Parallel NFS (pNFS)
• Better scalability
• Session management
• Advanced features

10. How do I monitor NFS performance?

Several tools are available:

• nfsstat for NFS statistics:

nfsstat -c  # Client stats
nfsstat -s  # Server stats

• iostat for I/O statistics:

iostat -x 1

• nfsiostat for NFS-specific I/O:

nfsiostat 1

• System monitoring tools like Prometheus or Grafana with NFS exporters

11. What are common NFS mount options?

Important mount options:

1. rw/ro: Read-write or read-only
2. sync/async: Synchronous or asynchronous writes
3. no_root_squash: Allow root access
4. no_subtree_check: Disable subtree checking
5. soft/hard: How to handle server unavailability
6. intr: Allow interrupts on hard mounts
7. tcp/udp: Transport protocol
8. vers: NFS version to use

Example with multiple options:

mount -t nfs -o rw,sync,no_subtree_check,vers=4 host_ip:/share /mountpoint

Conclusion

In this tutorial, we created an NFS host and illustrated some key NFS behaviours by creating two different NFS mounts, which we shared with a NFS client.

If you’re looking to implement NFS in production, it’s important to note that the protocol itself is not encrypted. In cases where you’re sharing over a private network, this may not be a problem. In other cases, a VPN or some other type of encrypted tunnel will be necessary to protect your data. For encrypted alternatives, consider using SSHFS or setting up a VPN connection.

Next steps

To continue learning about network storage and file sharing, explore these related resources:

How to Use SSHFS to Mount Remote File Systems Over SSH: Learn about an alternative encrypted file sharing solution that uses SSH for secure connections.

How to Set Up an NFS Server Using Block Storage: Advanced NFS configuration using DigitalOcean Block Storage volumes for persistent, scalable storage.

NFS Mount Collection: Comprehensive collection of NFS-related guides covering various use cases and advanced configurations.

DigitalOcean Block Storage: Explore managed block storage volumes that can be attached to multiple Droplets for shared storage without managing NFS servers.

DigitalOcean Volumes Documentation: Learn more about volume limits, performance characteristics, and best practices for using block storage in your infrastructure.

When you’re ready to deploy, consider using DigitalOcean Droplets with private networking enabled for secure NFS communication between your servers.

This work is licensed under a Creative Commons Attribution-NonCommercial- ShareAlike 4.0 International License.