Sun Microsystems’ NFS (Network File System) is an RPC-based distributed file system structure that allows networked devices to use servers running NFS over a network as their local drives.
Here’s a step-by-step guide to setting up and configuring an NFS server on a Linux machine.
What Is Network File System?
The NFS file system has four protocols. When the server is ready, it notifies portmap (the server that converts protocol to port numbers) of the port to use and provides the controlled RPC program number.
When using an embedded Linux system, it is very convenient to boot your device via an NFS file share over the network instead of starting it directly from the storage device (NAND flash, eMMC, MMC, etc.).
Although rarer, you may also want to mount an NFS share and perform file shares using it after the system boots up, even if you don’t boot your system directly from the NFS share. For both scenarios to work, you must first install an NFS server on the computer you are developing on.
How to Install NFS on Linux
If you are using a Debian-based system such as Ubuntu or Linux Mint, you should install the nfs-kernel-server package as follows:
sudo apt install nfs-kernel-server
On Arch Linux:
sudo pacman -S nfs-utils
On Fedora, CentOS, and RHEL:
sudo dnf -y install nfs-utils
At the end of the process, your NFS server will run automatically. However, at this point, it does not yet know which directories on your computer you want to share over the network. Therefore, it does not provide any sharing by default.
You can open multiple directories on the same server to allow network sharing with different authorizations and restrictions.
Configuring the NFS Server on Linux
To share any directory over the NFS server, it is necessary to configure a directory-related setting in the /etc/exports file. Open the file with any text editor of your choice. Make sure to add the sudo prefix to the command.
sudo vim /etc/exports
You may be wondering what the mapping options you see here mean:
- root_squash: Marks sudo authorized client users as nobody user and group on NFS
- no_root_squash: Disables root squashing
- all_squash: Unlike root_squash, it allows all users to be mapped as the nobody user and group. It is generally used for public access.
- no_all_squash: The opposite of all_squash; this option is the default
When a system outside of the IP ranges you allow in the /etc/exports file on the NFS server tries to access the relevant resource, the NFS server will reject the request.
You may receive “access denied by server” messages while mounting on your embedded system. Error messages similar to the following will appear at the end of the /var/log/syslog file on the computer where the NFS server is running:
rpc.mountd: refused mount request from 192.168.2.2 for /home/example/casper/target (/home/example/casper/target): unmatched host
When you see an unmatched host log message like the one above, you should expand the IP/Netmask section of the relevant rule in the /etc/exports file or use the asterisk (*) special character if you want to grant access to all IP addresses.
You must restart the NFS service after making modifications to the /etc/exports file:
sudo service nfs-kernel-server restart
Or, if your distro ships with systemctl, run the following command:
sudo systemctl restart nfs-server.service
You can also give the -r parameter to the exportfs command so that it re-shares directories that have changed any settings related to the share:
sudo exportfs -r
Fixing the Mount Latency Problem
When you use NFS protocol version 4 and higher on your server, there may be delays of up to 15 seconds during the client-side mount process in traditional operating scenarios with the default configurations of the NFS server. This issue may appear on some versions of Debian, Fedora, and Ubuntu.
If you are experiencing a similar mount lag, you can check the server-side log files (/var/log/syslog, /var/log/messages) for a log message similar to the following:
RPC: AUTH_GSS upcall timed out
This message indicates that Kerberos authentication failed and timed out. You probably won’t need the Kerberos protocol for security authentication on the network in your environment. Even if you are on a network configured this way, at least with your embedded Linux systems, you won’t need to enable Kerberos authentication.
Although alternatives to running the GSSD service with NFS to fix the problem have been offered, these approaches do not have the same impact in all distributions and package versions, and therefore, it is most rational to tackle this problem from the root.
You must block (or blacklist) the rpcsec_gss_krb5 kernel module from loading on the Linux system where the NFS server is executing.
To have this option take effect every time you restart your computer, create a new file called /etc/modprobe.d/nfs-gss-blacklist.conf and add the following lines to it:
Once you save the file and reboot the system, the mount latency problem will go away.
Why Use an NFS Server?
NFS is simple and affordable to set up. It allows for centralized management, which reduces the requirement for extra software and storage space on an individual user’s PC. On a single machine, multiple users can share the same disk space. They can put these disks on top of their file system to extend the storage space.
NFS sharing allows programs that require a lot of storage space to be grouped on a single server. This can result in huge disk space savings. While previous NFS versions are vulnerable, newer versions have introduced additional levels of protection, including Kerberos authentication.
However, there are some disadvantages as well. NFS has been found to slow down in some cases during heavy network traffic. Sharing with Windows is possible, but may require some third-party applications. But this is not a very sensible practice in terms of security. If the configuration is not correct, unauthorized access may occur.
File System Sharing Made Easy on Linux Using NFS
Knowing security problems and finding solutions is one of the most critical tasks of a system administrator. It is necessary to know the security procedures for all file sharing systems and management tools and not just NFS.