Now we'll look at how we configure the NFS server. Specifically, we'll look at how we tell the NFS server what filesystems it should make available for mounting, and the various parameters that control the access clients will have to the filesystem. The server determines the type of access that is allowed to the server's files. The /etc/exports file lists the filesystems that the server will make available for clients to mount and use.
By default, rpc.mountd disallows all directory mounts, which is a rather sensible attitude. If you wish to permit one or more hosts to NFS-mount a directory, you must export it, that is, specify it in the exports file. A sample file may look like this:
# exports file for vlager /home vale(rw) vstout(rw) vlight(rw) /usr/X11R6 vale(ro) vstout(ro) vlight(ro) /usr/TeX vale(ro) vstout(ro) vlight(ro) / vale(rw,no_root_squash) /home/ftp (ro) |
Each line defines a directory and the hosts that are allowed to mount it. A hostname is usually a fully qualified domain name but may additionally contain the * and ? wildcards, which act the way they do with the Bourne shell. For instance, lab*.foo.com matches lab01.foo.com as well as laboratory.foo.com. The host may also be specified using an IP address range in the form address/netmask. If no hostname is given, as with the /home/ftp directory in the previous example, any host matches and is allowed to mount the directory.
When checking a client host against the exports file, rpx.mountd looks up the client's hostname using the gethostbyaddr call. With DNS, this call returns the client's canonical hostname, so you must make sure not to use aliases in exports. In an NIS environment the returned name is the first match from the hosts database, and with neither DNS or NIS, the returned name is the first hostname found in the hosts file that matches the client's address.
The hostname is followed by an optional comma-separated list of flags, enclosed in parentheses. Some of the values these flags may take are:
This flag insists that requests be made from a reserved source port, i.e., one that is less than 1,024. This flag is set by default.
This flag reverses the effect of the secure flag.
This flag causes the NFS mount to be read-only. This flag is enabled by default.
This option mounts file hierarchy read-write.
This security feature denies the superusers on the specified hosts any special access rights by mapping requests from uid 0 on the client to the uid 65534 (that is, -2) on the server. This uid should be associated with the user nobody.
Don't map requests from uid 0. This option is on by default, so superusers have superuser access to your system's exported directories.
This option converts absolute symbolic links (where the link contents start with a slash) into relative links. This option makes sense only when a host's entire filesystem is mounted; otherwise, some of the links might point to nowhere, or even worse, to files they were never meant to point to. This option is on by default.
This option leaves all symbolic links as they are (the normal behavior for Sun-supplied NFS servers).
This option tells the server to assume that the client uses the same uids and gids as the server. This option is on by default.
This option tells the NFS server to assume that client and server do not share the same uid/gid space. rpc.nfsd then builds a list that maps IDs between client and server by querying the client's rpc.ugidd daemon.
This option allows you to specify the name of a file that contains a static map of uids and gids. For example, map_static=/etc/nfs/vlight.map would specify the /etc/nfs/vlight.map file as a uid/gid map. The syntax of the map file is described in the exports(5) manual page.
This option causes the NIS server to do the uid and gid mapping.
These options allow you to specify the uid and gid of the anonymous account. This is useful if you have a volume exported for public mounts.
Any error in parsing the exports file is reported to syslogd 's daemon facility at level notice whenever rpc.nfsd or rpc.mountd is started up.
Note that hostnames are obtained from the client's IP address by reverse mapping, so the resolver must be configured properly. If you use BIND and are very security conscious, you should enable spoof checking in your host.conf file. We discuss these topics in Chapter 6.