Managing NFS and NIS, 2nd Edition - Mike Eisler [204]
startnfsd=0
if [ -f /etc/dfs/dfstab ]; then
/usr/sbin/shareall -F nfs
if /usr/bin/grep -s nfs /etc/dfs/sharetab >/dev/null; then
startnfsd=1
fi
fi
if [ $startnfsd -ne 0 ]; then
/usr/lib/nfs/mountd
/usr/lib/nfs/nfsd -a 16
fi
The dynamically managed file of exported filesystems, /etc/dfs/sharetab, is truncated to zero length during the boot process. This takes place in the nfs.server boot script, although the truncation code is not shown in this example. Once mountd is running, the contents of /etc/dfs/sharetab determine the mount operations that will be permitted by mountd.
/etc/dfs/sharetab is maintained by the share utility, so the modification time of /etc/dfs/sharetab indicates the last time filesystem export information was updated. If a client is unable to mount a filesystem even though the filesystem is named in the server's /etc/dfs/dfstab file, verify that the filesystem appears in the server's /etc/dfs/sharetab file by using share with no arguments:
server% share
- /export/home1 rw "Cool folks"
- /export/home2 root=mahimahi:thud ""
If the sharetab file is out-of-date, then re-running share on the server should make the filesystem available. Note that there's really no difference between cat /etc/dfs/sharetab and share with no arguments. Except for formatting differences, the output is the same.
When mountd accepts a mount request from a client, it notes the directory name passed in the mount request and the client hostname in /etc/rmtab. Entries in rmtab are long-lived; they remain in the file until the client performs an explicit umount of the filesystem. This file is not purged when a server reboots because the NFS mounts themselves are persistent across server failures.
Before an NFS client shuts down, it should try to unmount its remote filesystems. Clients that mount NFS filesystems, but never unmount them before shutting down, leave stale information in the server's rmtab file.
In an extreme case, changing a hostname without performing a umountall before taking the host down makes permanent entries in the server's rmtab file. Old information in /etc/rmtab has an annoying effect on shutdown, which uses the remote mount table to warn clients of the host that it is about to be rebooted. shutdown actually asks the mountd daemon for the current version of the remote mount table, but mountd loads its initial version of the table from the /etc/rmtab file. If the rmtab file is not accurate, then uninterested clients may be notified, or shutdown may attempt to find hosts that are no longer on the network. The out-of-date rmtab file won't cause the shutdown procedure to hang, but it will produce confusing messages. The contents of the rmtab file should only be used as a hint; mission-critical processing should never depend on its contents. For instance, it would be a very bad idea for a server to skip backups of filesystems listed in rmtab on the simple assumption that they are currently in use by NFS clients. There are multiple reasons why this file can be out-of-date.
The showmount command is used to review server-side mount information. It has three invocations:
showmount -a [server] Prints client:directory pairs for server's clients.
showmount -d [server] Simply prints directory names mounted by server's clients.
showmount -e [server] Prints the list of shared filesystems.
For example:
% showmount -a
bears:/export/home1
bears:/export/home2/wahoo
honeymoon:/export/home2/wahoo
131.40.52.44:/export/home1
131.40.52.44:/export/home2
% showmount -d mahimahi
/export/home1
/export/home2
% showmount -e mahimahi
/export/home1 (everyone)
/export/home2 (everyone)
In the first example, an unknown host, indicated by the presence of an IP address instead of a hostname, has mounted filesystems from the local host. If the IP address is valid on the local network,