How to configure an NFS server and mount NFS shares on Ubuntu 18.04

Network File System (NFS) is a popular distributed filesystem protocol that enables users to mount remote directories on their server. The system lets you leverage storage space in a different location and write onto the same space from multiple servers in an effortless manner. It, thus, works fairly well for directories that users need to access frequently. This tutorial explains the process of mounting NFS share on an Ubuntu 18.04 server in simple and easy-to-follow steps.

Preliminary Information

For the purpose of this tutorial, there would be a directory sharing configuration between two Ubuntu 18.04 servers, which could be of any size. However, for each of these servers, you would need an account that has been set up with sudo privileges. The server that shall share its directories would be referred to as the host, while the server that shall mount these directories would be termed as the client. 3. For the purposes of uniformity and simplicity, the following IP addresses shall be used to refer to the host and server values throughout the tutorial:

  • Host:
  • Client:

Users must substitute the aforementioned values with their distinct host and client values. We are now all set to learn the steps in mounting an NFS share on Ubuntu 18.04 LTS.

Downloading and Installing the Components

At the outset, it is essential to install the necessary components on both the host and client servers. Expressly on the host server, you would be required to install the nfs-kernel-server package, which will enable you to share your directories. As this is the first step that you'l be performing with apt in this session, you must begin by refreshing the local package index before the installation (as given below):

sudo apt-get update
sudo apt-get install nfs-kernel-server

Upon installation of these packages, you may make the switch to the client computer. On the client computer, you would be required to install a package called nfs-common, that offers NFS functionality without the need to include the server components. Here again, you need to refresh the local package index prior to installation to ensure that you have updated information (as shown below):

sudo apt-get update
sudo apt-get install nfs-common

This brings you to the end of this step, and you may now move on to the next one.

Creating the Share Directory on the Host Server

For the purpose of this tutorial, there would be an experiment involving sharing two distinct directories. The first directory for sharing happens to be the /home directory containing user data. The second one would be a general purpose directory that would be created particularly for NFS so as to demonstrate the proper settings and processes. The same would be located at /var/nfs As the /home directory already exists, let us simply go ahead and begin by creating the /var/nfsdirectory, using the following command:

sudo mkdir /var/nfs

We now have a new directory expressly designated for sharing with remote hosts. However, the ownership of this directory is not yet ideal. We must assign user ownership to a user on our system named nobody. We must also assign the group ownership to a group on the system named nogroup. This can be done by keying in the following command:

sudo chown nobody:nogroup /var/nfs

It is important to note here that we must carefully change the ownership on only those directories that are particularly used for sharing. For instance, the ownership of the home directory (/home directory) must not be changed as it would cause numerous problems for users present on the host server.

Configuring the NFS Exports on the Host Server

With the directories created and assigned, we can now take a plunge into the NFS configuration file in order to set up the sharing of these resources. For that, you must open the /etc/exports file in the text editor with root privileges using the following command:

sudo nano /etc/exports

The files that will appear would contain a few comments to apprise you of the general structure of each configuration line. Essentially, the syntax would be similar to the following:

directory_to_share client (share_option2,...,share_optionM)

The aim here is to be able to create a line for each of the directories that must be shared. Since, in our chosen example, the IP happens to be, the lines should look something like the following:


Let us now take a while to understand the options given in the lines above.

  • rw: This option allows the client computer read as well as write access to the volume.
  • sync: It forces NFS to write changes to the disk before replying, thus resulting in a more stable and consistent environment. This is primarily because the reply replicates the actual state of the remote volume.
  • nosubtreecheck: This option averts subtree checking, which is a process that compels the host to check if the file is actually still available in the exported tree for each request. It may create problems when a file is renamed while the client has it opened. For the same reason, in roughly all the cases, it is advisable to disable subtree checking.
  • norootsquash: By default, the NFS translates requests from a root user remotely into a non-privileged one on the server. This is meant to be a security feature that does not allow a root account on the client to use the filesystem of the host as root. This kind of a directive disables this for a certain lot of shares.

Once you have made all the requisite changes, quite predictably, you must make the changes, and save these changes before closing the file. Subsequently, you must create the NFS table that holds the exports of your shares by using the following command:

sudo exportfs -a

However, the NFS service is not as yet running. You may start the same by typing the following command:

sudo service nfs-kernel-server start

The above command shall make your shares available to the clients that you would have configured. You are now ready to move on to the next step.

Creating the Mount Points and Mount Remote Shares on the Client Server

With the host server configured and making its directory shares available, you would now need to prep your client. Here, you would be required to mount the remote shares, hence you need to create a few mount points. You would be using the conventional /mnt to begin with, and subsequently, create a directory called NFS under it to consolidate the shares. Here, the actual directories shall correspond with their location on the host server. Users can create each directory, and the necessary parent directories, by using the following command:

sudo mkdir -p /mnt/nfs/home
sudo mkdir -p /mnt/nfs/var/nfs

Having created a decent place to house the remote shares, you are now in a position to mount them by addressing the host server, which, for the purpose of this tutorial is, as shown below:

sudo mount /mnt/nfs/home
sudo mount /mnt/nfs/var/nfs

These should let you mount the shares from the host computer onto the client machine. You may double check this by looking at the available disk space on the client server (as given below):

df -h

Filesystem Size Used Avail Use% Mounted on /dev/vda 59G 1.3G 55G 3% / none 4.0K 0 4.0K 0% /sys/fs/cgroup udev 2.0G 12K 2.0G 1% /dev tmpfs 396M 324K 396M 1% /run none 5.0M 0 5.0M 0% /run/lock none 2.0G 0 2.0G 0% /run/shm none 100M 0 100M 0% /run/user 59G 1.3G 55G 3% /mnt/nfs/home

As is evident at the bottom, only one of the intended shares is visible because both of the exported shares exist on the same filesystem on the remote server, which means they share the same pool of storage. For the Avail and Use% columns to be accurate, only one of the shares may be added into the calculations. Nonetheless, if you wish to view all of the NFS shares that you have mounted, you may type the following command:

mount -t nfs

The above command will throw up the entire lot of NFS mounts that are currently accessible on the client machine, which brings you to the end of this step, and it is now time to move on to the next one.

Testing NFS Access

You may test the shares access by writing something to your shares, for instance, a test file to one of your shares (as shown below):

sudo touch /mnt/nfs/home/test_home

Here, we shall also write test file to the other share to demonstrate an important difference:

sudo touch /mnt/nfs/var/nfs/test_var_nfs

Please look carefully at the ownership of the file in the mounted home directory (as shown below) to understand the difference:

ls -l /mnt/nfs/home/test_home
-rw-r--r-- 1 root   root      0 Apr 10 09:15 test_home

As is evident, the file is owned by root, the reason being that you.deactivated the root_squash option on this mount, which would have written the file as an unknown, non-root user. On the other test file, which was mounted with the root_squash enabled, you will notice something entirely different (as explained below):

ls -l /mnt/nfs/var/nfs/test_var_nfs
-rw-r--r-- 1 nobody nogroup 0 Apr 10 09:15 test_var_nfs

Clearly, this file was assigned to the nobody user and the nogroup group. Hence, this conforms to the preset configuration. Let us now move on to the next step.

Making Remote NFS Directory Mounting Automatic

You enjoy the option of making the remote NFS shares mounting automatic by adding it to the fstab file on the client. You need to open this file with root privileges in your text editor by using the following command:

sudo nano /etc/fstab

Right at the bottom of the file, you need to add a line for each of the shares, which would look something like what is given below:      /mnt/nfs/home   nfs auto,noatime,nolock,bg,nfsvers=4,intr,tcp,actimeo=1800 0 0 /mnt/nfs/var/nfs nfs auto,noatime,nolock,bg,nfsvers=4,sec=krb5p,intr,tcp,actimeo=1800 0 0

The options specified here may be found in the man page that describes NFS mounting in the fstab file, by using the following command:

man nfs

This will enable you to automatically mount the remote partitions at boot. It may take a while for the connection to be made and the shares to be available (patience is going to be a virtue here!!)

Unmounting an NFS Remote Share

If you do not require the remote directory to be mounted on your system any longer, you may unmount it easily by moving out of the share's directory structure and unmounting, using the following command:

cd ~
sudo umount /mnt/nfs/home
sudo umount /mnt/nfs/var/nfs

This shall allow you to remove the remote shares, rendering only your local storage accessible:

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda         59G  1.3G   55G   3% /	
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            2.0G   12K  2.0G   1% /dev
tmpfs           396M  320K  396M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            2.0G     0  2.0G   0% /run/shm
none            100M     0  100M   0% /run/user

As is clear, the NFS shares are now not available as storage space. This brings you to the end of the tutorial.


NFS offers a simple and swift mechanism to access remote systems over a network. However, the protocol stands unencrypted. If you intend to use this in a production environment, it is advisable to consider routing NFS over SSH or a VPN connection so as to create a far more secure experience.

Share this page:

Suggested articles

3 Comment(s)

Add comment


By: joede at: 2019-04-12 10:34:40

NFS is easy to configure and really very fast. Nearly no article about NFS mentions the years old problems. My experiences are based on Debian (6..8) as client and server, some Ubuntu releases and some Synology NAS devices.

(1) access control is based on the UID and GID. If these IDs differ between client and server, the service "idmapd" gets involved. But this thing is broken and doesn't work as expected.

(2) NFS transmits only the first 16 groups a user is member of. If you have access writes with are limitted to group #17, you don't have access!

Another problem is th handling of Wifi connections. Since NetworkManager doesn't dupport pre-down scripts anymore, the WLAN connection is disabled *before* the NFS share is unmounted! This leads to enormous timeouts at the shutdown.

By: thctlo at: 2019-04-16 14:40:20

above is nice, but still an out dated setup. 


1) Ow yes it does. execpt when people use reserved TLD, this might go wrong, in these cases, configure /etc/idmapd.conf 2) One i didnt know, thanks for that one. 3) about the shutdown, reconfigure the service so the order is better. 


By: Heikki Moisander at: 2019-04-20 10:26:31

We had to give up using nfs as timeouts were unbearable and I could not figure out how to fix it. How to reconfigure the service so the order is better?