How To Set Up NFS Mount on Ubuntu

Today! A new topic to help in your networking:  How to set Up NFS Mount on Ubuntu.

NFS

• NFS, or 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 Server provides a relatively quick and easy way to access remote systems over a network and works well in situations where the shared resources must be accessed regularly.

 Set Up NFS Mount on Ubuntu

In this tutorial:

• we will teach you how to install the components needed for NFS functionality, configure NFS mounts, and unmount an NFS remote share.

Before going into details, see our hand-picked VPS hosting and WordPress hosting services.

Prerequisites

• We will use two servers in this tutorial, one sharing part of its filesystem with the other. To follow along, you will need:
• Two Ubuntu 18.04 servers. Each of these should have a non-root user with sudo privileges configured, a simple firewall set up with UFW, and private networking, if it’s available to you.
• 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’.
• In order to keep them straight, we’ll use the following IP addresses as stand-ins for the host and client values:

• Host: 203.0.113.0
• Client: 203.0.113.24

When these IP addresses appear in commands and configuration files, you will need to replace them with your own respective ‘host’ and ‘client’ IP addresses.

1. Downloading and Installing the Components

Begin by installing the necessary components on each server.

On the Host

• On the host server, install the ‘nfs-kernel-server’ package; this 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

1. On the client-server, you need to install a package called ‘nfs-common’, which provides NFS functionality without including unneeded server components.
2. 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, you can start configuring them.

2. Creating the Share Directories on the Host

You’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.
Trusted Users:
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.

This is an example of exporting a General Purpose Mount

In the first example, we will create a general-purpose NFS mount that uses default NFS behavior 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 which were uploaded using a content management system or to create space for users to easily share project files.
Now we will create a share directory named ‘nfs’.

sudo mkdir /var/nfs/general -p

Because you are creating it with sudo, the directory is going to be owned by the root user on the host.

ls -la /var/nfs/general

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

Output
4 drwxr-xr-x  2 root   root    4096 Jul 25 15:26 .

You’re now ready to export this directory.

Second Example, Exporting the Home Directory

• In this 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, export the ‘/home’ directory. Since it already exists, you don’t need to create it.
• You won’t need to change the permissions, either. If you did, it could lead to a range of issues for anyone with a home directory on the host machine.

3. Configuring the NFS Exports on the Host Server

Next, dive into the NFS configuration file to set up the sharing of these resources.
Open the ‘/etc/exports’ file in your text editor with root privileges

sudo chown nobody:nogroup /var/nfs/general

The file has comments showing the general structure of each configuration line. The syntax is basically like below.

/etc/exports
directory_to_share    client(share_option1,...,share_optionN)

1. You will need to create a line for each of the directories that you plan to share. Since our example client has an IP of 203.0.113.24, the lines will look like the following.
2. Be sure to change the IP address shown here to that of your client.

/etc/exports
/var/nfs/general    203.0.113.24(rw,sync,no_subtree_check)
/home       203.0.113.24(rw,sync,no_root_squash,no_subtree_check)

Here, the same configuration is being used for options for both directories with the exception of ‘no_root_squash’. Let’s take a look at what each of these options mean:

• 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 have configured, restart the NFS server with the following command.

sudo systemctl restart nfs-kernel-server

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

4. In this part we will adjust the Firewall on the Host

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

sudo ufw status

Output
Status: active
To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

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

• With many applications, you can use ‘sudo ufw app list’ and enable them by name, however, nfs is not one of those.
• As ‘ufw’ also checks ‘/etc/services’ for the port and protocol of a service, you can still add NFS by name.
• We recommend the Best practice that you can enable the most restrictive rule that will still allow the traffic you want to permit, so rather than enabling traffic from just anywhere, you can be specific.
• Use the following command to open port 2049 on the host, being sure to substitute your client’s IP address.

• sudo ufw allow from 203.0.113.24 to any port nfs

You can verify the change by typing the below.

sudo ufw status

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

Output
Status: 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.

5. Create and Mounting Directories on the Client

Now that the host server is configured and serving its shares, prepare your client.

1. In order to make the remote shares available on the client, you need to mount the directories on the host that you want to share to empty directories on the client.
2. Note: If there are files and directories in your mount point, they will become hidden as soon as you mount the NFS share.
3. To avoid the loss of important files make sure that, if you mount in a directory that already exists, that this directory is empty.

Create two directories for your mounts:

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

Now that you have a location in which to put the remote shares and you have opened the firewall, you can mount the shares by addressing your host server; in this guide it is 203.0.113.0.

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

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 plain mount or ‘findmnt’ command; ‘df -h’ provides a more easily readable output that illustrates how disk usage is displayed differently for the NFS shares.

df -h

Output
Filesystem                Size  Used Avail Use% Mounted on
udev                      238M     0  238M   0% /dev
tmpfs                      49M  628K   49M   2% /run
/dev/vda1                  20G  1.2G   18G   7% /
tmpfs                     245M     0  245M   0% /dev/shm
tmpfs                     5.0M     0  5.0M   0% /run/lock
tmpfs                     245M     0  245M   0% /sys/fs/cgroup
tmpfs                      49M     0   49M   0% /run/user/0
203.0.113.0:/home      20G  1.2G   18G   7% /nfs/home
203.0.113.0:/var/nfs/general   20G  1.2G   18G   7% /nfs/general

Both of the shares you have  mounted appear at the bottom. As 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

Results
36K /nfs/home

This will show us that the contents of thewhole home directory is using only 36K of the available space.
6. Testing NFS Access
Next, let’s test access to the shares by writing something to each of them.

First example:  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

• As you have 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.

Second example: The Home Directory Share

• To compare the permissions of the General Purpose share with the Home Directory share, create a file Home Directory 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

‘home.test’ was created as root using the ‘sudo’ command, exactly the same way the ‘general.test’ file was created. 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 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 you don’t have to give these users root access on the host.

7. Mounting the Remote NFS Directories at Boot

You can mount the remote NFS shares automatically at boot by adding them to ‘/etc/fstab’ file on the client.
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 your shares. They should look like the below.

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

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

man nfs

The client server 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.

8. Unmounting an NFS Remote Share

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 below.

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

This should get rid of the remote shares, and leaving only your local storage accessible.

df -h

Output
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

If you also want to prevent them from being remounted on the next reboot, edit ‘/etc/fstab’ and either deleting the line or commenting it out by placing a ‘#’ symbol at the beginning of the line. You can also prevent auto-mounting by removing the auto option; this will allow you to mount it manually.

Conclusion

In this tutorial, we created an NFS host and illustrated some key NFS behaviors by creating two different NFS mounts, which we shared with our 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 files that are intended to be publicly accessible, this doesn’t cause any serious problems.
• If you’re using NFS for private data, however, you’ll need to decide how you want to protect that data.
• You might be able to route NFS over SSH or a VPN connection to create a more secure experience, however, this often comes with a significant reduction in performance.
• If performance is an issue, consider SSHFS. It’s slightly slower than unencrypted NFS traffic but usually much faster than tunnelled NFS.
• Kerberos authenticated encryption for NFS is another option to explore.

Don’t forget to subscribe to our email newsletter for more helpful tips, insights, and tutorials;
Want more details? Check out our more tutorial guides on Linux and Windows and VPS:
How to install PyCharm on Ubuntu 16.04