NFS CONFIGURATION IN LINUX UBUNTU -16.04.3-server

Sankalpa H.T.S
Jul 4, 2018
6 min read

Updated: Oct 14, 2019

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 provides a relatively quick and easy way to access remote systems over a network and works well in situations where the shared resources will be accessed regularly. In this guide, we'll cover how to configure NFS mounts.

Throughout the 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:

• Client: 192.168.100.8 host name - “nfs_client”

• Host: 192.168.100.9 host name - “nfs_server”

You should replace these values with your own host and client ip addresses.

On the Host

On this server, we need to install a package called nfs-common, which provides NFS functionality without including unneeded server components. Again, we will refresh the local package index prior to installation to ensure that we have up-to-date information:

On the Client

On this server, we will install the nfs-kernel-server package, which will allow us to share our directories. Since this is the first operation that we're performing with apt in this session, we'll refresh our local package index before the installation:

Creating the Share Directories on the Client

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, re-assign ownership, or perform any other superuser tasks on the NFS mount.

Sometimes, however, there are trusted users on the client system who need to be able to do these things on the mounted file system but who have no need for superuser access on the host. The NFS server can be configured 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 behavior to makes it difficult for a user with root privileges on the client machine to interact with the client using those host superuser privileges. You might use something like this to store the files uploaded using a content management system or to create space for users to easily share project files. First, make a share directory called nfs:

Since we’re creating it with super user mod, the directory is owned by root here on the client.

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

Example 2: Exporting the Home Director

In our second example, the goal is to make user home directories stored on the host available on host servers, while allowing trusted administrators of those host 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 would cause all kinds of issues for anyone with a home directory on the client machine.

Configuring the NFS Exports on the Client Server

Next, we’ll 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:

File looks like below:

We’ll need to create a line for each of the directories that we plan to share. Since our example host has an IP of 192.168.100.9, our lines will look like the following. Be sure to change the IPs to match your host:

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 one means.

• rw: This option gives the hostt 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 client 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 host from using the file system of the client 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 hosts that you configured, restart the NFS server with the following command:

tail -f /var/log/syslog for errors:

Service will be restarted.

Adjusting the IPTABLES on the Client

First, let’s check the iptables rule list to see if it has some rules and if so, to see what's currently permitted:

Here we can see there are no existing rules.

Best practice recommends that you add 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 client, being sure to substitute your client's ip address:

Confirm the added iptable rule:

Creating the Mount Points on the Host

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

In order to make the remote shares available on the host, we need to mount the client directory on an empty host directory.

Note: If there are files and directories in your mount point, as soon as you mount the NFS share, they’ll be hidden. Be sure if you mount in a directory that already exists that the directory is empty.

We’ll create two directories for our mounts:

Verify the directories we made:

Mounting the Directories on the Host

Now that we have some place to put the remote shares and we've added the iptable rule to ACCEPT the incoming traffic to port 2049 , we can mount the shares by addressing our client server, which in this guide is 192.168.100.8, like this:

Before we mount type and see df -h command:

These commands should mount the shares from the host computer onto the host machine.

You can double-check that they mounted successfully in several ways. You can check this with a plain mount or findmnt command, but df -h will give you more human readable output illustrates how disk usage is displayed differently for the nfs shares:

Testing NFS Access

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

touch amaa.txt

Then, check its ownership:

Because we mounted this volume without changing NFS’s default behavior and created the file as the host machine’s root user via the sudo command, ownership of the file defaults to nobody:nogroup. Host 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.

In the client machine check whether the test file amaa.txt we created in client machine is also created in its mount point:

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:

It already shows you the directories exist in client machine’s home folder in the host’s mount directory: write a test file to the /home/nfs/home:

Verify it:

On the client machine check whether the created file shared:

Mounting the Remote NFS Directories at Boot

We can mount the remote NFS shares automatically at boot by adding them to /etc/fstab file on the host.

Open this file with root privileges in your text editor:

File will looks like below:

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

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

Check now for verify mount points:

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 this:

Check whether unmount the remote share. This will remove the remote shares, leaving only your local storage accessible:

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 # symbol at the beginning of the line. You can also prevent auto-mounting by removing the auto option, which will allow you to mount it manually.