The Network File System (NFS) allows directories and files to be shared across a network. It was originally developed by Sun Microsystems but is now supported by virtually all Unix and many non-Unix operating systems. Through NFS, users and programs can access files located on remote systems as if they were local files. In a perfect NFS environment, the user neither knows nor cares where files are actually stored.
NFS has several benefits:
It reduces local disk storage requirements because a server can store a single copy of a directory that is fully accessible to everyone on the network.
It simplifies central support tasksfiles can be updated centrally yet be available throughout the network.
It allows users to use familiar Unix commands to manipulate remote files instead of learning new commands. There is no need to use ftp or rcp to copy a file between hosts on the network; cp works fine.
There are two sides to NFS: a client side and a server side. The client is the system that uses the remote directories as if they were part of its local filesystem. The server is the system that makes the directories available for use. Attaching a remote directory to the local filesystem (a client function) is called mounting a directory. Offering a directory for remote access (a server function) is called sharing or exporting a directory. Frequently, a system runs both the client and the server NFS software. In this section we'll look at how to configure a system to export and mount directories using NFS.
 Solaris uses the term sharing. Most other systems use the term exporting.
If you're responsible for an NFS server for a large site, you should take care in planning and implementing the NFS environment. This chapter describes how NFS is configured to run on a client and a server, but you may want more details to design an optimal NFS environment. For a comprehensive treatment, see Managing NFS and NIS by Hal Stern (O'Reilly & Associates).
The Network File System is run by several daemons, some performing client functions and some performing server functions. Before we discuss the NFS configuration, let's look at the function of the daemons that run NFS on a Solaris 8 system:
The NFS daemon, nfsd, runs on NFS servers. This daemon services the client's NFS requests. The nservers option specifies how many daemons should be started.
The NFS mount daemon, mountd, processes the clients' mount requests. NFS servers run the mount daemon.
The NFS logging daemon, nfslogd, logs activity for exported filesystems. NFS servers run the logging daemon.
The remote quota server, rquotad, provides information about user quotas on remote filesystems that is then displayed by the quota command. The remote quota server is run on both clients and servers.
The lock daemon, lockd, handles file lock requests. Both clients and servers run the lock daemon. Clients request file locks, and servers grant them.
The network status monitor daemon, statd, is required by lockd to provide monitoring services. In particular, it allows locks to be reset properly after a crash. Both clients and servers run statd.
On a Solaris 8 system, the daemons necessary to run NFS are found in the /usr/lib/nfs directory. Most of these daemons are started at boot time by two scripts located in the /etc/init.d directory, nfs.client and nfs.server. The nfs.client script starts the statd and lockd programs.
 Alternatively, the prefix rpc. may be used on the daemon names. For example, the Slackware Linux system uses the filename rpc.nfsd for the NFS daemon. Check your system's documentation.
NFS server systems run those two daemons, plus the NFS server daemon (nfsd), the NFS logging daemon (nfslogd), and the mount server daemon (mountd). On Solaris systems, the nfs.server script starts mountd, nfslogd, and 16 copies of nfsd. Solaris systems do not normally start rquotad at boot time. Instead, rquotad is started by inetd, as this grep of the /etc/inetd.conf file shows:
$ grep rquotad /etc/inetd.conf rquotad/1 tli rpc/datagram_v wait root /usr/lib/nfs/rquotad rquotad
Each system has its own technique for starting these daemons. If some of the daemons aren't starting, ensure your startup scripts and your inetd.conf file are correct.
The first step in configuring a server is deciding which filesystems will be shared and what restrictions will be placed on them. Only filesystems that provide a benefit to the client should be shared. Before you share a filesystem, think about what purpose it will serve. Some common reasons for sharing filesystems are:
To provide disk space to diskless clients
To prevent unnecessary duplication of the same data on multiple systems
To provide centrally supported programs and data
To share data among users in a group
Once you've selected the filesystems you'll share, you must configure them for sharing using the appropriate commands for your system. The following section emphasizes the way this is done on Solaris systems. It is very different on Linux systems, which are covered later. Check your system's documentation to find out exactly how it implements NFS file sharing.
On Solaris systems, directories are exported using the share command.
A simplified syntax for the share command is:
share -F nfs [-o options ] pathname
where pathname is the path of the directory the server is offering to share with its clients, and options are the access controls for that directory. The options are:
The rw option grants read and write access to the shared filesystem. It can be specified in the form rw=accesslist to identify the systems that are granted this access. When used in this way, only the systems identified in the list are given access to the filesystem. If the access list is not provided with the rw option, all hosts are given read/write access to the filesystem.
This option limits access to read-only. It also can be specified with an access list, e.g., ro=accesslist. When the access list is included, only the systems on the list have access and that access is limited to read-only. If the access list is not provided with the ro option, all hosts are given read-only access to the filesystem, which is the default if no options are specified.
This option grants full access to all clients, which could open up a security hole. This option is documented on the Solaris system, but it should never be used. It is intended to provide backward compatibility with a version of NFS that no longer exists.
Defines the UID used for users who do not provide a valid user ID.
Tells NFS to use a web-style index file instead of a directory listing for this filesystem.
Enable logging. If an optional tag is specified, it must match a tag defined in the /etc/nfs/nfslog.conf file.
Do not allow clients to mount subdirectories. The default is sub, which allows subdirectories to be mounted.
Do not allow clients to create setuid or setgid files on this filesystem. The default is suid, which allows clients to create setuid and setgid files.
Use the public file handle for this filesystem.
This option allows the root users from the systems specified by the access list to have root access to the filesystem.
Defines the type of authentication used for accessing this filesystem. type is a colon-separated list of NFS security modes. For access to be successful, the client must support at least one of the security modes identified in the type list. The possible type values are:
Use clear-text user IDs and group IDs to control access to the filesystem. This is the same as traditional Unix file permissions, which are granted based on UID and GID, with the exception that the UID and GID are passed over the network and the server must trust the remote source.
Use Diffie-Hellman public key cryptography for authentication.
Use the Kerberos Version 4 for authentication.
Do not use authentication. When no authentication is used, all users access the filesystem as user nobody.
Defines the maximum lifetime in seconds that the NFS server will permit for a dh or krb4 authentication. The server rejects any security credentials that have a longer lifetime value. seconds defaults to 30000.
A few of the options contain an access list. The access list is a colon-separated list that identifies computers by individual hostnames, individual IP addresses, or by the domain, network, or NIS netgroup to which the hosts belong. The syntax of these list elements is:
This is any hostname that resolves to an IP address. It can be a fully qualified name or just the hostname as long as the name as written will resolve to an IP address. If the hostname can be found in the local host table, the short name can be used. If the name must be resolved by DNS, the fully qualified hostname, with its domain name attached, should be specified. However, fully qualified names should not be used if your system does not use DNS, i.e., if your system relies exclusively on NIS.
An IP address in dotted decimal format can be used.
If an NIS netgroup name is used, the option applies to every system within that netgroup. Netgroup names look identical to unqualified hostnames and are easy to confuse with hostnames. Netgroup names should only be used if your system uses NIS.
A domain name is used to apply the option to every system within that domain. When a domain name is used, it is preceded by a dot (.). Thus .wrotethebook.com applies to every system in the wrotethebook.com domain. Domain names should be used only if your server uses DNS.
A network address is used to apply an option to every system within the network. When a network address is used, it must be preceded by an at-sign (@). An optional network prefix can be used with the address to clearly define the network mask.
The rw and ro options can be combined to grant different levels of access to different clients. For example:
share -F nfs -o rw=crab:horseshoe ro /usr/man share -F nfs -o rw=rodent:crab:horseshoe:jerboas /export/home/research
The first share command grants read and write access to crab and rodent, and read-only access to all other clients. On the other hand, the second share command grants read/write access to rodent, crab, horseshoe, and jerboas, and no access of any kind to any other client.
The share command does not survive a boot. Put the share commands in the /etc/dfs/dfstab file to make sure that the filesystems continue to be offered to your clients even if the system reboots. Here is a sample dfstab file containing our two share commands:
% cat /etc/dfs/dfstab # place share(1M) commands here for automatic execution # on entering init state 3. # # share [-F fstype] [ -o options] [-d "<text>"] <pathname> [resource] # .e.g., # share -F nfs -o rw=engineering -d "home dirs" /export/home2 share -F nfs -o rw=crab:horseshoe ro /usr/man share -F nfs -o rw=rodent:crab:horseshoe:jerboas /export/home/research
The share command, the dfstab file, and even the terminology "share" are Solaris-specific. Most Unix systems say that they are exporting files, instead of sharing files, when they are offering files to NFS clients. Furthermore, they do not use the share command or the dfstab file; instead, they offer filesystems through the /etc/exports file. Linux is an example of such a system.
The /etc/exports file is the NFS server configuration file for Linux systems. It controls which files and directories are exported, which hosts can access them, and what kinds of access are allowed. A sample /etc/exports file might contain these entries:
/usr/man crab(rw) horseshoe(rw) (ro) /usr/local (ro) /home/research rodent(rw) crab(rw) horseshoe(rw) jerboas(rw)
This sample file says that:
/usr/man can be mounted by any client, but it can be written to only by crab and horseshoe. Other clients have read-only access.
/usr/local can be mounted by any client, with read-only access.
/home/research can be mounted only by the hosts rodent, crab, horseshoe, and jerboas. These four hosts have read/write access.
The options used in each of the entries in the /etc/exports file determine what kinds of access are allowed. The information derived from the sample file is based on the options specified on each line in the file. The general format of the entries is as follows:
directory names the directory or file that is available for export. The host is the name of the client granted access to the exported directory, while the option specifies the type of access being granted.
In the sample /etc/exports file shown above, the host value is either the name of a single client or it is blank. When a single hostname is used, access is granted to the individual client. If no hostvalue is specified, the directory is exported to everyone. Like Solaris, Linux also accepts values for domains, networks, and netgroups, although the syntax is slightly different. Valid host values are:
Individual hostnames such as crab or crab.wrotethebook.com.
Domain wildcards such as *wrotethebook.com for every host in the wrotethebook.com domain.
IP address/address mask pairs such as 172.16.12.0/255.255.255.0 for every host with an address that begins with 172.16.12.
Net groups such as @group1.
Notice that in Linux, domain names begin with an asterisk (*), instead of the dot used in Solaris. Also note that the at-sign begins a netgroup name, whereas in Solaris the at-sign is used at the beginning of a network address.
The options used in the sample /etc/exports file are:
Read-only prevents NFS clients from writing to this directory. Attempts by clients to write to a read-only directory fail with the message "Read-only filesystem" or "Permission denied." If ro is specified without a client hostname, all clients are granted read-only access.
Read/write permits clients to read and write to this directory. When specified without hostname, all clients are granted read/write access. If a hostname is specified, only the named host is given read/write permission.
Although specific hosts are granted read/write access to some of these directories, the access granted to individual users of those systems is controlled by standard Unix user, group, and world file permissions based on the user's user ID (UID) and group ID (GID). NFS trusts that a remote host has authenticated its users and assigned them valid UIDs and GIDs. Exporting files grants the client system's users the same access to the files they would have if they directly logged into the server. This assumes, of course, that both the client and the server have assigned exactly the same UIDs and GIDs to the same users, which is not always the case. If both the client and the server assign the same UID to a given user, for example, if Craig is assigned 501 on both systems, then both systems properly identify Craig and grant him appropriate access to his files. On the other hand, if the client assigns Craig a UID of 501 and the server has assigned that UID to Michael, the server will grant Craig access to Michael's files as if Craig owned those files. NFS provides several tools to deal with the problems that arise because of mismatched UIDs and GIDs.
One obvious problem is dealing with the root account. It is very unlikely that you want people with root access to your clients to also have root access to your server. By default, NFS prevents this with the root_squash setting, which maps requests that contain the root UID and GID to the nobody UID and GID. Thus if someone is logged into a client as root, they are only granted world permissions on the server. You can undo this with the no_root_squash setting, but no_root_squash opens a potential security hole.
Map other UIDs and GIDs to nobody with the squash_uids, squash_gids, and all_squash options. all_squash maps every user of a client system to the user nobody. squash_uids and squash_gids map specific UIDs and GIDs. For example:
/pub (ro,all_squash) /usr/local/pub (squash_uids=0-50,squash_gids=0-50)
The first entry exports the /pub directory with read-only access to every client. It limits every user of those clients to the world permissions granted to nobody, meaning that the only files the users can read are those that have world read permission.
The second entry exports /usr/local/pub to every client with default read/write permission. The squash_uid and squash_gid options in the example show that a range of UIDs and GIDs can be specified in some options. A single UID or GID can be defined with these options, but it is frequently useful to affect a range of values with a single command. In the example we prevent users from accessing the directory with a UID or GID that is 50 or less. These low numbers are usually assigned to non-user accounts. For example, on our Linux system, UID 10 is assigned to uucp. Attempting to write a file as uucp would cause the file to be written with the owner mapped to nobody. Thus the user uucp would be able to write to the /usr/local/pub directory only if that directory had world write permission.
 Of the eight options discussed in this section, three, squash_uid, squash_gid, and map_static, map a range of UIDs and GIDs. These three options are not available in the kernel-level NFS (knfsd) used on some Linux systems. Mapping for knfsd must be done with the other options.
It is also possible to map every user from a client to a specific user ID or group ID. The anonuid and anongid options provide this capability. These options are most useful when the client has only one user and does not assign that user a UID or GID, for example, in the case of a Microsoft Windows PC running NFS. PCs generally have only one user and they don't use UIDs or GIDs. To map the user of a PC to a valid user ID and group ID, enter a line like this in the /etc/exports file:
In this example, the hostname of Alana's PC is giant. The entry grants that client read/write access to the directory /home/alana. The all_squash option maps every request from that client to a specific UID, but this time, instead of nobody, it maps to the UID and the GID defined by the anonuid and anongid options. Of course, for this to work correctly, 1001:1001 should be the UID and GID pair assigned to alana in the /etc/passwd file.
A single mapping is sufficient for a PC, but it might not handle all of the mapping needed for a Unix client. Unix clients assign their users UIDs and GIDs. Problems occur if those differ from the UIDs and GIDs assigned to those same users on the NFS server. Use the map_static option to point to a file that maps the UIDs and GIDs for a specific client. For example:
This entry says that the /export/oscon directory is exported to the client oscon with read/write permission. The map_static option points to a file on the server named /etc/nfs/oscon.map that maps the UIDs and GIDs used on oscon to those used on the server. The oscon.map file might contain the following entries:
# UID/GID mapping for client oscon # remote local comment uid 0-50 - #squash these gid 0-50 - #squash these uid 100-200 1000 #map 100-200 to 1000-1100 gid 100-200 1000 #map 100-200 to 1000-1100 uid 501 2001 #map individual user gid 501 2001 #map individual user
The first two lines map the UIDs and GIDs from 0 to 50 to the user nobody. The next two lines map all of the client UIDs and GIDs in the range of 100 to 200 to corresponding numbers in the range of 1000 to 1100 on the server. In other words, 105 on the client maps to 1005 on the server. This is the most common type of entry. On most systems, existing UIDs and GIDs have been assigned sequentially. Often, several systems have assigned the UIDs and GIDs sequentially from 101 to different users in a completely uncoordinated manner. This entry maps the users on oscon to UIDs and GIDs starting at 1000. Another file might map the 100 to 200 entries of another client to UIDs and GIDs starting at 2000. A third file might map yet another client to 3000. This type of entry allows the server to coordinate UIDs and GIDs where no coordination exists. The last two lines map an individual user's UID and GID. This is less commonly required, but it is possible.
After defining the directories in the /etc/exports file, run the exportfs command to process the exports file and to build /var/lib/nfs/xtab. The xtab file contains information about the currently exported directories, and it is the file that mountd reads when processing client mount requests. To process all of the entries in the /etc/exports file, run exportfs with the -a command-line option:
# exportfs -a
This command, which exports everything in the exports file, is normally run during the boot from a startup script. To force changes in the /etc/exports file to take effect without rebooting the system, use the -r argument:
# exportfs -r
The -r switch synchronizes the contents of the exports file and the xtab file. Items that have been added to the exports file are added to the xtab file, and items that have been deleted are removed from xtab.
The exportfs command can export a directory that is not listed in the /etc/exports file. For example, to temporarily export /usr/local to the client fox with read/write permission, enter this command:
# exportfs fox:/usr/local -o rw
After the client has completed its work with the temporarily exported filesystem, the directory is removed from the export list with the -u option, as shown:
# exportfs -u fox:/usr/local
The -u option can be combined with the -a option to completely shut down all exports without terminating the NFS daemon:
# exportfs -ua
Once the server exports or shares the appropriate filesystems, the clients can mount and use those filesystems. The next section looks at how an NFS client system is configured.
Some basic information is required before you can decide which NFS directories to mount on your system. You need to know which servers are connected to your network and which directories are available from those servers. A directory cannot be mounted unless it is first exported by a server.
Your network administrator is a good source for this information. The administrator can tell you what systems are providing NFS service, what directories they are exporting, and what these directories contain. If you are the administrator of an NFS server, you should develop this type of information for your users. See Chapter 4 for advice on planning and distributing network information.
On Solaris and Linux systems, you can also obtain information about the shared directories directly from the servers by using the showmount command. The NFS servers are usually the same centrally supported systems that provide other services such as mail and DNS. Select a likely server and query it with the command showmount -e hostname. In response to this command, the server lists the directories that it exports and the conditions applied to their export.
For example, a showmount -e query to jerboas produces the following output:
% showmount -e jerboas export list for jerboas: /usr/man (everyone) /home/research rodent,crab,limulus,horseshoe /usr/local (everyone)
The export list shows the NFS directories exported by jerboas as well as who is allowed to access those directories. From this list, rodent's administrator may decide to mount any of the directories offered by jerboas. Our imaginary administrator decides to:
Mount /usr/man from jerboas instead of maintaining the manpages locally.
Mount /home/research to more easily share files with other systems in the research group.
Mount the centrally maintained programs in /usr/local.
These selections represent some of the most common motivations for mounting NFS directories:
Saving disk space
Sharing files with other systems
Maintaining common files centrally
The extent to which you use NFS is a personal choice. Some people prefer the greater personal control you get from keeping files locally, while others prefer the convenience offered by NFS. Your site may have guidelines for how NFS should be used, which directories should be mounted, and which files should be centrally maintained. Check with your network administrator if you're unsure about how NFS is used at your site.
A client must mount a shared directory before using it. "Mounting" the directory attaches it to the client's filesystem hierarchy. Only directories offered by the servers can be mounted, but any part of the offered directory, such as a subdirectory or a file, can be mounted.
NFS directories are mounted using the mount command. The general structure of the mount command is:
mount hostname:remote-directory local-directory
The hostname identifies an NFS server, and the remote-directory identifies all or part of a directory offered by that server. The mount command attaches that remote directory to the client's filesystem using the directory name provided for local-directory. The client's local directory, called the mount point, must be created before mount is executed. Once the mount is completed, files located in the remote directory can be accessed through the local directory exactly as if they were local files.
For example, assume that jerboas.wrotethebook.com is an NFS server and that it shares the files shown in the previous section. Further assume that the administrator of rodent wants to access the /home/research directory. The administrator simply creates a local /home/research directory and mounts the remote /home/research directory offered by jerboas on this newly created mount point:
# mkdir /home/research # mount jerboas:/home/research /home/research
In this example, the local system knows to mount an NFS filesystem because the remote directory is preceded by a hostname and NFS is the default network filesystem for this client. NFS is the most common default network filesystem. If your client system does not default to NFS, specify NFS directly on the mount command line. On a Solaris 8 system, the -F switch is used to identify the filesystem type:
# mount -F nfs jerboas:/home/research /home/research
On a Linux system the -t switch is used:
# mount -t nfs jerboas:/home/research /home/research
Once a remote directory is mounted, it stays attached to the local filesystem until it is explicitly dismounted or the local system reboots. To dismount a directory, use the umount command. On the umount command line, specify either the local or remote name of the directory that is to be dismounted. For example, the administrator of rodent can dismount the remote jerboas:/home/research filesystem from the local /home/research mount point, with either:
# umount /home/research
# umount jerboas:/home/research
Booting also dismounts NFS directories. Because systems frequently wish to mount the same filesystems every time they boot, Unix provides a system for automatically remounting after a boot.
Unix systems use the information provided in a special table to remount all types of filesystems, including NFS directories, after a system reboot. The table is a critical part of providing users consistent access to software and files, so care should be taken whenever it is modified. Two different files with two different formats are used for this purpose by the different flavors of Unix. Linux and BSD systems use the /etc/fstab file, and Solaris, our System V example, uses the /etc/vfstab file.
The format of the NFS entries in the Solaris vfstab file is:
filesystem - mountpoint nfs - yes options
The various fields in the entry must appear in the order shown and be separated by whitespace. The items not in italics (both dashes and the words nfs and yes) are keywords that must appear exactly as shown. filesystem is the name of the directory offered by the server, mountpoint is the pathname of the local mount point, and options are the mount options discussed below. A sample NFS vfstab entry is:
jerboas:/home/research - /home/research nfs - yes rw,soft
This entry mounts the NFS filesystem jerboas:/home/research on the local mount point /home/research. The filesystem is mounted with the rw and soft options set. We previously discussed the commonly used read/write (rw) and read-only (ro) options, and there are many more NFS options. The NFS mount options available on Solaris systems are:
If the filesystem is already mounted read-only, remount the filesystem as read/write.
If the server fails to respond, return an error and don't retry the request.
Defines the number of seconds to wait for a timeout before issuing an error.
If the server fails to respond, retry until it does respond. This is the default.
Do the retries in background mode, which allows the boot to proceed.
Do the retries in foreground mode. This option could hang the boot process while the mount is being retried. For this reason, fg is used primarily for debugging.
Allow a keyboard interrupt to kill a process that is hung waiting for the server to respond. Hard-mounted filesystems can become hung because the client retries forever, even if the server is down. This is a default.
Don't allow keyboard interrupts. In general, this is a bad idea.
Do not allow an executable stored on the mounted filesystem to run setuid. This improves security but may limit utility.
Cache directory attributes for no more than n seconds. The default is to hold cache values for a maximum of 60 seconds. Repeated requests for filesystem attributes is one of the leading contributors to NFS traffic. Caching this information helps to reduce the traffic.
Cache directory attributes for at least n seconds. The default is 30 seconds.
Cache file attributes for no more than n seconds. The default is 60 seconds.
Cache file attributes for at least n seconds. The default is 3 seconds.
Sets a single value for acdirmax, acdirmin, acregmax, and acregmin.
Use the group ID of the parent directory when creating new files. If this option is not set, the effective GID of the calling process is used.
Do not cache information. The default is to use caching, which can be specified with the ac option.
Identifies the IP port number used by the server.
Use POSIX standards for the filesystem. POSIX is a wide-ranging Unix interoperability standard that includes many standards for filesystems, such as the maximum length of filenames and how file locks are set.
Specifies the transport protocol that will be used by NFS.
Use the public file handle when connecting to the NFS server.
Use quota to enforce user quotas on this filesystem.
Do not use quota to enforce user quotas on this filesystem.
Defines the number of times NFS will retransmit when a connectionless transport protocol is used.
Defines the number of times a mount attempt will be retried. The default is to retry 10,000 times.
Defines the size of the read buffer as n bytes. The default for NFS version 3 is 32,768 bytes.
Specifies the type of security used for NFS transactions. The type values supported on the Solaris 8 mount command are the same as those listed for the share command: sys, dh, krb4, or none.
Sets the size of the write buffer to n bytes. The default is 32768 bytes for NFS version 3.
Specifies the version of NFS that should be used for this mount. By default, the system automatically selects the latest version supported by both the client and the server.
On the Solaris system, the filesystems defined in the vfstab file are mounted by a mountall command located in a startup file. On Linux systems, the startup file contains a mount command with the -a flag set, which causes Linux to mount all filesystems listed in fstab.
 Red Hat Linux uses a special script, /etc/init.d/netfs, just for mounting all of the different networked filesystems, which include NFS.
The format of NFS entries in the /etc/fstab file is:
filesystem mountpoint nfs options
The fields must appear in the order shown and must be separated by whitespace. The keyword nfs is required for NFS filesystems. filesystem is the name of the directory being mounted. mountpoint is the pathname of the local mount point. options are any of the Linux mount options.
Linux uses most of the same NFS mount options as Solaris. rsize, wsize, timeo, retrans, acregmin, acregmax, acdirmin, acdirmax, actimeo, retry, port, bg, fg, soft, hard, intr, nointr, ac, noac, and posix are all options that Linux has in common with Solaris. In addition to these, Linux uses:
Defines the port to be used by mountd.
Identifies the server running mountd.
Defines the RPC program number used by mountd on the remote host.
Defines the RPC version number used by mountd on the remote host.
Defines the RPC program number used by nfsd on the remote host.
Defines the RPC version number used by nfsd on the remote host.
Defines the maximum length of the filenames supported by the remote server.
Do not retrieve attributes when creating a file. The default is to retrieve the attributes, which can be specified with the cto option.
Specifies that NFS should use TCP as its transport protocol.
Specifies that NFS should use UDP as its transport protocol.
Prevents the system from starting lockd. The default is to run lockd, which can be requested with the lock option.
Finally, there are several options that are not specific to NFS and can be used on the mount command for any type of filesystem. Table 9-1 lists the common mount options used on Linux systems.
Use asynchronous file I/O, which acknowledges writes as soon as they are received to improve performance.
Mount when the -a option is used.
Allow character and block special devices on the filesystem.
Permit execution of files from the filesystem.
Don't mount with the -a option.
Don't allow character and block special devices on the filesystem.
Don't allow execution of files from the filesystem.
Don't allow programs stored on the filesystem to run setuid or setgid.
Only root can mount the filesystem.
Remount a mounted filesystem with new options.
Mount the filesystem read-only.
Mount the filesystem read/write.
Allow programs to run setuid or setgid.
Use synchronous filesystem I/O, which acknowledges writes only after they are written to disk to improve reliability.
Permit ordinary users to mount the filesystem.
Update inode access time for every access.
Do not update inode access time.
Set the rw, suid, dev, exec, auto, nouser, and async options.
A grep of fstab shows sample NFS entries.
 grep is used because the fstab file contains other information not related to NFS.
% grep nfs /etc/fstab jerboas:/usr/spool/mail /usr/spool/mail nfs rw 0 0 jerboas:/usr/man /usr/man nfs rw 0 0 jerboas:/home/research /home/research nfs rw 0 0
The grep shows that there are three NFS filesystems contained in the /etc/fstab file. The mount -a command in the boot script remounts these three directories every time the system boots.
The vfstab and fstab files are the most common methods used for mounting filesystems at boot time. There is another technique that automatically mounts NFS filesystems, but only when they are actually needed. It is called automounter.
An automounter is a feature available on most NFS clients. Two varieties of automounters are in widespread use: autofs and amd. The Automounter Filesystem (autofs) is the automounter implementation that comes with Solaris and Linux, and it is the implementation we cover in this section. Automounter Daemon (amd) is available for many Unix versions and is included with Linux but not with Solaris. To find out more about amd, see Linux NFS and Automounter Administration written by Erez Zadok, the amd maintainer. In this section, automounter and automounter daemon refer to the version of autofs that comes with Solaris 8.
The automounter configuration files are called maps. Three basic map types are used to define the automounter filesystem:
The configuration file read by automount. It lists all of the other maps that are used to define the autofs filesystem.
A configuration file that lists the mount points, pathnames, and options of filesystems that are to be mounted by the automounter daemon (automountd).
A configuration file that contains pathnames and "relative" mount points. The mount points are relative to a directory path declared in the master map. How indirect maps are used will become clear in the examples.
On Solaris systems the automounter daemon (automountd) and the automount command are started by the /etc/init.d/autofs script. The script is run with the start option to start automounter, i.e., autofs start. It is run with the stop option to shut down automounter. automount and automountd are two distinct, separate programs. automountd runs as a daemon and dynamically mounts filesystems when they are needed. automount processes the auto_master file to determine the filesystems that can be dynamically mounted.
To use automounter, first configure the /etc/auto_master file. Entries in the auto_master file have this format:
mount-point map-name options
The Solaris system comes with a default auto_master file preconfigured. Customize the file for your configuration. Comment out the +a