19 Sharing file systems with NFS #

With YaST, turn a host in your network into an NFS server—a server that exports directories and files to all hosts granted access to it or to all members of a group. Thus, the server can also provide applications without installing the applications locally on every host.

To set up such a server, proceed as follows:

The configuration files for the NFS export service are /etc/exports and /etc/sysconfig/nfs. In addition to these files, /etc/idmapd.conf is needed for the NFSv4 server configuration with kerberized NFS or if the clients cannot work with numeric user names.

To start or restart the services, run the command systemctl restart nfs-server. This also restarts the RPC port mapper that is required by the NFS server.

To make sure the NFS server always starts at boot time, run sudo systemctl enable nfs-server.

Note: NFSv4

NFSv4 is the latest version of the NFS protocol available on SUSE Linux Enterprise Server. Configuring directories for export with NFSv4 is now the same as with NFSv3.

On SUSE Linux Enterprise Server 11, the bind mount in /etc/exports was mandatory. It is still supported, but now deprecated.

To use Kerberos authentication for NFS, Generic Security Services (GSS) must be enabled. Select Enable GSS Security in the initial YaST NFS Server dialog. You must have a working Kerberos server to use this feature. YaST does not set up the server but only uses the provided functionality. To use Kerberos authentication in addition to the YaST configuration, complete at least the following steps before running the NFS configuration:

Kerberos authentication also requires the idmapd daemon to run on the server. For more information, refer to /etc/idmapd.conf.

For more information about configuring kerberized NFS, refer to the links in Section 19.7, “More information”.

Authorized users can mount NFS directories from an NFS server into the local file tree using the YaST NFS client module. Proceed as follows:

The configuration is written to /etc/fstab and the specified file systems are mounted. When you start the YaST configuration client at a later time, it also reads the existing configuration from this file.

Tip: NFS as a root file system

On (diskless) systems where the root partition is mounted via network as an NFS share, you need to be careful when configuring the network device with which the NFS share is accessible.

When shutting down or rebooting the system, the default processing order is to turn off network connections then unmount the root partition. With NFS root, this order causes problems as the root partition cannot be cleanly unmounted as the network connection to the NFS share is already deactivated. To prevent the system from deactivating the relevant network device, open the network device configuration tab as described in Section 23.4.1.2.5, “Activating the network device” and choose On NFSroot in the Device Activation pane.

The prerequisite for importing file systems manually from an NFS server is a running RPC port mapper. The nfs service takes care to start it properly; thus, start it by entering systemctl start nfs as root. Then remote file systems can be mounted in the file system just like local partitions, using the mount:

> sudo mount HOST:REMOTE-PATH LOCAL-PATH

To import user directories from the nfs.example.com machine, for example, use:

> sudo mount nfs.example.com:/home /home

To define a count of TCP connections that the clients make to the NFS server, you can use the nconnect option of the mount command. You can specify any number between 1 and 16, where 1 is the default value if the mount option has not been specified.

The nconnect setting is applied only during the first mount process to the particular NFS server. If the same client executes the mount command to the same NFS server, all already established connections will be shared—no new connection will be established. To change the nconnect setting, you have to unmount all client connections to the particular NFS server. Then you can define a new value for the nconnect option.

You can find the value of nconnect that is in currently in effect in the output of the mount, or in the file /proc/mounts. If there is no value for the mount option, then the option has not been used during mounting and the default value of 1 is in use.

Note: Different number of connections than defined by nconnect

As you can close and open connections after the first mount, the actual count of connections does not necessarily have to be the same as the value of nconnect.

/nfsmounts /etc/auto.nfs

localdata -fstype=nfs server1:/data
nfs4mount -fstype=nfs4 server2:/

19.4.2.2 Manually editing /etc/fstab #

 

A typical NFSv3 mount entry in /etc/fstab looks like this:

nfs.example.com:/data /local/path nfs rw,noauto 0 0

For NFSv4 mounts, use nfs4 instead of nfs in the third column:

nfs.example.com:/data /local/pathv4 nfs4 rw,noauto 0 0

The noauto option prevents the file system from being mounted automatically at start-up. If you want to mount the respective file system manually, it is possible to shorten the mount command specifying the mount point only:

> sudo mount /local/path

Note: Mounting at start-up

If you do not enter the noauto option, the init scripts of the system will handle the mount of those file systems at start-up. In that case, you may consider adding the option _netdev, which prevents scripts from trying to mount the share before the network is available.

NFS is one of the oldest protocols, developed in the 1980s. As such, NFS is usually sufficient if you want to share small files. However, when you want to transfer big files or many clients want to access data, an NFS server becomes a bottleneck and has a significant impact on the system performance. This is because files are quickly getting bigger, whereas the relative speed of Ethernet has not fully kept pace.

When you request a file from a regular NFS server, the server looks up the file metadata, collects all the data, and transfers it over the network to your client. However, the performance bottleneck becomes apparent no matter how small or big the files are:

pNFS, or parallel NFS, overcomes this limitation as it separates the file system metadata from the location of the data. As such, pNFS requires two types of servers:

The metadata and the storage servers form a single, logical NFS server. When a client wants to read or write, the metadata server tells the NFSv4 client which storage server to use to access the file chunks. The client can access the data directly on the server.

SUSE Linux Enterprise Server supports pNFS on the client side only.

> sudo mount -t nfs4 -o nfsvers=4.2 MDS_SERVER MOUNTPOINT

> sudo echo 32767 > /proc/sys/sunrpc/nfsd_debug
> sudo echo 32767 > /proc/sys/sunrpc/nfs_debug

NFS 4 requires TCP port 2049 to be open on the server side only. To open this port on the firewall, enable the nfs service in firewalld on the NFS server:

> sudo firewall-cmd --permanent --add-service=nfs --zone=ACTIVE_ZONE
firewall-cmd --reload

Replace ACTIVE_ZONE with the firewall zone used on the NFS server.

No additional firewall configuration on the client side is needed when using NFSv4. By default mount defaults to the highest supported NFS version, so if your client supports NFSv4, shares will automatically be mounted as version 4.2.

NFS 3 requires the following services:

These services are operated by rpcbind, which, by default, dynamically assigns ports. To allow access to these services behind a firewall, they need to be configured to run on a static port first. These ports need to be opened in the firewall(s) afterwards.

Important: Loading a changed firewalld configuration

Whenever you change the firewalld configuration, you need to reload the daemon to activate the changes:

> sudo firewall-cmd --reload

Note: Firewall zone

Make sure to replace ACTIVE_ZONE with the firewall zone used on the respective machine. Note that, depending on the firewall configuration, the active zone can differ from machine to machine.

In some cases, you can understand the problem in your NFS by reading the error messages produced and looking into the /var/log/messages file. However, in many cases, the information provided by the error messages and in /var/log/messages is not detailed enough. In these cases, most NFS problems can be best understood through capturing network packets while reproducing the problem.

Clearly define the problem. Examine the problem by testing the system in a variety of ways and determining when the problem occurs. Isolate the simplest steps that lead to the problem. Then try to reproduce the problem as described in the procedure below.

Important: Advanced debugging is for experts

Please bear in mind that the following section is intended only for skilled NFS administrators who understand the NFS code. Therefore, perform the first steps described in Section 19.8.1, “Common troubleshooting” to help narrow down the problem and to inform an expert about which areas of debug code (if any) might be needed to learn deeper details.

There are various areas of debug code that can be enabled to gather additional NFS-related information. However, the debug messages are quite cryptic and the volume of them can be so large that the use of debug code can affect system performance. It may even impact the system enough to prevent the problem from occurring. In the majority of cases, the debug code output is not needed, nor is it typically useful to anyone who is not highly familiar with the NFS code.

rpcdebug -m module -s flags

rpcdebug -m module -c flags

man 8 rpcdebug

MOUNTD_OPTIONS=""

MOUNTD_OPTIONS="-d all"

man 8 rpc.mountd

systemctl restart nfs-server  # for nfs server related changes
systemctl restart nfs  # for nfs client related changes