UNIX System Administration Handbook - Evi Nemeth [294]
Since xtab and sharetab aren’t human-readable, you use a helper command to add and modify entries. On most systems this command is exportfs; Solaris uses share. To remove entries from the exports table, use exportfs -u or unshare.
Maintaining a binary file by hand is not much fun, so most systems assume (correctly) that you would rather maintain a text file that enumerates all of the system’s exported directories and their access settings. The system can then consult this text file at boot time to automatically construct the xtab or sharetab file.
On most systems, /etc/exports is the canonical, human-readable list of exported directories. Its contents are read by exportfs -a. Under Solaris, the canonical list is /etc/dfs/dfstab, which is really just a script containing a series of share commands. (The shareall command greps the NFS-related commands out of dfstab and runs them. Since NFS is the only file-sharing system in common use, shareall is equivalent to sh /etc/dfs/dfstab.)
FreeBSD is unusual in that its mountd consults /etc/exports directly; there is no binary xtab file or exportfs command. After editing the exports file, you must send mountd a HUP signal to tell it to reread the file’s contents:
# kill -HUP `cat /var/run/mountd.pid`
Table 17.2 summarizes the last few paragraphs. It tells you what file to edit when you want to export a new filesystem and what to do once you’ve finished editing to make your changes take effect.
Table 17.2 Where to set up exported directories
NFS deals with the logical layer of the filesystem. Any directory can be exported; it doesn’t have to be a mount point or the root of a physical filesystem. However, for security reasons, NFS does pay attention to the boundaries between filesystems and does require each device to be exported separately. For example, on a machine that has a /users partition, the root directory can be exported without exporting /users.
Clients are usually allowed to mount subdirectories of an exported directory if they wish, although the protocol does not require this feature. For example, if a server exports /chimchim/users, a client could mount only /chimchim/users/joe and ignore the rest of the users directory. Most systems don’t let you export subdirectories of an exported directory with different options, although Red Hat is an exception.
The share command and dfstab file (Solaris)
/etc/dfs/dfstab executes the share command once for each exported filesystem. For example, on a server that shares /chimchim/users with hosts band and moon (with band allowed root access) and shares /usr/share/man with chimchim and rastadon, the /etc/dfs/dfstab file would contain the following commands:
share -F nfs -o rw=band.xor.com:moon.xor.com,root=band.xor.com
/chimchim/users
share -F nfs -o rw=chimchim.xor.com:rastadon.xor.com /usr/share/man
After editing /etc/dfs/dfstab, remember to run shareall to make your changes take effect. Note that since shareall simply runs the commands in the dfstab file, it will not unshare filesystems that you remove. Table 17.3 lists the most common options.
Table 17.3 Options for the share command (Solaris)
Wherever a list is called for in a share option, it should consist of a colon-separated group of the items shown in Table 17.4, all of which are ways of specifying hosts or groups of hosts.
Table 17.4 Client specifications for the share command
a. CIDR-style specifications are also accepted; for example, @128.138.92.128/25.
The note in Table 17.4 regarding hostnames bears repeating: if your site uses DNS, individual hostnames must be fully qualified or they will be ignored.
You can put a dash in front of an item to explicitly disallow it. The list is examined from left to right during each lookup until a matching item is found, so negations should precede the more