Exporting filesystems

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.

Rules for exporting filesystems

1. 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.
2. You cannot export any subdirectory of an exported filesystem unless the subdirectory is on a different physical device.
3. You cannot export any parent directory of an exported filesystem unless the parent is on a different physical device.
4. You can export only local filesystems.

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

share [ -d description ] [ -F nfs ] [ -o suboptions ] pathname

# share -F nfs /export/home # share -F nfs -o rw=corvette /usr/local

• 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
• Limits the set of hosts that may write to the filesystem to the NFS clients identified in client_list. A client_list has the form of a colon-separated list of components, such that a component is one of the following:
  • hostname
  • The hostname of the NFS client.
  • netgroup
  • The NIS directory services support the concept of a set of hostnames named collectively as a netgroup. See "Network File System Design and Operation" for a description on how to set up netgroups under NIS.
  • DNS domain
  • An Internet Domain Name Service domain is indicated by a preceding dot. For example:
    
    

    # share -o rw=.widget.com /export2
    

    
    
    grants access to any host in the widget.com domain. In order for this to work, the NFS server must be using DNS as its primary directory service ahead of NIS (see "System Management Using NIS").
  • netmask
  • A netmask is indicated by a preceding at-sign (@) and possibly by a suffix with a slash and length to indicate the number of bits in the netmask. Examples will help here:
    
    

    # share -o rw=@129.100.0.0 /export # share -o rw=@193.150.145.63/27 /export2
    

    
    
    The notation of four decimal values separated by periods is known as a dotted quad. In the first example, any client with an Internet Protocol (IP) address such that its first two octets are 129 and 100 (in decimal), will get read/write access to /export. In the second example, a client with an address such that the first 27 bits match the first 27 bits of will get read/write access. The notation /27 is an example of classless addressing, which was previously discussed in "IPv4 address classes". So in the second example, a client with an address of would get access, but another client with the address would not. "System Administration Using the Network File System" clarifies this.

  Table 6-2. Netmask matching

  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

  • -component
  • Each component in the client_list can be prefixed with a minus sign (-) to offer negative matching. This indicates that the component should not get access, even if it is included in another component in the client_list. For example:
    
    

    # share -o rw=-wrench.widget.com:.widget.com /dir
    

    
    
    would exclude the host wrench in the domain widget.com, but would give access to all other hosts in the domain widget.com. Note that order matters. If you did this:
    
    

    # share -o rw=.widget.com:-wrench.widget.com /dir
    

    
    
    host wrench would not be denied access. In other words, the NFS server will stop processing the client_list once it gets a positive or negative match.

• 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
• Maps anonymous, or unknown, users to the user identifier uid. Anonymous users are those that do not present valid credentials in their NFS requests. Note that an anonymous user is not one that does not appear in the server's password file or NIS passwd map. If no credentials are included with the NFS request, it is treated as an anonymous request. NFS clients can submit requests from unknown users if the proper user validation is not completed; we'll look at both of these problems in later chapters. "NFS security" discusses the anon option in more detail.

• 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 "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 "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 "Access control lists".

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

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