The autofs daemon can be used to mount remote file systems automatically. Add the following entry in the your /etc/auto.master file:

/nfsmounts /etc/auto.nfs

Now the /nfsmounts directory acts as the root for all the NFS mounts on the client if the auto.nfs file is filled appropriately. The name auto.nfs is chosen for the sake of convenience—you can choose any name. In auto.nfs add entries for all the NFS mounts as follows:

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

Activate the settings with rcautofs start as root. In this example, /nfsmounts/localdata, the /data directory of server1, is mounted with NFS and /nfsmounts/nfs4mount from server2 is mounted with NFSv4.

If the /etc/auto.master file is edited while the service autofs is running, the automounter must be restarted for the changes to take effect with rcautofs restart.

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

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

NFSv4 mounts may also be added to the /etc/fstab file. For these mounts, use nfs4 instead of nfs in the third column and make sure that the remote file system is given as / after the nfs.example.com: in the first column. A sample line for an NFSv4 mount in /etc/fstab looks like this:

nfs.example.com:/ /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:

mount /local/path

Note, that if you do not enter the noauto option, the initialization scripts of the system will handle the mount of those file systems at start up.

Activate Enable NFSv4 to support NFSv4 clients. Clients with NFSv3 can still access the server's exported directories if they are exported appropriately. This is explained in detail in Section 28.4.3, “Coexisting v3 and v4 Exports”.

After activating NFSv4, enter an appropriate domain name. Make sure the name is the same as the one in the /etc/idmapd.conf file of any NFSv4 client that accesses this particular server. This parameter is for the idmapd service that is required for NFSv4 support (on both server and client). Leave it as localdomain (the default) if you do not have special requirements. For more information, see the links in Section 28.7, “For More Information”.

Click Next. The dialog that follows has two sections. The upper half consists of two columns named Directories and Bind Mount Targets . Directories is a directly editable column that lists the directories to export.

For a fixed set of clients, there are two types of directories that can be exported—directories that act as pseudo root file systems and those that are bound to some subdirectory of the pseudo file system. This pseudo file system acts as a base point under which all file systems exported for the same client set take their place. For a client or set of clients, only one directory on the server can be configured as pseudo root for export. For this client, export multiple directories by binding them to some existing subdirectory in the pseudo root.

Figure 28.4. Exporting Directories with NFSv4

In the lower half of the dialog, enter the client (wild card) and export options for a particular directory. After adding a directory in the upper half, another dialog for entering the client and option information pops up automatically. After that, to add a new client (client set), click Add Host.

In the small dialog that opens, enter the host wild card. There are four possible types of host wild cards that can be set for each host: a single host (name or IP address), netgroups, wild cards (such as * indicating all machines can access the server), and IP networks. Then, in Options, include fsid=0 in the comma-separated list of options to configure the directory as pseudo root. If this directory needs to be bound to another directory under an already configured pseudo root, make sure that a target bind path is given in the option list with bind=/target/path.

For example, suppose that the directory /exports is chosen as the pseudo root directory for all the clients that can access the server. Then add this in the upper half and make sure that the options entered for this directory include fsid=0. If there is another directory, /data, that also needs to be NFSv4 exported, add this directory to the upper half. While entering options for this, make sure that bind=/exports/data is in the list and that /exports/data is an already existing subdirectory of /exports. Any change in the option bind=/target/path, whether addition, deletion, or change in value, is reflected in Bindmount Targets. This column is not a directly editable column, but instead summarizes directories and their nature. After all information is provided, click Finish to complete the configuration. The service will become available immediately.

Make sure that Enable NFSv4 is not checked in the initial dialog before clicking Next.

The next dialog has two parts. In the upper text field, enter the directories to export. Below, enter the hosts that should have access to them. There are four types of host wild cards that can be set for each host: a single host (name or IP address), netgroups, wild cards (such as * indicating all machines can access the server), and IP networks.

This dialog is shown in Figure 28.5, “Exporting Directories with NFSv2 and v3”. Find a more thorough explanation of these options in man exports. Click Finish to complete the configuration.

Figure 28.5. Exporting Directories with NFSv2 and v3¶

Both, NFSv3 and NFSv4 exports can coexist on a server. After enabling the support for NFSv4 in the initial configuration dialog, those exports for which fsid=0 and bind=/target/path are not included in the option list are considered v3 exports. Consider the example in Figure 28.3, “Configuring an NFS Server with YaST”. If you add another directory, such as /data2, using Add Directory then in the corresponding options list do not mention either fsid=0 or bind=/target/path, this export acts as a v3 export.

Automatic Firewall Configuration If SuSEfirewall2 is active on your system, YaST adapts its configuration for the NFS server by enabling the nfs service when Open Ports in Firewall is selected.

NFSv4 is the latest version of NFS protocol available on openSUSE. Configuring directories for export with NFSv4 differs slightly from previous NFS versions.

/shared/directory   host(option_list)

/export   192.168.1.2(rw,fsid=0,sync,crossmnt)
/export/data   192.168.1.2(rw,bind=/data,sync)

[General] 

Verbosity = 0 
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = localdomain

[Mapping]

Nobody-User = nobody
Nobody-Group = nobody

This section is specific to NFSv3 and NFSv2 exports. Refer to Section 28.4.1, “Exporting for NFSv4 Clients” for exporting with NFSv4.

Exporting file systems with NFS involves two configuration files: /etc/exports and /etc/sysconfig/nfs. A typical /etc/exports file entry is in the format:

/shared/directory   host(list_of_options)

For example:

/export   192.168.1.2(rw,sync)

Here, the directory /export is shared with the host 192.168.1.2 with the option list rw,sync. This IP address can be replaced with a client name or set of clients using a wild card (such as *.abc.com) or even netgroups.

For a detailed explanation of all options and their meaning, refer to the man page of exports (man exports).

After changing /etc/exports or /etc/sysconfig/nfs, start or restart the NFS server using the command rcnfsserver restart.