How to configure an NFS server and mount NFS shares on Ubuntu 14.04
This tutorial exists for these OS versions
- Ubuntu 22.04 (Jammy Jellyfish)
- Ubuntu 20.04 (Focal Fossa)
- Ubuntu 18.04 (Bionic Beaver)
- Ubuntu 14.04 LTS (Trusty Tahr)
- Ubuntu 10.04 (Lucid Lynx)
On this page
- 1.1 NFS-An Overview
- 1.2 Preliminary Information
- 1.3 Downloading and Installing the Components
- 1.4 Creating the Share Directory on the Host Server
- 1.5 Configuring the NFS Exports on the Host Server
- 1.6 Creating the Mount Points and Mount Remote Shares on the Client Server
- 1.7 Testing NFS Access
- 1.8 Making Remote NFS Directory Mounting Automatic
- 1.9 Unmounting an NFS Remote Share
- 1.10 Wrap Up
1.1 NFS-An Overview
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 14.04 server in an simple and easy-to-follow steps.
1.2 Preliminary Information
1. For the purpose of this tutorial, there would be a directory sharing configuration between two Ubuntu 14.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. 2. For the purposes of this tutorial, 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: 22.214.171.124
- Client: 333. 333. 333. 333
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 14.04
1.3 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â€™ll 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.
1.4 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 noone. We must also assign the group ownership to a group on the system named anygroup. This can be done by keying in the following command:
sudo chown noone:anygroup /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.
1.5 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 333.333.333.333, the lines should look something like the following: /home 333.333.333.333(rw,sync,no_root_squash,no_subtree_check) /var/nfs 333.333.333.333(rw,sync,no_subtree_check) 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.
1.6 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 126.96.36.199, as shown below:
sudo mount 188.8.131.52:/home /mnt/nfs/home
sudo mount 184.108.40.206:/var/nfs /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):
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 220.127.116.11:/home 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
18.104.22.168:/home on /mnt/nfs/home type nfs (rw,vers=4,addr=22.214.171.124,clientaddr=333.333.333.333) 126.96.36.199:/var/nfs on /mnt/nfs/var/nfs type nfs (rw,vers=4,addr=188.8.131.52,clientaddr=333.333.333.333)
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.
1.7 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 27 12:58 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 noone anybody 0 Apr 27 12:58 test_var_nfs
Clearly, this file was assigned to the noone user and the anybody group. Hence, this conforms to the preset configuration. Let us now move on to the next step.
1.8 Making Remote NFS Directory Mounting Automatic
You enjoy the option of making the remote NFS shares mounting automatic by adding it to the fstabfile 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:
184.108.40.206:/home /mnt/nfs/home nfs auto,noatime,nolock,bg,nfsvers=4,intr,tcp,actimeo=1800 0 0
220.127.116.11:/var/nfs /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:
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!!)
1.9 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:
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.
1.10 Wrap Up
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.