There are a number of export options for managing the export process. Some commonly used export options are briefly described below. For a complete explanation of options, see the exports(4) reference page.

ro		(read only) Export this file system with read-only privileges.
rw		(read, write) Export this file system with read and write privileges. rw is the default.
rw=		(read mostly) Export this file system read-only to all clients except those listed. Note: Directories are exported either ro or rw, not both ways. The option specified first is used.
anon=		(anonymous UID) If a request comes from the user root (UID = 0), use the specified UID as the effective UID instead. By default, the effective UID is nobody (UID = –2). Specifying a UID of –1 disables access by unknown users or by root on a host not specified by the root option. Use the root option to permit accesses by the user root.
root=		Give superuser privileges to root users of NFS-mounted directories on systems specified in root access list. By default, root is set to none.
access=		Grant mount privileges to a specified list of clients only. Clients can be listed individually or as an NIS netgroup (see netgroup(4)).
nohide		(IRIX enhancement) By default, the contents of a child file system are hidden when only the parent file system is mounted. Allow access to this file system without performing a separate mount if its parent file system is mounted.
wsync		(IRIX enhancement for NFS2 only) Perform all write operations to disk before sending an acknowledgment to the client. Overrides delayed writes. (See “NFS Input/Output Management” in Chapter 1 for details.)
32bitclients		Causes the server to mask off the high-order 32 bits of directory cookies in NFS3 directory operations. This option may be required when clients run 32-bit operating systems such as IRIX 5.3.

When a file system or directory is exported without specifying options, the default options are rw and anon=nobody.

A default version of the /etc/exports file is shipped with NFS software and stored in /etc/exports when NFS is installed. You must add your own entries to the default version as part of the NFS setup procedure (given in “Setting Up the NFS Server” in Chapter 4). This sample /etc/exports illustrates entries and how to structure them with various options:

/dev/root     -ro
/reports      -access=finance,rw=susan,nohide
/usr          -nohide
/usr/demos    -nohide,ro,access=client1:client2:client3
/usr/catman   -nohide

In this sample /etc/exports, the first entry exports the root directory (/) with read-only privileges. The second entry exports a separate file system, /reports, read-only to the netgroup finance, with write permission specified for susan. Users who mount the root directory can access the /reports, /usr, /usr/demo and /usr/catman file systems (if they are in finance) because nohide is specified.

The fourth entry uses the access list option. It specifies that client1, client2, and client3 are authorized to access /usr/demos with read-only privileges. To avoid possible problems, client1, client2, and client3 should be fully qualified domain names.

---

Note: If you are using an access list to export to a client with multiple network interfaces, the /etc/exports file must contain all names associated with the client's interfaces. For example, a client named octopus with two interfaces needs two entries in the /etc/exports file, typically octopus and gate-octopus.

---

The fifth entry is an example of an open file system. It exports /usr/catman to the entire world with read-write access (the default when neither ro or rw is specified) to its contents.

There are several options for configuring mounts. When you use these options, it is important to understand that export options (specified on a server) override mount options, in the sense that the more restrictive options take precedence. NFS /etc/fstab options are briefly described below (see the fstab(4) reference page for complete information):

In addition to these options, /etc/fstab also offers several options dedicated to attribute caching. Using these options, you can direct NFS to cache file attributes, such as size and ownership, to avoid unnecessary network activity. See the fstab(4) reference page for more details.

NFS entries in /etc/fstab are designated by the nfs identifier, while XFS (local file systems) entries are designated by xfs. This sample /etc/fstab file includes a typical NFS entry:

/dev/root           /         xfs rw,raw=/dev/rroot 0 0
redwood:/usr/demos  /n/demos  nfs ro,bg 0 0

In this example, the NFS directory /usr/demos on server redwood is mounted at mount point /n/demos on the client system with read-only (ro) permissions (see Figure 1-2). Mounting executes as a background task (bg) if it didn't succeed the first time. By default, if the server fails after the mount has taken place, the client attempts to complete any NFS transactions indefinitely (hard) or until it receives an interrupt.

By default, when automount executes at boot time, it reads the /etc/config/automount.options file for initial operating parameters. The information contained in the /etc/config/automount.options file can contain the complete information needed by the automounter or the information can direct automount to a set of files that contain customized automounting instructions. /etc/config/automount.options cannot have comments in it.

The default version of /etc/config/automount.options is:

-v /hosts -hosts -nosuid,nodev

This /etc/config/automount.options directs automount to execute with the verbose (–v) option. It also specifies that automount should use /hosts as its daemon mount point. When a user accesses a file or directory under /hosts, the –hosts argument directs automount to use the pathname component that follows /hosts as the name of the NFS server. All accessible file systems exported by the server are mounted to the default mount point /tmp_mnt/hosts/hostname with the nosuid and nodev options.

For example, if the system redwood has the following entry in /etc/exports:

/
/usr 	-ro,nohide

And a client system is using the default /etc/config/automount.options file, as above, then executing the following command on the client lists the contents of the directory /usr on redwood:

ls -l /hosts/redwood/usr/*

Mount points for automount serve the same function as mount points in conventional NFS mounting. They are the access point in the client's file system where a remote NFS directory is attached. There are two major differences between automount mount points and conventional NFS mount points.

With automount, mount points are automatically created and removed as needed by the automount program. When the automount program is started, it reads configuration information from /etc/config/automount.options, additional automount maps, or both, and creates all mount points needed to support the specified configuration.

By default, automount mounts everything in the directory /tmp_mnt and creates a link between the mounted directory in /tmp_mnt and the accessed directory. For example, in the default configuration, mounts take place under /tmp_mnt/hosts/hostname. The automounter creates a link from the access point /hosts/hostname to the actual mount point under /tmp_mnt/hosts/hostname. The command ls /hosts/redwood/tmp displays the contents of server redwood's /tmp directory. You can change the default root mount point with the automount –M option.

By default, when autofs executes at boot time, it reads the /etc/config/autofs.options and /etc/auto_master files for initial operating parameters. /etc/config/autofs.options cannot have comments in it.

The default version of /etc/config/autofs.options is:

-v 

This /etc/config/autofs.options directs autofs to execute with the verbose (–v) option.

The default /etc/auto_master contains:

/hosts -hosts -nosuid,nodev

This file specifies that autofs should use /hosts as its daemon mount point. When a user accesses a file or directory under /hosts, the –hosts argument directs autofs to use the pathname component that follows /hosts as the name of the NFS server. All accessible file systems exported by the server are mounted to the default mount point /hosts/hostname with the nosuid and nodev options.

For example, if the system redwood has the following entries in /etc/exports:

/
/usr -ro,nohide

and a client system is using the default /etc/auto_master file, as above, then executing the following command on the client lists the contents of the directory /usr on redwood:

ls -l /hosts/redwood/usr/*

Mount points for autofs serve the same function as mount points in conventional NFS mounting. They are the access point in the client's file system where a remote NFS directory is attached. Noticeably different from automount, autofs performs mounts in place; it does not link /hosts with /tmp_mnt.

With AutoFS, mount points are automatically created and removed as needed by the autofs program. When the autofs program is started, it reads configuration information from /etc/config/autofs.options, additional autofs maps, or both, and creates all mount points needed to support the specified configuration.

The autofs command installs AutoFS mount points and associates an AutoFS map with each mount point. The AutoFS file system monitors attempts to access directories within it and notifies the autofsd daemon. The daemon uses the map to locate a file system, and then mounts it at the point of reference within the AutoFS file system. Maps can be assigned to an AutoFS mount using an entry in the /etc/auto_master map or they can be combined in another map file referenced in an /etc/auto_master entry.

The master map is the first file read by the automount or autofs program. There is only one master map on a client. It specifies the types of supported maps, the name of each map to be used, and options that apply to the entire map (if any). By convention, the master map is called /etc/auto.master with automount (but the name can be changed) and /etc/auto_master with autofs (this name cannot be changed).

With automount, for complex automatic mounter configurations, a master map can be specified in the /etc/config/automount.options file. For example, /etc/config/automount.options might contain:

-v -f /etc/auto.master

The automount master map can be a local file or an NIS database file. For autofs, it must be a local file named /etc/auto_master. The master map contains three fields: mount point, map name, and map options. A crosshatch (#) at the beginning of a line indicates a comment line. A sample of master map entries is:

#Mount Point     Map Name              Map Options
/hosts           -hosts                -nosuid,nodev
/net             /etc/auto_irix.misc   -nosuid
/home            /etc/auto_home        -timeo=20
/-               /etc/auto_direct      -ro
/net2            /etc/indirect2        -ro,vers=2

The mount point field serves two purposes. It determines whether a map is a direct or indirect map, and it provides mount point information. A slash followed by a dash (/–) in the mount point field designates a direct map. It signals the automatic mounter to use the mount points specified in the direct map for mounting this map. For example, to mount the fourth entry in the sample above, the automatic mounter gets a mount point specification from the direct map /etc/auto_direct. In the fifth entry, an entire indirect map, which includes all its entries, is declared to use the NFS version 2 protocol. The default for automount is NFS version 2; the default for autofs is NFS version 3, and if it is not available on the server, the mount tries to NFS version 2.

A directory name in the mount point field designates an indirect map. It specifies the mount point the automatic mounter should use when mounting this map. For example, the second entry in the sample above tells the automatic mounter to mount the indirect map /etc/auto.irix.misc at mount point /net. A mount point for direct and indirect maps can be several directory levels deep.

The map name field in a master map specifies the full name and location of the map. Notice that –hosts is considered an indirect map whose mount point is /hosts. The –hosts map mounts all the exported file systems from a server. If frequent access to just a single file system is required for a server with many exports that do not use the -nohide option, it is more efficient to access that file system with a map entry that mounts just that file system.

The map options field can be used to specify any options that should apply to the entire map. Options set in a master map can be overridden by options set for a particular entry within a map.

Direct maps allow mounted directories to be distributed throughout a client's local file system. They contain the information that the automatic mounter needs to determine when, what, and how to mount a remote NFS directory. You can have as many direct maps as needed. A direct map for AutoFS is typically called /etc/auto.mapname, where mapname is some logical name that reflects the map's contents.

All direct maps contain three fields: directory, options, and location. An example of an /etc/auto_direct direct map is:

#Directory          Options   Location
/usr/local/tools    -nodev    ivy:/usr/cooltools
/usr/frame                    redwood:/usr/frame
/usr/games          -nosuid   peach:/usr/games 

In a direct map, users access the NFS directory with the pathname that is identical to the directory field value in the direct map. For example, a user gives the command cd /usr/local/tools to mount /usr/cooltools from server ivy as specified in the direct map /etc/auto_direct. Notice that the directory field in a direct map can include several subdirectory levels.

The options field can be used to set options for an entry in the direct map. Options set within a map for an individual entry override the general option set for the entire map in the master map. The location field contains the NFS server's name and the remote directory to mount.

Indirect maps allow remotely mounted directories to be housed under a specified shared top-level location on the client's file system. They contain the specific information the automatic mounter program needs to determine when, what, and how to NFS mount a remote directory. You can have as many indirect maps as needed.

An indirect map is typically called /etc/auto.mapname (for automount) and /etc/auto_mapname (for autofs), where mapname is some logical name that reflects the map's contents. Indirect maps can be grouped according to logical characteristics. For example, in the master map above, the indirect map /etc/auto_home, indicated by the mount point /home, can include mounting information for all home directories on various servers.

Indirect maps contain three fields: directory, options, and location. Entries might look something like this for the /etc/auto_home indirect map:

#Directory    Options       Location
willow                      willow:/usr/people
rudy          -nosuid       pine:/usr/people/rudy
bruiser       -ro,nointr    ivy:/usr/people/bruiser
jinx          -ro,vers=2    jinx:/usr

With an indirect map, user access to an NFS directory is always relative to the mount point specified in the master map entry for the indirect map. That is, the directory is the concatenation of the mount-point field in the master map and the directory field in the indirect map. For example, given our sample /etc/auto_master and indirect map /etc/auto_home, a user gives the command cd /home/willow to access the NFS directory willow:/usr/people.

If a user changes the current working directory to the /home directory and tries to list its contents, the directory appears empty unless a subdirectory of /home, such as /home/willow, was previously accessed, thereby mounting /home subdirectories. Access to the mount point of an indirect map only shows information for mounts currently in effect; it does not trigger mounts, as with direct maps. Users must access a subdirectory to trigger a mount.

The directory field in an indirect map is limited to one subdirectory level. Additional subdirectory levels for indirect maps must be indicated in the mount point field in the master map, or on the command line for automount.

The options field can be used to set options for an entry in the indirect map. For example, the fourth entry attempts to mount using the NFS2 protocol, all other entries are unaffected. Options set within a map for an entry override the general options set for the entire map in the master map. The location field contains the NFS server's name and the remote directory to mount.

When mounting and unmounting a CacheFS file system, the following option is used for CacheFS. For descriptions of the other options, see “Customizing mount and umount Commands”.

For an example of a fundamental /etc/fstab file and an explanation of the /etc/fstab mount process, see “/etc/fstab Mount Process”. The /etc/fstab file also has several added options that are used with CacheFS for mounting and unmounting.

Any mount options not recognized by CacheFS are passed to the back file system mount if one is performed.

These added options for CacheFS are:

The default values for the cache parameters are for a cache that uses the entire front file system for caching. To limit the cache to only a portion of the front file system, you should change the parameter values.

Any parameter may be changed at any time. The change does not take effect however, until all file systems for the affected cache have been unmounted and remounted.

Table 2-2 shows the parameters for space and file allocation.

Table 2-3 shows the default values for the cache parameters. The default values for parameters devote the full resources of the front file system to caching

The maxblocks parameter sets the maximum number of blocks, expressed as a percentage, that CacheFS is allowed to claim within the front file system. The maxblocks percentage is relative to the total number of blocks on the front file system, not what has been allocated by CacheFS. The maxfiles parameter sets the maximum percentage of available inodes (number of files) CacheFS can claim.

---

Note: The maxblocks and maxfiles parameters do not guarantee the resources will be available for CacheFS—they set maximums. If you allow the front file system to be used for purposes other than CacheFS, there may be fewer blocks or files available to CacheFS than you intend.

---

The hiblocks parameter sets the high water mark for disk usage, and lowblocks sets the low water mark, expressed as a percentage of the total number of blocks available to CacheFS. The hifiles and lowfiles parameters set the maximum and minimum blocks available for file system use. When the maximum number of blocks or files has been reached, CacheFS will begin removing cached files to stay within the established percentage.

The maxblocks, maxfiles, hiblocks, hifiles, lowblocks and lowfiles values apply to the entire front file system, not file systems you have cached under the front file system.

---

Note: Using the whole front file system solely for caching eliminates the need to change the maxblocks, maxfiles, hiblocks, hifiles or the corresponding low parameters.

---

CacheFS allows the cache to grow to the maximum size specified—if you have not reduced available resources by using part of the front file system for other storage purposes.

The cfsstat command displays and reinitializes statistics about CacheFS. It must be used as the superuser. For more information, refer to the cfsstat(1M) reference page.