The Network File System (NFS) is a distributed file system protocol that allows users to access files over a network as if they were on a local disk. Developed by Sun Microsystems in 1984, NFS provides a way to share directories and files with others over a network. NFS is widely used in UNIX and Linux environments but is also supported by other operating systems such as Windows.

This post describes the basic server configuration to be able to mount an NFS export easily. Additionally, due to the limited authorization options of NFS (w/o Kerberos), it gives some hints how to improve the security and accessibility of an NFS server via its configuration options.

Nfs General Structure — NFS basic structure

Table of contents

1. Introduction

1.1 NFS server/client structure

The NFS architecture is based on a server/client model, where the NFS server hosts the file systems and makes them available to NFS clients. The actual version of NFS is NFS v4 (RFC 7530).
DietPi supports NFS

as a software option of an NFS server and an NFS client being installed via dietpi-software
by configuring the NFS client via dietpi-drive_manager

Generally, the server is configured via a configuration file (/etc/exports), the client is configured via dietpi-drive_manager.

Nfs Multiclient Structure 1 — NFS multiclient structure example

1.2 NFS Server

The NFS server is responsible for sharing its directories and files with clients over the network. The server controls access to its file systems, manages permissions, and handles client requests for data.

Key components of an NFS server include:

Exported Directories: Directories that are made available to clients.
Access Control: Permissions set to control which clients can access which directories.
NFS Daemons: Background processes that manage file system requests from clients (e.g., nfs-server.service).

1.3 NFS Client

The NFS client is the part that accesses the shared directories from the NFS server. The client mounts the remote file systems locally, allowing users to interact with them as if they were on their local machines.

Key tasks for an NFS client include:

Mounting Remote Directories: Commands like dietpi-drive_manager (or a Linuxmount) are used to connect to the NFS server and access shared directories.
Interacting with Mounted File Systems: Performing file operations (e.g., read, write, delete) on the mounted directories.

2. Installation

Grafik — Installation option via `dietpi-software`

2.1 Server installation

The installation of the NFS server is done via dietpi-software, either via navigating through the menus or via installing it directly from the command line:

dietpi-software install 109

This installs the NFS server (Debian package nfs-kernel-server), generates a sample NFS exports configuration file /etc/exports.d/dietpi.exports and starts the server.
The default exports file contains an export of /mnt/dietpi_userdata without any client restrictions:

root@NFS-server:~# cat /etc/exports.d/dietpi.exports 
/mnt/dietpi_userdata *(rw,async,no_root_squash,crossmnt,no_subtree_check)

(Remark: Until DietPi v9.8 the exports file had the option fsid=0. This led to a problem with the dietpi-drive_manager mounting procedure: Only NFS v3 then was used (see below). Using fsid=0 with NFS v4 could only be achieved by manually editing the /etc/fstab file.)

The correct start of the server can be checked via

systemctl status nfs-server

root@NFS-server:~# systemctl status nfs-server         
● nfs-server.service - NFS server and services
     Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; preset: enabled)
    Drop-In: /run/systemd/generator/nfs-server.service.d
             └─order-with-mounts.conf
     Active: active (exited) since Fri 2024-09-13 02:51:45 BST; 10min ago
    Process: 473 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS)
    Process: 475 ExecStart=/usr/sbin/rpc.nfsd (code=exited, status=0/SUCCESS)
   Main PID: 475 (code=exited, status=0/SUCCESS)
        CPU: 4ms

Sep 13 02:51:45 NFS-server systemd[1]: Starting nfs-server.service - NFS server and services...
Sep 13 02:51:45 NFS-server systemd[1]: Finished nfs-server.service - NFS server and services.

The part Active: active shows that the server is up and running.

2.2 Client installation

Generally, an explicit NFS client installation by the user is not necessary, because it is automatically installed if NFS shares are mounted via dietpi-drive_manager.

A manual installation of the NFS client is done via dietpi-software, either via navigating through the menus or via installing it directly from the command line:

dietpi-software install 110

This installs the NFS client (Debian package nfs-common) without any further NFS mount actions.

The correct installation of the client can be checked via

systemctl status nfs-client.target

root@NFS-client:~# systemctl status nfs-client.target
● nfs-client.target - NFS client services
Loaded: loaded (/lib/systemd/system/nfs-client.target; enabled; preset: enabled)
Active: active since Fri 2024-10-25 16:42:11 BST; 20min ago

Oct 25 16:42:11 NFS-client systemd[1]: Reached target nfs-client.target - NFS client services.

3. Basic Server configuration

3.1 Editing exports file(s)

The NFS server is configured by configuration files located in /etc/exports.d/ and the file /etc/exports itself.
These files defines which directories are shared and the permissions for each client or group of clients.

3.1.1 Prerequisites

As a first step, some questions shall be cleared to find the correct export base lines. It is a good practice to first check the correct accessibility using less resp. simple export options. These can later be changed to improve security and accessiblility (see next chapter).

The questions to be cleared are the following:

Shall the default exported directory (/mnt/dietpi_userdata/) kept as an exported directory?
Which directories shall be shared?
For every directory the following additional questions have to be cleared.
Shall the directory exported read/only or read-write?
Is it a subdirectory of any other directory to be exported?

Q1: If `/mnt/dietpi_userdata/` shall not be kept as exported:

comment this line in the file /etc/exports.d/dietpi.exports via # ,or
delete the line, or
delete the complete dietpi.exports file.

Q2: For every directory to be exported:

add a line to an exports file (e.g. /etc/exports.d/dietpi.exports or an extra file within /etc/exports.d/ with

/path/to/directory *(rw,async,no_root_squash,crossmnt,no_subtree_check)

Remark: Ensure that there is be no blank between the * and the (.

Example:

mnt/dietpi_userdata       *(rw,no_subtree_check)
mnt/dietpi_userdata/Music *(ro,no_subtree_check)
mnt/dietpi_userdata/Video *(ro,no_subtree_check)

Remark: If fsid=0 is used in the exports file (former DietPi versions), it means that the <path_to_directory> is the directory point which shall be the root of exported directories: If several directories with at least one subordinated directory shall be exported, e.g. with different options, the uppermost directory is given the fsid=0 (equal to fsid=root) attribute.
Additionally, the mount command on the client has to direct to / instead of /mnt/dietpi_userdata in the /etc/fstab file.

3.1.2 General exports structure

Each line in the export file specifies a directory to be shared and the associated access control rules. The general syntax is:

/path/to/directory client(options)

/path/to/directory: The directory to be shared. It must start from root, i.e. with a leading /.
client: Specifies the client or network allowed to access the directory.
options: Defines the permissions and behaviors for the client.

Remark: Ensure that there is be no blank between client and the ( of the options.
I.e. (client(options) instead of client (options).

Client and options can occur several times in a line to define different options for different clients for one identical shared directory:

/path/to/directory client_1(options_1) client_2(options_2)

The client value can be e.g.

* -> export shall be accessible for every client (anonymous)
<ip-address> or a hostname -> export shall be accessible for one machine via an ip address or a hostname. The ip address or the hostname might have wildcards like ? and * (e.g. 192.168.1.*, client_?).
<ip-address range> like 192.168.1.0/24

3.1.3 Applying changes

After modifying the /etc/exports file or export files below /etc/exports.d, the changes need to be applied by running the following command:

exportfs -ra

This command exports all directories listed in the exports files and applies the specified access rules.

Verification of the exports can be executed with:

exportfs -v

This command lists the current exports and their options, allowing administrators to confirm that the configuration is correct.

3.2 Example export file entries

Initial DietPi installation

On a fresh DietPi system with the NFS server installed there are two export files: /etc/exports and /etc/exports.d/dietpi.exports.

Contents of /etc/exports

# /etc/exports: the access control list for filesystems which may be exported
#		to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
#

To export further directories, a good practice is to edit the dietpi.exports file or to generate own export files in the /etc/exports.d/ directory.

Example entries in /etc/exports

Basic Export to a Single Client:

/mnt/dietpi_userdata/Music 192.168.1.10(rw,sync,no_subtree_check)

This line shares the directory /mnt/dietpi_userdata/Music with the client at IP address 192.168.1.10. The options specified are:

rw: Read and write access.dietpi-drive_manager
sync: Write operations are committed to disk before the request is completed.
no_subtree_check: Disables subtree checking for improved performance.

Export to Multiple Clients:

/mnt/dietpi_userdata/Video 192.168.1.11(rw,sync,no_subtree_check) 192.168.1.12(ro,sync,no_subtree_check)

This line shares the directory /mnt/dietpi_userdata/Video with two clients:

192.168.1.11 has read and write access.
192.168.1.12 has read-only access.

Export to a Subnet:

/mnt/dietpi_userdata/Pictures192.168.1.0/24(rw,sync,no_subtree_check)

This line shares the directory /mnt/dietpi_userdata/Pictureswith all clients in the 192.168.1.0/24 subnet, providing read and write access.

3.3 Set/check directory/file permissions of directories to be exported

Every exported directory/file which shall be accessible need appropriate permissions. This might be achieved by setting the permissions for the whole exported directory structure (recursively via -R option).

chmod -R g+rwx /path/to/directory

Remark: To be fool proof for a first test, chmod -R ugo+rwx /path/to/directory (equal to chmod -R 777 /path/to/directory) might be used.

Possibly, also the user or group settings of the files need to be set (e.g. via chown -R dietpi:dietpi /path/to/directory). Optionally, a new group can be added to the system to distinguish access permissions resp. file permissions on a user/group basis.

3.4 Check file system type of directories to be exported

Basically, NFS is recommended only be used to export Linux file system types. We do not recommend to e.g. export a NTFS share. There, often file attribute and file permission problems occur.

4. Client configuration

Basically, the client mounts are handled via entries in the /etc/fstab file.
This can be done manually, but DietPi offers a more comfortable option using the dietpi-drive_manager which makes life easier: It handles all the editing of /etc/fstab “under the hood” on a dialog wizard base:

The dietpi-drive_manager guides the user through the needed information entries to add a NFS mount. Just select “Add network drive”:

After entering the NFS servers IP address resp. hostname, the exported shares are shown and can be selected:

After this, the location where the share shall occur is entered (the “mount point”). We recommend to use a share below /mnt:

When the mount procedure was successful, the last dialog shows some status information:

And the main dialog shows the mounted share also:

5. Improving security and accessibility of the server

Securing an NFS server is crucial to protect sensitive data and ensure that only authorized clients can access shared resources. The /etc/exports file not only specifies which directories are shared but also allows administrators to set options that enhance security. Below are various options that can be configured in /etc/exports to achieve higher security.

5.1 Key security options

5.1.1 Read-only access

Option:ro
Description: Restricts clients to read-only access, preventing any modifications to the shared directory.
Example:
/mnt/dietpi_userdata 192.168.1.10(ro,sync,no_subtree_check)

5.1.2 Root squashing

Option:root_squash
Description: Maps requests from the root user on the client to an anonymous user (nfsnobody). This prevents a root user on the client machine from having root privileges on the NFS server.
Example:
/mnt/dietpi_userdata 192.168.1.10(ro,root_squash,sync,no_subtree_check)

5.1.3 All user squashing

Option:all_squash
Description: Maps all user and group IDs to the anonymous user (nfsnobody), which can be useful in a public or multi-user environment.
Example:
/mnt/dietpi_userdata 192.168.1.10(ro,all_squash,sync,no_subtree_check)

5.1.4 No root squashing

Option:no_root_squash
Description: Allows root users on the client machine to have root privileges on the NFS server. This option should be used with caution and only when necessary, as it can pose a security risk.
Example:
/mnt/dietpi_userdata 192.168.1.10(ro,no_root_squash,sync,no_subtree_check)

5.1.5 Secure ports

Option:secure
Description: Ensures that the client uses a secure port (below 1024) to communicate with the NFS server. This can help in preventing unauthorized access.
Example:
/mnt/dietpi_userdata 192.168.1.10(ro,root_squash,sync,no_subtree_check,secure)

5.1.6 Sync

Option:sync
Description: Forces the NFS server to write changes to disk before replying to the client, ensuring data integrity. This is more secure but may reduce performance compared to async.
Example:
/mnt/dietpi_userdata 192.168.1.10(ro,root_squash,sync,no_subtree_check)

5.1.7 No subtree check

Option:no_subtree_check
Description: Disables subtree checking, which can improve performance and avoid issues with certain directory structures. While not directly a security feature, it is often used to avoid certain vulnerabilities.
Example:
/mnt/dietpi_userdata 192.168.1.10(ro,root_squash,sync,no_subtree_check)

5.1.8 IP-based access control

Description: Restricts access to specific IP addresses or subnets, ensuring that only authorized clients can mount the shared directories.
Example:
/mnt/dietpi_userdata 192.168.1.10(ro,root_squash,sync,no_subtree_check)
/mnt/dietpi_userdata 192.168.1.0/24(ro,root_squash,sync,no_subtree_check)

5.2 Combining options for enhanced security

To achieve a higher level of security, administrators can combine multiple options. Here is an example configuration that applies several security measures:

/mnt/dietpi_userdata192.168.1.10(ro,root_squash,sync,no_subtree_check,secure)

In this example:

ro: Ensures the directory is read-only.
root_squash: Maps root user requests to the anonymous user.
sync: Writes changes to disk before replying, ensuring data integrity.
no_subtree_check: Improves performance and avoids potential issues.
secure: Ensures communication from secure ports.

The sections above also give an overview, which other options can be combined.

5.3 NFS v3 vs. NFS v4: What to activate?

5.3.1 General

NFS v4 is the actual NFS version which gives somehow better security compared to NFS v3 (e.g. see there or there).
Nowadays, typically only NFS v4 is used and NFS v3 is only needed in case of older clients. Therefore, disabling NFS v3 can be an option to enhance security in your network.

To find out which NFS versions the server is running, the file /proc/fs/nfsd/versions is available and can be viewed via

cat /proc/fs/nfsd/versions

In an example with NFS v3 and NFS v4 activated, it shows

root@NFS-server:~# cat /proc/fs/nfsd/versions
+3 +4 +4.1 +4.2

5.3.2 Possible drawbacks when disabling NFS v3

Disabling NFS v3 can have potential drawbacks, depending on the environment and specific use cases. Here are some of the main disadvantages:

Compatibility Issues with Older Systems
Many legacy systems and older network-attached storage (NAS) devices only support NFS v3. Disabling NFS v3 will prevent these systems from accessing shared resources, as they may not support NFS v4 or later versions.
Performance Concerns in Certain Environments
NFS v3 is often faster in certain environments, especially where low latency is critical or where network reliability is inconsistent. NFS v3 can perform better in high-latency networks since it has a simpler, stateless design. Also, NFS v3 supports asynchronous writes, which can enhance performance under specific workloads. Disabling it could lead to performance degradation in some use cases.
Loss of Stateless Connection Simplicity
NFS v3 operates as a stateless protocol, meaning it doesn’t keep track of active connections between client and server, which simplifies management in unreliable or transient network conditions. NFSv4, however, is stateful, requiring ongoing session tracking that can be more complicated to manage and troubleshoot if there are network issues.

5.3.3 Disable/enable NFS v3

One option to disable NFS v3 is to add a file to the directory /etc/nfs.conf.d/ within the section [nfsd](see also there).

cat << _EOF_ > "/etc/nfs.conf.d/00-dietpi.conf"
# Disable NFS v3 (to only have NFS v4 enabled)
#
[nfsd]
vers3=n
#vers4=y
#vers4.1=y
#vers4.2=y
_EOF_

A restart of the NFS service is then necessary:

systemctl restart nfs-server.service

The disabled NFS v3 can be examined like above:

root@NFS-server:/etc/nfs.conf.d# cat /proc/fs/nfsd/versions
-3 +4 +4.1 +4.2

The output gives that NFS v3 is not active (-3) whereas NFS v4 is active (+4 +4.1 +4.2).

To re-enable NFS v3 again, the entry vers3=y can be used, or the complete file /etc/nfs.conf.d/00-dietpi.conf can be deleted (also restarting the nfs-server service afterwards).

An alternative to /etc/nfs.conf resp. /etc/nfs.conf.d/ is to use the file/etc/default/nfs-kernel-server (e.g. see there) and use these entries:

RPCNFSDOPTS="-N 2 -N 3"
RPCMOUNTDOPTS="--manage-gids -N 2 -N 3"

6. Diagnosis of NFS mount problems

6.1 Diagnosis within the shell

6.1.1 List exported shares

On the server side, the accessible exported mounts can be shown via exportfs

root@NFS-server:~# exportfs
/mnt/dietpi_userdata
		<world>

In the example, the local NFS server exports /mnt/dietpi_userdata to every NFS client (<world>).

On the client side, the accessible exported mounts can be shown via showmount

root@NFS-client:~# showmount -e 192.168.8.112
Export list for 192.168.8.112:
/mnt/dietpi_userdata *

In the example, IP address 192.168.8.112 is the NFS server exporting its directory /mnt/dietpi_userdata to every NFS client.

6.1.2 List NFS version of mount connection

To examine the NFS version (e.g. NFS v3, v4.1, v4.2) of a mounted directory, the command

nfsstat -m

can be used. The output value vers=... gives the NFS version of the mount connection.
An example output looks like the following:

root@NFS-client:~# nfsstat -m
/mnt/nfs_client from NFS-server:/
Flags: rw,relatime,vers=4.2,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.8.113,local_lock=none,addr=192.168.8.112

The output vers=4.2 denotes that NFS v4.2 is active.

6.2 Diagnosis with DietPi-Drive_Manager

The dietpi-drive_managercan give an overview about mounted shares:

In the example, there is a mounted directory /mnt/dietpi_userdata from the NFS server with IP address 192.168.8.112 mounted on the local path /mnt/nfs_client.
This corresponds to a line within /etc/fstab:

192.168.8.112:/mnt/dietpi_userdata /mnt/nfs_client nfs noauto,x-systemd.automount

6.3 Diagnosis with Webmin

Webmin (DietPi software package #) is a webserver based frontend for managing your system.

Webmin NFS server dialogs

It is not recommended to use the Webmin NFS exports dialog within Webmin, because it only handles one exports file (default: /etc/exports).

Webmin NFS client dialogs

7. References

DietPi and NFS: Basics and improving security

X Facebook Reddit