Linux Home Server HOWTO

Home

Chapter 19 - Network File System

Version:

- nfs-utils-1.0.8

Setting the Exports
Starting and Testing
Selecting the Server Version
Imports and Mounting
NFS Version 4

The Network File System (NFS) was originally developed by SUN Microsystems as a protocol that allowed communications between different computing environments. The NFS enables a UNIX workstation to mount an exported share from the server into its own filesystem, thus giving the user and the client the appearance that the sub filesystem belongs to the client; it provides a seamless network mount point.

The NFS protocol has been around for a few years now and has undergone many advancements and revisions. The initial NFS server implementations only supported UDP packets, while the later versions support stateful TCP connections; there are pros and cons for using both protocols. NFS support has been compiled into the Linux kernel now for a while, with NFS versions 2, 3 (RFC 1813) and 4 (RFC 3530) being supported by the 2.6 kernel for both UDP and TCP protocols.

This chapter will describe how to prepare and export shares for users and workstations from the Linux server, it will also cover the steps needed for the Linux client to view and mount those exports into its own filesystem. NFS Versions 2 and 3 are similar in implementation, while Version 4 is slightly different and detailed further in its own section.

The following list of man pages can provide further information to assist with configuration or debugging requirements.

Man Pages:
nfs	mount
fstab	mountd
exports	rpcinfo
exportfs	rpc.nfsd
portmap	rpc.mountd

Setting the Exports

When a user and client workstation connect to an NFS server, the server firstly checks to ensure that a connection can be established from the workstation. If the connection is allowed, then the user that is logged onto the workstation is then authenticated against their account located on the server to determine if they are an authorised user. If both checks confirm valid access, then they will be granted their normal permissions which also include any restrictions placed on the exported share. The users UID and GID must match between the client and the server.

The "/etc/exports" file contains the configuration settings for the servers exports, it may need to be created if it does not already exist. The following example displays a listing of the exported filesystems and the access restrictions that apply to each export.

[bash]# vi /etc/exports
1. 2. 3. 4. 5.	/home linuxwkstn(rw,sync) /tmp/fileswap (rw,no_root_squash,async) /filestore 192.168.1.0/24(rw,no_root_squash,sync) /var/ftp 192.168.1.0/24(ro,all_squash,async) /home/alice admin(rw,all_squash,sync,anonuid=567,anongid=567)

The following details examine each of the entries which have been specified in the above exports file.

1.   The "/home" directory is accessible from ALL workstations whose hostnames start with "linuxwkstn". The export has read / write permissions and the data transfer is synchronous in nature.

2.   The "/tmp/fileswap" directory is accessible from ALL workstations (regardless of name). The export has read / write permissions and data transfer is asynchronous. The root account on the local workstation will have root permission on the remote servers filesystem through the export.

3.   The "/filestore" directory is accessible to all hosts in the 192.168.1.0/24 subnet. The export has read / write permissions and data transfer is synchronous. The root account on the local workstation will have root permission on the remote servers filesystem through the export.

4.   The "/var/ftp" directory is accessible to all hosts in the 192.168.1.0/24 subnet. The export is read only, and all connecting users will be forced to connect as the "nobody" account (squashed). Data transfers are asynchronous.

5.   Alice's home directory "/home/alice" is only accessible from the "admin" host workstation. The export has read / write permissions and data transfers are synchronous. All connecting users will be forced to connect as the UID and GID 567. This assumes the account in Alice's name on the server is UID/GID 567.

The following are some of the basic exporting options, type "man exports" to see more information.

Options:	Description:
rw	Allows read and write access to the share
ro	Only allows read access, writing is blocked
all_squash	Forces all connecting users to "nobody" account and permissions
no_root_squash	Allows root account on client to access export share on server as the root account
anonuid	Forces all anonymous connections to predefined UID on server
anongid	Forces all anonymous connections to predefined GID on server

After the exports have been defined, the changes need to be passed through to the NFS mounting daemon (mountd) which stores a list of available exports in the /var/lib/nfs/etab (or xtab) file. Any adjustments are added or removed to synchronise the files.

[bash]# exportfs -rv
1. 2. 3. 4. 5.	exporting linuxwkstn:/home exporting :/tmp/fileswap exporting 192.168.1.0/24:/filestore exporting 192.168.1.0/24:/var/ftp exporting admin.example.com:/home/alice

Both the nfs and portmap services need to be restarted for new exports to be available to the client.

Starting and Testing

The nfs and portmap services should be set and checked for the appropriate runlevels. The portmap service should already be running on most standard Linux installations, but its save to check.

[bash]# chkconfig --level 345 nfs on
[bash]# chkconfig --level 345 portmap on

[bash]# chkconfig --list nfs
[bash]# chkconfig --list portmap

Although the export settings can be pushed through to the mounting daemon using the exportfs command, the nfs and portmap initscripts handle other important functions, so the services should both be restarted before trying to use the exported filesystem.

[bash]# /etc/init.d/nfs restart
[bash]# /etc/init.d/portmap restart

The available list of exports can be seen using the "showmount -e" command (for local or remote use).

[bash]# showmount -e galaxy
1. 2. 3. 4. 5.	Export list for galaxy: /home linuxwkstn* /tmp/fileswap * /filestore 192.168.1.0/24 /var/ftp 192.168.1.0/24 /home/alice admin.example.com

The system logs should also be checked for any initialisation errors or events. The system log will normally contain any mounting or disconnecting calls and should be checked regularly to debug any NFS connections errors.

[bash]# tail -n 50 /var/log/messages

Setting the Server Versions

In the chapter's opening, I mentioned that the Linux kernel has built-in support for NFS versions 2, 3 and 4. The rpcinfo command can be used to query the server which will return a listing of RPC details, most important are the nfs and mountd entries.

The following query of the "galaxy" server tells us that it is running NFS versions 2, 3 and 4 and connections are available using either the UDP and TCP protocols, it also identifies the server is accepting connections on port 2049; the default for NFS.

The lower part of the query tells us that mountd is accepting connections for versions 1, 2, and 3 of the NFS protocol, NFSv4 is handled differently and will be covered later.

[bash]# rpcinfo -p galaxy

   program vers proto   port
    100003    2   udp   2049 nfs
    100003    3   udp   2049 nfs
    100003    4   udp   2049 nfs
    100003    2   tcp   2049 nfs
    100003    3   tcp   2049 nfs
    100003    4   tcp   2049 nfs
.
.   ### EXCESS REMOVED ###
.
    100005    1   udp    997 mountd
    100005    1   tcp   1000 mountd
    100005    2   udp    997 mountd
    100005    2   tcp   1000 mountd
    100005    3   udp    997 mountd
    100005    3   tcp   1000 mountd

The NFS mounting daemon can be configured to ignore calls from clients that are trying to connect with certain NFS versions. The following details in the "/etc/sysconfig/nfs" file instructs the mounting daemon to ignore versions 1 and 2. Type "man rpc.mountd" at the command prompt for further details on the mounting daemon.

[bash]# vi /etc/sysconfig/nfs
`RPCMOUNTDOPTS`=`"-N 1 -N 2"`

When you disable mountd versions 1 and 2, then the "showmount -e galaxy" command will fail with an error similar to: "rpc mount export: RPC: Program/version mismatch; low version = 3, high version = 3". This can be alleviated by leaving all NFS versions running on the server and then forcing "nfsvers=3" in your "/etc/fstab" file on the remote client.

This is the "rpcinfo" output after making the above changes (nfs daemon not displayed).

[bash]# rpcinfo -p galaxy
program vers proto port . . ### EXCESS REMOVED ### . 100005 3 udp 997 mountd 100005 3 tcp 1000 mountd

If you intend running NFSv4, then mountd must at least handle support for version 3; you can not disable all versions.

Imports and Mounting

Now that the server has been configured with the exported filesystem, the Linux workstations need to be configured so they can connect to the remote resources for mounting. The portmap service handles the call between the client and server, so the service should be running; the portmap service should already be active in a standard installation.

The rcpinfo command can be used on the Linux client to confirm that portmap service is running.

[bash]# rpcinfo -p linuxwkstn01
program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper

Now that the portmap service is running, the "showmount -e galaxy" command can be executed on the client to query the server for any available exported resources.

[bash]# showmount -e galaxy

The exports that have been made available on the server need to be mounted on the client, this occurs in the same fashion that your partitions are mounted throughout the rest of your filesystem; with the use of mount points.

The workstation needs to have the mount point directories prepared for the exports to connect, creating the directories as required.

[bash]# mkdir /shared
[bash]# mkdir /workfiles
[bash]# mkdir /media/ftp
[bash]# mkdir /media/alice

The file system table (fstab) is a configuration file that details the static mounting details and different types of the filesystems that are configured on the host computer. The configurations may also specify any additional mounting options that should be associated with each entry.

The following entries in fstab list the mounting details for the local workstation that where declared earlier on the NFS server. The filesystem type declared is "nfs" which handles versions 2 and 3 of the protocol. The default version (depending on the server) is version 2, so the entries labeled 2 and 5 below have explicitly defined they are connecting to the server using version 3 (nfsvers=3).

[bash]# cp /etc/fstab /etc/fstab.original [bash]# vi /etc/fstab
1. 2. 3. 4. 5.	galaxy:/home /home nfs defaults 0 0 galaxy:/tmp/fileswap /shared nfs defaults,nfsvers=3,tcp 0 0 galaxy:/filestore /workfiles nfs defaults,rsize=8192,wsize=8192 0 0 galaxy:/var/ftp /media/ftp nfs sync,auto,ro,noexec,hard,intr 0 0 galaxy:/home/alice /media/alice nfs defaults,nfsvers=3,tcp,retry=30,rsize=8192,wsize=8192 0 0

Now that the file system table has been populated with the details needed to connect to the server, the connections can be made by calling the "mount" command. This example says activate the "/workfiles" mount point specified in the fstab file, which is line 3. Because all the relevant details are located in the file, the system will just mount it automatically.

[bash]# mount /workfiles

All of the connections can also be made at the same time by specifying the all (-a) option, and defining all the nfs types (-t). This is a quick command for mounting all the nfs connections at once.

[bash]# mount -a -t nfs

After the connection has been established, a directory listing reveals the directories located on the remote server. It appears seamless to the user and client workstation.

[bash]# ls -l /workfiles

drwxrwx--- 4 root financial 4096 Jan 1 06:07 financial
drwxrwx--- 3 root adminstaff 4096 Jan 1 06:07 adminstaff
drwxrwxrwx 4 root root 4096 Jan 1 06:07 shared

The connections can also be typed manually on the command line using the following example.

[bash]# mount -t nfs galaxy:/var/ftp /tmp/ftp -o ro,sync,auto,hard,intr

To see which connections have been established, the full mount listing can be displayed.

[bash]# mount -l

To disconnect the remote connection, the unmount command can be issued specifying the connection point (mount point).

[bash]# umount /media/ftp
[bash]# umount /workfiles

If the connections are configured correctly but appear to be problematic, then restarting the portmap service can normally assist; though this is rare.

[bash]# /etc/init.d/portmap restart

NFS Version 4

Version:

- kernel 2.6

Version 4 of the NFS brings a new range of advancements to the networking protocol, with access control lists, sophisticated security mechanisms, and better interoperability with firewall and NAT applications to name a few. To the average user the main difference will be in the configuration and its implementation.

Are You NFS4 Ready

If you are using a standard installed Linux distribution, you can easily check to see if it supports version 4. Assuming the nfs service is running on the server, the following "rcpinfo" command can be issued which returns the version numbers and protocols supported by the servers kernel; in this case version 4 is supported with both UDP and TCP (other versions have been removed from the display).

[bash]# rpcinfo -p galaxy
program vers proto port 100003 4 udp 2049 nfs 100003 4 tcp 2049 nfs . . ### EXCESS REMOVED ###

On the server the following mount command displays the running nfs daemon and also the ID to name mapping daemon (new to version 4).

### ON THE SERVER ###
[bash]# mount -l

sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)

On the client the ID to name mapping daemon must also be present.

### ON THE CLIENT ###
[bash]# mount -l

sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

Assuming these small checks are satisfied, your systems should be capable of implementing NFSv4.

Preparing The Server

The earlier versions (2 and 3) of NFS map anonymous users to the nobody account on the server. Depending on your distribution it may already have an account that is configured specifically for NFS anonymous access, in this case the "nfsnobody" account. If not, leave the default as the standard "nobody" account.

[bash]# grep nfs /etc/passwd

nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin

The ID to name mapping daemon is a new enhancement to the NFSv4 protocol, it passes usernames between the client and server after mapping them from (and back to) UID and GID.

[bash]# vi /etc/idmapd.conf

[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = example.com

[Mapping]
Nobody-User = nfsnobody
Nobody-Group = nfsnobody

[Translation]
Method = nsswitch

The ID name mapping settings that are defined on the server also need to be replicated to the client workstations.

Setting Up The Server

The exports for an NFSv4 server are handled very much differently to the earlier versions of the protocol. For a version 4 server, all of the exports are handled through one export point (the pseudofilesystem), with all other exports grouped underneath the master export. Sounds confusing? All of the exports must be put into the one master directory, even if the original directories are located elsewhere in the filesystem.

In our example below, we are going to export several sections of the servers filesystem, however we need to create a master export point (pseudofilesystem), then place all of the exports we intend to share into that one master directory, then we export everything.

The "/NFS4exports" directory will hold all of our local filesystem resources that will be made available as exports, the three sub directories are the actual exported resources which need to be mapped back to the real resources.

[bash]# mkdir /NFS4exports

[bash]# mkdir /NFS4exports/ftp
[bash]# mkdir /NFS4exports/home
[bash]# mkdir /NFS4exports/filestore

The "/NFS4exports" directory and other three sub directories are empty so we need to create the links to the actual areas we are exporting.

Using mount and the fstab file, we are able to "bind" one section of the filesystem to another. This works similar in functionality to a symbolic link, however it is configured as a bind and the files are fully accessible in both sections of the filesystem, not just linked to the original location.

The following configuration is bind mounting the original directories (left) into the main "/NFS4exports" directory. Note the filesystem type is defined as "none" and the only options defined is the "bind" method.

[bash]# vi /etc/fstab

## BIND Mounting The Filesystem ##
/var/ftp /NFS4exports/ftp none bind 0 0
/home /NFS4exports/home none bind 0 0
/filestore /NFS4exports/filestore none bind 0 0

After the fstab file has been configured, the mounts can be binded using the following command.

[bash]# mount -a -t none

The active mounts can be checked to confirm the successful mounting of the bind directories. At this point the filesystems have two access points to the same locations, this should not be confused with a symbolic link (although it is similar in understanding).

[bash]# mount -l | grep bind

/var/ftp on /NFS4exports/ftp type none (rw,bind)
/home on /NFS4exports/home type none (rw,bind)
/filestore on /NFS4exports/filestore type none (rw,bind)

Doing a directory listing of the "/NFS4exports/ftp" directory displays the "pub" directory that is actually located in "/var/ftp". This indicates a successful bind.

[bash]# ls -l /NFS4exports/ftp

drwxr-xr-x 3 root root 4096 Dec 9 15:49 pub

The exports can now be defined for the server, similar to the examples for version 2 and 3. Be sure to check the nfs man page for NFSv4 specific export options. Type "man nfs" at the command prompt.

The most important configuration setting here is the "fsid=0" option which tells the server that this is the pseudofilesystem and that all other directories are contained within this one. Another important setting here is the anonuid and anongid values, they are set to 65534 which is the nfsbody account we identified earlier (if it exists, otherwise nobody account).

[bash]# vi /etc/exports

/NFS4exports 192.168.1.0/24(rw,insecure,sync,wdelay,no_subtree_check,no_root_squash,fsid=0)
/NFS4exports/ftp 192.168.1.0/24(ro,insecure,sync,wdelay,no_subtree_check,nohide,all_squash,anonuid=65534,anongid=65534)
/NFS4exports/filestore 192.168.1.0/24(rw,insecure,sync,wdelay,no_subtree_check,nohide,no_root_squash)
/NFS4exports/home 192.168.1.0/24(rw,insecure,sync,wdelay,no_subtree_check,nohide,no_root_squash)

Starting and Testing

As with the normal configuration, the services need to be configured at the appropriate runlevels and checked.

[bash]# chkconfig --level 345 nfs on
[bash]# chkconfig --level 345 portmap on

[bash]# chkconfig --list nfs
[bash]# chkconfig --list portmap

The services should be restarted.

[bash]# /etc/init.d/nfs restart
[bash]# /etc/init.d/portmap restart

The exports that are available from the server can be checked with the following commands.

[bash]# exportfs -v
[bash]# showmount -e localhost

Setting Up The Client

Before the client can be configured, we need to confirm the exports can be seen and are accessible to the client workstation. The following output displays the psuedofilesystem and the three subordinate exports.

[bash]# showmount -e galaxy

Export list for galaxy:
/NFS4exports           192.168.1.0/24
/NFS4exports/ftp       192.168.1.0/24
/NFS4exports/home      192.168.1.0/24
/NFS4exports/filestore 192.168.1.0/24

Similar to the servers earlier configuration, the client also needs to be configured with the ID to name mapping daemon. These settings should be the same as earlier defined on the server.

[bash]# vi /etc/idmapd.conf

[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = example.com

[Mapping]
Nobody-User = nfsnobody
Nobody-Group = nfsnobody

[Translation]
Method = nsswitch

The major difference for the NFSv4 client is the way the export is going to be mounted. All of the shares are located under one main export; the pseudofilesystem which is the only one that needs to be mounted.

We now need to create the mount point for our connection.

[bash]# mkdir /media/galaxy

The client needs to detail the mounting configurations and options in the fstab file. The noticeable difference below is the explicit setting for "nfs4", if this is missed then the client will attempt to connect with an earlier NFS version.

All of the exports on the server are located under "/NFS4exports", however when the connection is made, the configuration needs to specify the root connection of "galaxy:/" and not "galaxy:/NFS4exports". Using the "/" (root) mount instructs the client to connect to the pseudofilesystem which was earlier configured on the server with the "fsid=0" option.

[bash]# vi /etc/fstab

galaxy:/ /media/galaxy nfs4 auto,rw,nodev,sync,_netdev,proto=tcp,retry=10,rsize=32768,wsize=32768,hard,intr 0 0

The mounting options for NFSv4 are different to earlier versions, type "man nfs" at the command prompt to see the options available for all versions.

Now that the connection is configured on the client, the mount can be established with the following command.

[bash]# mount /media/galaxy

The mount can also be detailed and connected manually by typing a similar command at the prompt.

[bash]# mount -t nfs4 192.168.1.11:/ /mnt/testing \
-o async,auto,exec,_netdev,nodev,rw,retry=5,rsize=32768,wsize=32768,proto=tcp,hard,intr

A listing of the mounted filesystem determines whether the connection was successful.

[bash]# mount -l

galaxy:/ on /mnt/galaxy type nfs4 (rw,addr=galaxy)

Doing a directory listing of the mounted filesystem on the local client returns all of the subordinate mounts on the remote server.

[bash]# ls -l /media/galaxy

drwxr-xr-x 4 root root 4096 Jan 1 06:07 filestore
drwxr-xr-x 3 root root 4096 Jan 1 06:07 ftp
drwxr-xr-x 4 root root 4096 Jan 1 06:07 home

The systems are now all configured with the NFSv4 protocol.

Home