Chapter 9. Local Network Services

9.1.2.1. The share command

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:

rw

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.

ro

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.

aclok

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.

anon=uid

Defines the UID used for users who do not provide a valid user ID.

index=file

Tells NFS to use a web-style index file instead of a directory listing for this filesystem.

log[=tag]

Enable logging. If an optional tag is specified, it must match a tag defined in the /etc/nfs/nfslog.conf file.

nosub

Do not allow clients to mount subdirectories. The default is sub, which allows subdirectories to be mounted.

nosuid

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.

public

Use the public file handle for this filesystem.

root=accesslist

This option allows the root users from the systems specified by the access list to have root access to the filesystem.

sec=type

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:

sys

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.

dh

Use Diffie-Hellman public key cryptography for authentication.

krb4

Use the Kerberos Version 4 for authentication.

none

Do not use authentication. When no authentication is used, all users access the filesystem as user nobody.

window=seconds

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:

hostname

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.

address

An IP address in dotted decimal format can be used.

netgroup

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.

.domain

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.

@network[/prefix]

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.

9.1.2.2. The /etc/exports file

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 [host(option)]...

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:

ro

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.

rw

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.[100] 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.

[100]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:

/home/alana  giant(all_squash,anonuid=1001,anongid=1001)

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:

/export/oscon oscon(map_static=/etc/nfs/oscon.map)

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.

9.1.2.3. The exportfs command

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.

9.1.3.1. The mount command

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

or:

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

9.1.3.2. The vfstab and fstab files

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:

remount

If the filesystem is already mounted read-only, remount the filesystem as read/write.

soft

If the server fails to respond, return an error and don't retry the request.

timeo=n

Defines the number of seconds to wait for a timeout before issuing an error.

hard

If the server fails to respond, retry until it does respond. This is the default.

bg

Do the retries in background mode, which allows the boot to proceed.

fg

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.

intr

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.

nointr

Don't allow keyboard interrupts. In general, this is a bad idea.

nosuid

Do not allow an executable stored on the mounted filesystem to run setuid. This improves security but may limit utility.

acdirmax=n

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.

acdirmin=n

Cache directory attributes for at least n seconds. The default is 30 seconds.

acregmax=n

Cache file attributes for no more than n seconds. The default is 60 seconds.

acregmin=n

Cache file attributes for at least n seconds. The default is 3 seconds.

actimeo=n

Sets a single value for acdirmax, acdirmin, acregmax, and acregmin.

grpid

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.

noac

Do not cache information. The default is to use caching, which can be specified with the ac option.

port=n

Identifies the IP port number used by the server.

posix

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.

proto=protocol

Specifies the transport protocol that will be used by NFS.

public

Use the public file handle when connecting to the NFS server.

quota

Use quota to enforce user quotas on this filesystem.

noquota

Do not use quota to enforce user quotas on this filesystem.

retrans=n

Defines the number of times NFS will retransmit when a connectionless transport protocol is used.

retry=n

Defines the number of times a mount attempt will be retried. The default is to retry 10,000 times.

rsize=n

Defines the size of the read buffer as n bytes. The default for NFS version 3 is 32,768 bytes.

sec=type

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.

wsize=n

Sets the size of the write buffer to n bytes. The default is 32768 bytes for NFS version 3.

vers=version

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.[101]

[101]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:

mountport=n

Defines the port to be used by mountd.

mounthost=name

Identifies the server running mountd.

mountprog=n

Defines the RPC program number used by mountd on the remote host.

mountvers=n

Defines the RPC version number used by mountd on the remote host.

nfsprog=n

Defines the RPC program number used by nfsd on the remote host.

nfsvers=n

Defines the RPC version number used by nfsd on the remote host.

namlen=n

Defines the maximum length of the filenames supported by the remote server.

nocto

Do not retrieve attributes when creating a file. The default is to retrieve the attributes, which can be specified with the cto option.

tcp

Specifies that NFS should use TCP as its transport protocol.

udp

Specifies that NFS should use UDP as its transport protocol.

nolock

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.

Table 9-1. Common mount options

Option	Function
async	Use asynchronous file I/O, which acknowledges writes as soon as they are received to improve performance.
auto	Mount when the -a option is used.
dev	Allow character and block special devices on the filesystem.
exec	Permit execution of files from the filesystem.
noauto	Don't mount with the -a option.
nodev	Don't allow character and block special devices on the filesystem.
noexec	Don't allow execution of files from the filesystem.
nosuid	Don't allow programs stored on the filesystem to run setuid or setgid.
nouser	Only root can mount the filesystem.
remount	Remount a mounted filesystem with new options.
ro	Mount the filesystem read-only.
rw	Mount the filesystem read/write.
suid	Allow programs to run setuid or setgid.
sync	Use synchronous filesystem I/O, which acknowledges writes only after they are written to disk to improve reliability.
user	Permit ordinary users to mount the filesystem.
atime	Update inode access time for every access.
noatime	Do not update inode access time.
defaults	Set the rw, suid, dev, exec, auto, nouser, and async options.

A grep of fstab shows sample NFS entries.[102]

[102]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.