Read in 9 minutes

last updated 

How to Install and Configure an NFS Server on Ubuntu 18.04

Network File System (NFS) is a distributed file system protocol that allows you to share remote directories over a network. With NFS, you can mount remote directories on your system and work with the files on the remote machine as if they were local files.

NFS protocol is not encrypted by default and unlike Samba, it does not provide user authentication. Access to the server is restricted by the clients IP addresses or hostnames.

In this tutorial, we’ll go over how to set up an NFSv4 Server on Ubuntu 18.04. We’ll also show you how to mount an NFS file system on the client.

Prerequisites

This example assumes that you have one server running Ubuntu 18.04 and another one running any other Linux distribution. The server and the clients should be able to communicate with each other over a private network. If your hosting provider doesn’t offer private IP addresses, you can use the public IP addresses and configure the server firewall to allow traffic on port 2049 only from trusted sources.

The machines in this example have the following IPs:

NFS Server IP: 192.168.33.10
NFS Clients IPs: From the 192.168.33.0/24 range

Set Up the NFS Server

We’ll start by installing and configuring the NFS server.

Installing the NFS server

Refresh the packages index and install the NFS server package:

sudo apt update
sudo apt install nfs-kernel-server

Once the installation is completed, the NFS services will start automatically.

By default, on Ubuntu 18.04 NFS version 2 is disabled. Versions 3 and 4 are enabled. You can verify that by running the following cat command:

sudo cat /proc/fs/nfsd/versions
-2 +3 +4 +4.1 +4.2

NFSv2 is pretty old now, and there is no reason to enable it.

NFS server configuration options are set in /etc/default/nfs-kernel-server and /etc/default/nfs-common files. The default settings are sufficient in our case.

Creating the file systems

When configuring an NFSv4 server it is a good practice is to use a global NFS root directory and bind mount the actual directories to the share mount point. In this example, we will use the /srv/nfs4 director as NFS root.

We’re going to share two directories (/var/www and /opt/backups), with different configuration settings, to better explain how the NFS mounts can be configured.

The /var/www/ is owned by the user and group www-data and /opt/backups is owned by root.

Create the export filesystem using the mkdir command:

sudo mkdir -p /srv/nfs4/backups
sudo mkdir -p /srv/nfs4/www

Mount the actual directories:

sudo mount --bind /opt/backups /srv/nfs4/backups
sudo mount --bind /var/www /srv/nfs4/www

To make the bind mounts permanent, open the /etc/fstab file:

sudo nano /etc/fstab

and add the following lines:

/etc/fstab
/opt/backups /srv/nfs4/backups  none   bind   0   0
/var/www     /srv/nfs4/www      none   bind   0   0

Exporting the file systems

The next step is to define the file systems that will be exported by the NFS server, the shares options and the clients that are allowed to access those file systems. To do so open the /etc/exports file:

sudo nano /etc/exports
The /etc/exports file also contains comments that describe how to export a directory.

In our case we need to export the www and backups directories and allow access only from clients on the 192.168.33.0/24 network:

/etc/exports
/srv/nfs4         192.168.33.0/24(rw,sync,no_subtree_check,crossmnt,fsid=0)
/srv/nfs4/backups 192.168.33.0/24(ro,sync,no_subtree_check) 192.168.33.3(rw,sync,no_subtree_check)
/srv/nfs4/www     192.168.33.110(rw,sync,no_subtree_check)

The first line contains fsid=0 which defines the NFS root directory /srv/nfs. The access on this NFS volume is allowed only to the clients from the 192.168.33.0/24 subnet. The crossmnt option is required to share directories that are sub-directories of an exported directory.

In the second line shows how to specify multiple export rules for one filesystem. It exports the /srv/nfs4/backups directory and allows only read access to the whole 192.168.33.0/24 range and both read and write access to 192.168.33.3. The sync option tells NFS to write changes to disk before replying.

The last line should be self-explanatory. For more information about all the available options type man exports in your terminal.

Save the file and export the shares:

sudo exportfs -ra

You need to run the command above each time you modify the /etc/exports file. If there are any errors or warnings they will be shown on the terminal.

To view the current active exports and their state, use:

sudo exportfs -v

The output will include all shares with their options. As you can see there are also options that we haven’t define in the /etc/exports file. Those are default options and if you want to change them you’ll need to explicitly set those options.

/srv/nfs4/backups
		192.168.33.3(rw,wdelay,root_squash,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)
/srv/nfs4/www 	192.168.33.110(rw,wdelay,root_squash,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)
/srv/nfs4     	192.168.33.0/24(rw,wdelay,crossmnt,root_squash,no_subtree_check,fsid=0,sec=sys,rw,secure,root_squash,no_all_squash)
/srv/nfs4/backups
		192.168.33.0/24(ro,wdelay,root_squash,no_subtree_check,sec=sys,ro,secure,root_squash,no_all_squash)

On Ubuntu, root_squash is enabled by default. This is one of the most important options concerning NFS security. It prevents root users connected from the clients to have root privileges on the mounted shares. It will map root UID and GID to nobody/nogroup UID/GID.

In order for the users on the client machines to have access, NFS expects the client’s user and group ID’s to match with those on the server. Another option is to use the NFSv4 idmapping feature that translates user and group IDs to names and the other way around.

That’s it. At this point, you have set up an NFS server on your Ubuntu server. You can now move to the next step and configure the clients and connect to the NFS server.

Firewall configuration

If you run a firewall on your network, you’ll need to add a rule that will enable traffic on the NFS port.

Assuming you are using UFW to manage your firewall to allow access from the 192.168.33.0/24 subnet you need to run the following command:

sudo ufw allow from 192.168.33.0/24 to any port nfs

To verify the change run:

sudo ufw status

The output should show that the traffic on port 2049 is allowed:

To                         Action      From
--                         ------      ----
2049                       ALLOW       192.168.33.0/24           
22/tcp                     ALLOW       Anywhere                  
22/tcp (v6)                ALLOW       Anywhere (v6)  

Set Up the NFS Clients

Now that the NFS server is setup and shares are exported the next step configure the clients and mount the remote file systems.

You can also mount the NFS share on macOS and Windows machines but we will focus on Linux systems.

Installing the NFS client

On the client machines we need to install only the tools required to mount a remote NFS file systems.

  • Install NFS client on Debian and Ubuntu

    The name of the package that includes programs for mounting NFS file systems on Debian based distributions is nfs-common. To install it run:

      
    sudo apt update
    sudo apt install nfs-common
  • Install NFS client on CentOS and Fedora

    On Red Hat and its derivatives install the nfs-utils package:

    sudo yum install nfs-utils

Mounting file systems

We’ll work on the client machine with IP 192.168.33.110 which has read and write access to the /srv/nfs4/www file system and read only access to the /srv/nfs4/backups file system.

Create two new directories for the mount points. You can create this directories at any location you want.

sudo mkdir -p /backups
sudo mkdir -p /srv/www

Mount the exported file systems with the mount command:

sudo mount -t nfs -o vers=4 192.168.33.10:/backups /backups
sudo mount -t nfs -o vers=4 192.168.33.10:/www /srv/www

Where 192.168.33.10 is the IP of the NFS server. You can also use the hostname instead of the IP address but it needs to be resolvable by the client machine. This is usually done by mapping the hostname to the IP in the /etc/hosts file.

When mounting an NFSv4 filesystem, you need to ommit the NFS root directory, so instead of /srv/nfs4/backups you need to use /backups.

Verify that the remote file systems are mounted successfully using either the mount or df command:

df -h

The command will print all mounted file systems. The last two lines are the mounted shares:

Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00   38G  1.7G   36G   5% /
devtmpfs                         236M     0  236M   0% /dev
tmpfs                            244M     0  244M   0% /dev/shm
tmpfs                            244M  4.5M  240M   2% /run
tmpfs                            244M     0  244M   0% /sys/fs/cgroup
/dev/sda2                       1014M   87M  928M   9% /boot
tmpfs                             49M     0   49M   0% /run/user/1000
192.168.33.10:/backups           9.7G  1.2G  8.5G  13% /backups
192.168.33.10:/www               9.7G  1.2G  8.5G  13% /srv/www

To make the mounts permanent on reboot, open the /etc/fstab file:

sudo nano /etc/fstab

and add the following lines:

/etc/fstab
192.168.33.10:/backups /backups   nfs   defaults,timeo=900,retrans=5,_netdev	0 0
192.168.33.10:/www /srv/www       nfs   defaults,timeo=900,retrans=5,_netdev	0 0

To find more information about the available options when mounting an NFS file system, type man nfs in your terminal.

Another option to mount the remote file systems is to use either the autofs tool or to create a systemd unit.

Testing NFS Access

Let’s test the access to the shares by creating a new file to each of them.

First, try to create a test file to the /backups directory using the touch command:

sudo touch /backups/test.txt

The /backup file system is exported as read-only and as expected you will see a Permission denied error message:

touch: cannot touch ‘/backups/test’: Permission denied

Next, try to create a test file to the /srv/www directory as a root using the sudo command:

sudo touch /srv/www/test.txt

Again, you will see Permission denied message.

touch: cannot touch ‘/srv/www’: Permission denied

If you recall the /var/www directory is owned by the www-data user and this share has root_squash option set which maps the root user to the nobody user and nogroup group that doesn’t have write permissions to the remote share.

Assuming that you have a www-data use on the client machine with the same UID and GID as on the remote server (which should be the case if for example, you installed nginx on both machines) you can test to create a file as user www-data with:

sudo -u www-data touch /srv/www/test.txt

The command will show no output which means the file was successfully created.

To verify it list the files in the /srv/www directory:

ls -la /srv/www

The output should show the newly created file:

drwxr-xr-x 3 www-data www-data 4096 Jun 23 22:18 .
drwxr-xr-x 3 root     root     4096 Jun 23 22:29 ..
-rw-r--r-- 1 www-data www-data    0 Jun 23 21:58 index.html
-rw-r--r-- 1 www-data www-data    0 Jun 23 22:18 test.txt

Unmounting NFS File System

If you no longer need the remote NFS share, you can unmount it as any other mounted file system using the umount command. For example, to unmount the /backup share you would run:

sudo umount /backups

If the mount point is defined in the /etc/fstab file, make sure you remove the line or comment it out by adding # at the beginning of the line.

Conclusion

In this tutorial, we have shown you how to set up an NFS server and how to mount the remote file systems on the client machines. If you’re implementing NFS in production and sharing sensible data it is a good idea to enable kerberos authentication.

As an alternative to NSF, you can use SSHFS to mount remote directories over an SSH connection. SSHFS is encrypted by default and much easier to configure and use.

Feel free to leave a comment if you have any questions.