6.2. Exporting filesystemsUsually, 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
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.
6.2.1. Rules for exporting filesystemsThere are four rules for making a server's filesystem available to NFS:
then exporting both of them is allowed, since the exported directories reside on different filesystems. If, however, bin was a subdirectory of /usr/local, then it could not be exported in conjunction with its parent.The third rule is the converse of the second. If you have a subdirectory exported, you cannot also export its parent unless they are on different filesystems. In the previous example, if /usr/local/bin is already exported, then /usr/local can be exported only if it is on a different filesystem. This rule prevents entire filesystems from being exported on the fly when the system administrator has carefully chosen to export a selected set of subdirectories. Together, the second and third rules say that you can export a local filesystem only one way. Once you export a subdirectory of it, you can't go and export the whole thing; and once you've made the whole thing public, you can't go and restrict the export list to a subdirectory or two. One way to check the validity of subdirectory exports is to use the df command to determine on which local filesystem the current directory resides. If you find that the parent directory and its subdirectory appear in the output of df, then they are on separate filesystems, and it is safe to export them both. Exporting subdirectories is similar to creating views on a relational database. You choose the portions of the database that a user needs to see, hiding information that is extraneous or sensitive. In NFS, exporting a subdirectory of a filesystem is useful if the entire filesystem contains subdirectories with names that might confuse users, or if the filesystem contains several parallel directory trees of which only one is useful to the user.
6.2.2. Exporting optionsThe /etc/dfs/dfstab file contains a list of filesystems that a server exports and any restrictions or export options for each. The /etc/dfs/dfstab file is really just a list of individual sharecommands, and so the entries in the file follow the command-line syntax of the share command:
Before we discuss the options, pathnameis the filesystem or subdirectory of the filesystem being exported. The -d option allows you to insert a comment describing what the exported filesystem contains. This option is of little use since there are no utilities to let an NFS client see this information. The -F option allows you to specify the type of fileserver to use. Since the share command supports just one fileserver -- NFS -- this option is currently redundant. Early releases of Solaris supported a distributed file-sharing system known as RFS, hence the historical reason for this option. It is conceivable that another file sharing system would be added to Solaris in the future. For clarity, you should specify -F nfs to ensure that the NFS service is used. The -o option allows you to specify a list of suboptions. (Multiple suboptions would be separated by commas.) For example:share [ -d description ] [ -F nfs ] [ -o suboptions ] pathname
Several options modify the way a filesystem is exported to the network:# share -F nfs /export/home # share -F nfs -o rw=corvette /usr/local
Copyright © 2002 O'Reilly & Associates. All rights reserved.