Managing NFS and NIS, 2nd Edition - Mike Eisler [59]
You cannot export any subdirectory of an exported filesystem unless the subdirectory is on a different physical device.
You cannot export any parent directory of an exported filesystem unless the parent is on a different physical device.
You can export only local filesystems.
The first rule allows you to export selected portions of a large filesystem. You can export and mount a single file, a feature that is used by diskless clients. The second and third rules seem both redundant and confusing, but are in place to enforce the selective views imposed by exporting a subdirectory of a filesystem.
The second rule allows you to export /usr/local/bin when /usr/local is already exported from the same server only if /usr/local/bin is on a different disk. For example, if your server mounts these filesystems using /etc/vfstab entries like:
/dev/dsk/c0t0d0s5
/dev/rdsk/c0t0d0s5
/usr/local
ufs
2
no
rw
/dev/dsk/c0t3d0s0
/dev/rdsk/c0t3d0s0
/usr/local/bin
ufs
2
no
rw
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.
Exporting options
The /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:
share [ -d description ] [ -F nfs ] [ -o suboptions ] pathname
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 -F nfs /export/home
# share -F nfs -o rw=corvette /usr/local