Managing NFS and NIS, 2nd Edition - Mike Eisler [58]
The nfsd daemon accepts NFS RPC requests and executes them on the server. Some servers run multiple copies of the daemon so that they can handle several RPC requests at once. In Solaris, a single copy of the daemon is run, but multiple threads run in the kernel to provide parallel NFS service. Varying the number of daemons or threads on a server is a performance tuning issue that we will discuss in Chapter 17. By default, nfsd listens over both the TCP and UDP transport protocols. There are several options to modify this behavior and also to tune the TCP connection management. These options will be discussed in Chapter 17 as well.
The mountd daemon handles client mount requests. The mount protocol is not part of NFS. The mount protocol is used by an NFS server to tell a client what filesystems are available (exported) for mounting. The NFS client uses the mount protocol to get a filehandle for the exported filehandle.
Exporting filesystems
Usually, a host decides to become an NFS server if it has filesystems to export to the network. A server does not explicitly advertise these filesystems; instead, it keeps a list of currently exported filesystems and associated access restrictions in a file and compares incoming NFS mount requests to entries in this table. It is up to the server to decide if a filesystem can be mounted by a client. You may change the rules at any time by rebuilding its exported filesystem table.
This section uses filenames and command names that are specific to Solaris. On non-Solaris systems, you will find the rough equivalents shown in Table 6-1.
Table 6-1. Correspondence of Solaris and non-Solaris export components
Description
Solaris
Non-Solaris
Initial list of filesystems to export
/etc/dfs/dfstab
/etc/exports
Command to export initial list
shareall
exportfs
List of currently exported filesystems
/etc/dfs/sharetab
/etc/xtab
Command to export one filesystem
share
exportfs
List of local filesystems on server
/etc/vfstab
/etc/fstab
The exported filesystem table is initialized from the /etc/dfs/dfstab file. The superuser may export other filesystems once the server is up and running, so the /etc/dfs/dfstab file and the actual list of currently exported filesystems, /etc/dfs/sharetab, are maintained separately. When a fileserver boots, it checks for the existence of /etc/dfs/dfstaband runs shareall(1M) on it to make filesystems available for client use. If, after shareall runs, /etc/dfs/sharetab has entries, the nfsd and mountddaemons are run.
After the system is up, the superuser can export additional filesystems via the share command.
* * *
Tip
A common usage error is invoking the share command manually on a system that booted without entries in /etc/dfs/dfstab. If the nfsd and mountd daemons are not running, then invoking the share command manually does not enable NFS service. Before running the share command manually, you should verify that nfsd and mountd are running. If they are not, then start them. On Solaris, you would use the /etc/init.d/nfs.server script, invoked as /etc/init.d/nfs.server start. However, if there is no entry in /etc/dfs/dfstab, you must add one before the /etc/init.d/nfs.server script will have an effect.
* * *
Rules for exporting filesystems
There are four rules for making a server's filesystem available to NFS:
Any filesystem, or proper subset of a filesystem, can be exported from a server. A proper subset of a filesystem is a file or directory tree that starts below the mount point of the filesystem. For example, if /usr is a filesystem, and the /usr/local directory is part of that filesystem,