Principles of using the NFS file system to create shared network resources based on Linux systems

Creating shared network resources within a cluster is an essential part of a network administrator’s work. A number of software tools can be used to configure such clusters, including NCP (NetWare Core Protocol), SMB (Server Message Block), and several others.

However, for Linux-based systems, the most widely used network protocol is NFS (Network File System), which is designed to work with various types of file systems. Unlike, for example, FTP, it provides transparent access to remote files, making operations with them no different from working with local files.

Let’s look at the protocol’s features and examples of its practical application.

Characteristics of the NFS Protocol

The protocol was developed by Sun Microsystems based on the open network protocol for remote procedure calls — RPC (Open Network Computing Remote Procedure Call).

NFS has both client and server components, which are installed on network nodes independently of one another.

Clients gain access to server resources by sending requests to the server in the RPC format.

Here are some of the most important characteristics of NFS:

• Hardware independence of network nodes;
• Support for most well-known operating systems (OS): Windows, macOS, IBM i, and others;
• Recovery after client or server failures;
• Transparent access to remote resources without recompilation, path adjustments, or additional libraries;
• Performance comparable to disk storage devices;
• Remote and local files appear identical to the client;
• Ability to use the TCP/IP protocol stack for transport;
• The server receives requests from the client on a fixed port, 2049;
• Improved performance due to the use of multiple NFS servers or user-defined nfsd processes depending on system configuration;
• Each cluster node can function as both a server and a client.

The current latest version of the software is version 4.2, which includes, in particular, server-side cloning and copying operations, application data blocks, reservation tools, sparse files, and other enhancements.

Depending on the implementation, NFS may include several additional modules that expand its functionality. For example, the NLM lock manager and the NSM service, which monitors network status. Their combined use helps optimize system performance.

Practical Use of NFS

In practice, two main approaches are commonly used to organize an NFS-based cluster:

• Using a shared storage directory on the server;
• Using remote user home directories instead of local ones.

Both options help significantly reduce disk usage on client machines and optimize user workflows within the cluster.

Let’s explore how to implement each approach when the cluster consists of two nodes running Ubuntu 22.04.

Configuring Shared Storage

In this case, there is no need to provide root access to server resources from the clients, meaning the server is not exposed to unnecessary risk. A method for implementing such an architecture is already built into the protocol.

By default, the protocol is configured so that all client root commands are automatically mapped to the nobody:nogroup account. The administrator only needs to change the owner of the shared resource on the server to match this account’s parameters.

System Update

Before installing the server component, the server’s software environment must be updated.
Use the following commands:

$ sudo apt update
$ sudo apt list --upgradable

Installing and Activating the NFS Server

After the update is complete, you can proceed with installation:

$ sudo apt install nfs-kernel-server

After running the command, the application deployment process will begin.
In the final output window, you should see the message “Setting up nfs-kernel-server 1:2.6.1 …”, confirming that the installation finished successfully.

Next, start the NFS server:

$ sudo systemctl start nfs-kernel-server.service

Creating a Shared Resource on the Server

Create a shared directory on the server named all_users:

$ sudo mkdir /var/nfs/all_users -p

The newly created directory is owned by root.
Change the owner so that NFS blocks administrative requests, as described earlier:

$ sudo chown nobody:nogroup /var/nfs/all_users

The shared resource is now configured and almost ready for export. All that remains is to set export parameters that define access rights and other characteristics.

To do this, we use the system file /etc/exports. Open it with the nano editor:

$ sudo nano /etc/exports

Insert the following line into the file:

/var/nfs/all_users 178.21.139.65(rw,sync,no_subtree_check)

The options in parentheses mean the following:

• rw – allows reading and writing data;
• sync – synchronizes the current directory state before each client response;
• no_subtree_check – disables subtree checking when verifying file availability.

Configuring UFW

To allow the client to access the shared resource through server port 2049, firewall rules must be updated.

First, enable UFW:

$ sudo ufw enable

The output should include:
“Firewall is active and enabled …”

Check the current rules:

$ sudo ufw status

The output will look similar to:

To Action From
80/tcp ALLOW Anywhere
22/tcp ALLOW Anywhere
80/tcp (v6) ALLOW Anywhere (v6)
22/tcp (v6) ALLOW Anywhere (v6)

Add a rule:

$ sudo ufw allow from 178.21.139.65 to any port nfs

Here, 178.21.139.65 is the client machine’s IP address.

The command will output: “Rule added”, indicating success.

After checking the updated firewall rules, a line like this will appear:

To Action From
2049 ALLOW 178.21.139.65

This confirms that client access to the server is now open.

Client Configuration

On the client machine, you also need to update the software environment, just like we did earlier for the server, and then install the client component by running:

$ sudo apt install nfs-common

After successful installation, the output should show a message like:
“Setting up nfs-common 1:2.6.1…”

Configuring Remote User Home Directory

When configuring such a cluster, many steps are the same as those we performed on the server side when setting up the shared resource. The difference lies in that there is no need to change the directory owner, and there are different entries in the configuration file /etc/exports.

For the cluster configuration, we will use the existing home directory on the server.

Make the necessary changes in the /etc/exports file:

$ sudo nano /etc/exports

Insert the following line into the opened file:

/home 178.21.139.65(rw,sync,no_root_squash,no_subtree_check)

Here, the no_root_squash parameter disables the default NFS behavior and allows the client to have root access to the home directory. The other parameter values have been previously explained.

Mounting Server Resources on the Client Machine

No matter which type of cluster configuration is used, the same mount operations are employed. Let’s look at the sequence of steps for mounting directories in both of the previously discussed cases.

Create empty directories on the client machine that correspond to the server’s resources:

$ sudo mkdir -p /nfs/all_users
$ sudo mkdir -p /nfs/home

The mount commands will look like this:

$ sudo mount 178.21.139.66:/var/nfs/all_users /nfs/all_users
$ sudo mount 178.21.139.66:/home /nfs/home

Where 178.21.139.66 is the server’s IP address.

Verify the result of these commands:

$ df -h

The command’s output should look roughly like this:

You can confirm that, in our case, the shared resources are successfully mounted on the client machine.

Access Verification

Check the accessibility of the server’s resources. In the shared directory all_users, create a test file named all_users.new:

$ sudo touch /nfs/all_users/all_users.new

Check the file ownership permissions:

$ ls -l /nfs/all_users/all_users.new

The result should be roughly:

-rw-r--r-- 1 nobody nogroup 0 Mar 12 11:06 /nfs/all_users/all_users.new

This result indicates that the shared resource is correctly configured, because its owner is nobody nogroup, not root. This means that the client cannot perform actions that require administrative privileges here.

Similarly, create a test file named home.new in the remote home directory:

$ sudo touch /nfs/home/home.new

Check the owner’s permissions:

$ ls -l /nfs/home/home.new

Output of the command:

-rw-r--r-- 1 root root 0 Mar 12 11:12 /nfs/home/home.new

You can confirm that the file owner is the root user. This means that administrative actions from the client are allowed here, which fully corresponds to our initial settings.

Mounting Automation

After every reboot of the client machine, the mounted shared resources are reset unless they are listed in the /etc/fstab file. If they are listed there, mounting happens automatically.

You can add the required records to the file using the command:

$ sudo nano /etc/fstab

Add the following lines to the file:

178.21.139.66:/var/nfs/all_users /nfs/all_users nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0
178.21.139.66:/home /nfs/home nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

After saving the changes, the resources will be mounted automatically.

If you need to disable automatic mounting, simply comment out the entries above or remove the auto parameter.