Exporting filesystems (Managing NFS and NIS, 2nd Edition)

Client Address dotted quad	Client Address hexadecimal	Netmask dotted quad	Netmask hexadecimal	Access?
193.150.145.33	0xc1969121	193.150.145.63/27	0xc1969120	Yes
193.150.145.128	0xc1969180	193.150.145.63/27	0xc1969120	No

6.2. 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.

6.2.1. 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, then /usr/local is a proper subset of /usr.
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.

6.2.2. 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

Several options modify the way a filesystem is exported to the network:

rw: Permits NFS clients to read from or write to the filesystem. This option is the default; i.e., if none of rw, ro, ro=client_list, or rw=client_list are specified, then read/write access to the world is granted.

ro: Prevents NFS clients from writing to the filesystem. Read-only restrictions are enforced when a client performs an operation on an NFS filesystem: if the client has mounted the filesystem with read and write permissions, but the server specified ro when exporting it, any attempt by the client to write to the filesystem will fail, with "Read-only filesystem" or "Permission denied" messages.

rw=client_list

ro=client_list: Limits the set of hosts that may read (but not write to) the filesystem to the NFS clients identified in client_list. The form of client_list is the same as that described for the rw=client_list option.

anon=uid

root=client_list: Grants superuser access to the NFS clients identified in client_list. The form of client_list is the same as that described for the rw=client_list option. To enforce basic network security, by default, superuser privileges are not extended over the network. The root option allows you to selectively grant root access to a filesystem. This security feature will be covered in Section 12.4.2, "Superuser mapping".

sec=mode[:mode ...]

Requires that NFS clients use the security mode(s) specified. Security modes can be:

sys: This is the default form of security, which assumes a trusted relationship between NFS clients and servers.

dh: This is a stronger form of security based on a cryptographic algorithm known as Diffie-Hellman Key Exchange.

krb5: [9]The getcwd( ) routine builds

krb5i

krb5p: This is a trio of stronger forms of security based on a key management system called Kerberos Version 5.

none: This is the weakest form of security. All users are treated as unknown and are mapped to the anonymous user.

The sec= option can be combined with rw, ro, rw=, ro=, and root= in interesting ways. We will look at that and other security modes in more detail in Section 12.4.4, "Access to filesystems".

aclok: ACL stands for Access Control List. The aclok option can sometimes prevent interoperability problems involving NFS Version 2 clients that do not understand Access Control Lists. We will explore ACLs and the aclokoption in Section 12.4.8, "Access control lists".

nosub
nosuid: Under some situations, the nosub and nosuid options prevent security exposures. We will go into more detail in Chapter 12, "Network Security".

public: This option is useful for environments that have to cope with firewalls. We will discuss it in more detail also in Chapter 12, "Network Security".

Your system may support additional options, so check your vendor's relevant manual pages.


6. System Administration Using the Network File System		6.3. Mounting filesystems

6.2. Exporting filesystems

Table 6-1. Correspondence of Solaris and non-Solaris export components

6.2.1. Rules for exporting filesystems

6.2.2. Exporting options

Table 6-2. Netmask matching