[EdCert previous] [EdCert next] [EdCert top]

NFS Administration

NFS Daemons

NFS uses several daemons to handle various services. The daemons and their related services are generally started at boot time by the system boot scripts. Sometimes daemons are started only if there are files to be made available to NFS services. For specific information on how NFS daemons are started on specific systems, see the vendor's documentation.

Boot scripts that start NFS daemons include:

The major NFS daemons are:

nfsd
nfsd handles client requests from remote systems. Multiple copies of this daemon are usually run so that several requests can be handled simultaneously. However, too many copies of nfsd can increase the demand for CPU time to the point where a drop in performance results. For the best performance the number of copies of nfsd should be set to four.
biod
biod handles block I/O requests for NFS client processes. As with nfsd, several copies are usually run and the number of copies should be set to four.
rpc.mountd
rpc.mountd handles mount requests from remote systems.
rpc.lockd
rpc.lockd manages file locking on NFS client and server machines.
rpc.statd
rpc.statd manages lock crash and recovery services for both client and server systems.
portmap
portmap is not strictly an NFS daemon, although it is required for NFS to function properly. It facilitates the initial connection between local and remote servers. Under Solaris the rpcbind daemon performs the same function.

Installing NFS is fairly simple. Once the software has been installed and NFS capabilities are enabled in the kernel, the daemons need to be started. This can be done with with a script. Some flavors of Unix start these daemons when NFS is installed or upon a reboot following installation of the NFS software. The daemons can also be started from the command line:

# /usr/sbin/biod 4
# /usr/sbin/nfsd 4
# /usr/sbin/rpc.mountd
# /usr/sbin/rpc.statd
# /usr/sbin/rpc.lockd

The number following the command to start the nfsd and biod daemons indicates the number of copies to be run.

Exporting File Systems

Any file system or subset of a file system can be exported. However, subdirectories and parent directories of exported file system can't be exported.

On SGI, HP, SunOS, and Linux systems, the /etc/exports file controls network access to local file systems. The /etc/exports file on the NFS server contains a list of directories that are being exported and any restrictions, attributes, or options associated with them. Common export attributes include:

-access=list
List of hosts that can mount the file system.
-ro
The file system is exported with read-only access to all clients.
-rw=list
The file system is exported with read-only access to all clients except those in the list. Listed clients have read-write access.
-root=list
List of hosts allowed to access the file system as root.
-anon=n
Lists the UID to be used for requests from unknown users.

The /etc/exports file is processed automatically at boot time. Entries in /etc/exports look something like this:

/reports -access=sun.ucs.indiana.edu, rw=teak.uwsg.indiana.edu
/usr/man -ro,access=chrome:copper:zinc,root=chrome

If the /etc/exports file is modified the exportfs command must be run for the changes to take effect immediately.exportfs -u can be used to remove file systems from the export list.

On Linux systems /etc/exports entries have a slightly different format. Options and attributes are listed at the end of each entry in parenthesis, like this:

/usr/local teak(rw) splat(rw) tumnus(ro)

On Solaris systems /etc/dfs/dfstab is used in place of the /etc/exports file. /etc/dfs/dfstab is actually a shell script. Each entry in the script begins with a share command which exports the resource. Entries in /etc/dfs/dfstab look like:

share -F nfs -o ro=sun.ucs.indiana.edu,rw=teak.uwsg.indiana.edu /reports
share -F nfs -o ro=chrome:copper:zinc,root=chrome /usr/man

Like /etc/exports, /etc/dfs/dfstab is executed automatically at boot time. If the dfstab script if modified the shareall command can be used to put the changes into effect immediately. Files can be removed from the script using unshareall.

The showmount -e command can be used on most Unix systems to list all the local file systems that are exported.

Mounting Remote File Systems

An NFS client can mount any file system, or portion of a file system, that is exported from an NFS server. However, NFS does not permit multihopping, mounting a file system from a machine that is already mounting it from another NFS server.

File systems can be mounted by hand using the mount, or placed in a file that tells the system to automatically mount these files at boot time. List of file systems to be mounted at boot time is kept in /etc/fstab on IRIX, HP-UX, SunOS, and OSF/1 systems. Solaris systems use the /etc/vfstab file.

A number of options can be specified for each file system. Common options include:

rw
Mount the file system in read-write mode.
ro
Mount the file system in read-only mode.
hard
If the server is down block the requesting process until the server is back up.
soft
If the server is down return an error to the request process.
intr
This allows users to interrupt a blocked mount operation and force the RPC procedure to return an error.
quota
Disk quotas are being used.
noquota
Disk quotas are not being enforced.
bg
Mount the file system in the background.

/etc/fstab entries look something like this:

/dev/dsk/dks0d4s0 /usr/local xfs rw,noquota 0 0
herbie.ucs.indiana.edu:/usr3/part0/httpd /httpd nfs rw,noquota 0 0

These entries came from the /etc/fstab file on an SGI workstation. The first entry mounts partition 0 on the disk with SCSI ID 4 on /usr/local. xfs indicates the type of file system that's being mounted. The file system is being mounted read-write with no disk quotas. The third entry mounts file systems from a remote systems as indicated by the nfs notation to indicate the type of file system.

Entries in /etc/vfstab take a slightly different form. 

#device         device          mount           FS      fsck    mount   mount
#to mount       to fsck         point           type    pass    at boot option
/proc           -               /proc           proc    -       no      -
fd              -               /dev/fd         fd      -       no      -
swap            -               /tmp            tmpfs   -       yes     -

For further reference here is a list of files used by NFS servers and clients on various Unix systems.

The Automounter

Mounting network file systems at boot time, from a pre-compiled list, can be a complex task that has the potential to cause system interruptions if one of the NFS servers crash. The idea behind the automounter is more flexibility is needed than /etc/fstab and /etc/vfstab can provide. The automounter uses a map file to control how mounting is handled. It also provides a daemon, called automount, that listens for NFS RPC requests on directories. When a request comes in, the automounter issues a mount request for that file system and mounts it in a scratch area. It then creates a symbolic link that points to the desired directory path in that scratch area. An advantage of using an automounter is that file systems are mounted only when they are actually needed, keeping NFS mounts to a minimum. The automounter can also be set up to unmount file systems after a set period of inactivity.

There are three types of automount maps; master, direct, and indirect. The master map contains a list of direct and indirect maps that the automounter should use. Direct and indirect maps contain information on the file systems that are auto-mounted.

The master map is the first map read by automount. It holds a list of indirect and direct maps to be used for mounting. By convention the master map is usually named /etc/auto.master. Below is an example of a master map. 

#Mount Point      Map Name          Map Options
/home             /etc/auto.home    -intr,nosuid
/-                /etc/auto.direct  -ro,intr

The Mount Point field lists the mount point and whether the map is direct or indirect. Direct maps are indicated by /-. The Map Name field tells the automounter where to find the map. The Map Options lists the options to be used for the entire map. Options listed here can be overridden by any options that are set for a specific entry within a map.

Indirect maps are the most common and can be used to mount several file systems under a common directory. Indirect maps are used for local directories whose subdirectories are mounted from remote hosts. The map identifies the name of each local directory along with the associated system and directory to mount. Below is an example of an indirect map used to configure a local /home. Each entry specifies the location of a subdirectory of /home.

bigfoot -rw,intr stomp:/home/bigfoot
dracula -rw,intr castle:/home/dracula
quasimodo -rw,intr church:/home/quasimodo

In each entry the first word is the name of the /home subdirectory where the file system is mounted. This is followed by the mount options, the name of the remote machine where the file system is mounted from, and the path to the file system on that machine.

Direct maps can be thought of as abbreviated versions of /etc/fstab, and /etc/vfstab. They contain entries for remote file systems that are mounted on demand. Below is an example of a direct map.

/bigmess/dirt -rw,intr toclean:/bigmess/dirt

For further optional information on the automounter see The Automounter. For specific optional information on the Sun and public domain automounters see The NFS(tm) Distributed File System and AMD-a public domain automount daemon.



[EdCert previous] [EdCert next] [EdCert top]