• Choose a category
• All
• Classic-Fiction

share -F nfs -o rw=-@128.138.243/24:.cs.colorado.edu /users

exports /users read-write to all hosts in the cs.colorado.edu DNS domain except for hosts on the 128.138.243 network.

It’s possible to export a directory read-only to some clients and read-write to others: just include both the rw= and ro= options.

The share(1M) man page documents a few basic NFS options. For a complete list, refer to the share_nfs(1M) man page.

The exportfs command and the exports file (HP-UX, Red Hat, FreeBSD)

The exports file consists of a list of exported directories in the leftmost column, followed by lists of associated options and attributes. For example, the HP-UX exports

/chimchim/users -access=band:moon,root=band

/usr/share/man -access=xorasaurus:rastadon:moon,ro

permit /chimchim/users to be mounted by the machines band and moon, and allow root access to the filesystem from band.3

In addition, they let /usr/share/man be mounted by xorasaurus, rastadon, and moon.

Filesystems that are listed in the exports file without a specific set of hosts are usually mountable by all machines. This is a sizable security hole.

Some NFS implementations limit lines in the exports file to 1,024 characters. That limit can come awfully fast, especially when you’re using fully qualified domain names. Netgroups and network masks can help to keep line lengths manageable on the machines that support them.

The exact options and syntax used in the exports file vary greatly by system, though there is a certain thematic similarity. The following sections describe the formats for HP-UX, Red Hat Linux, and FreeBSD; as always, be sure to check the man page.

Exports under HP-UX

HP-UX has the most “classic” exports format of our four example systems. The permissible options (shown in Table 17.5) are actually quite similar to those understood by the Solaris share command. However, there are some subtle differences. For example, the option

rw=anchor.cs.colorado.edu:moet.cs.colorado.edu

Table 17.5 Common export options for HP-UX

on Solaris means to export the directory read-write with access only by the listed hosts. Under HP-UX, this option allows the entire world to mount the directory read-only. Gotcha! Under HP-UX, you must use the access clause to restrict mounting to a specified list of clients:

rw,access=anchor.cs.colorado.edu:moet.cs.colorado.edu

Read-write exporting is the default, so the rw clause could actually be eliminated. It doesn’t hurt to say it explicitly, however.

Each line in an HP-UX exports file should consist of a directory path, whitespace, and then a dash followed by a comma-separated list of options. See the lines on the previous page for some simple examples.

In Table 17.5, a list consists of a colon-separated series of hostnames and netgroup names. (See page 522 for more information about netgroups.)

Remember to run exportfs -a after changing the /etc/exports file.

Exports under Red Hat Linux

In Red Hat’s exports file, the clients that may access a given filesystem are presented in a whitespace-separated list. Each client is followed immediately by a parenthesized list of comma-separated options. Lines can be continued with a backslash.

Here’s what the format looks like:

/chimchim/users band(rw,no_root_squash) moon(rw)

/usr/share/man *.cs.colorado.edu(ro)

There is no way to list multiple clients for a single set of options, although certain types of “client” refer to multiple hosts. Table 17.6 lists the four types of client specifications that can appear in a Red Hat exports file.4

Table 17.6 Client specifications under Red Hat

a. Fully qualified domain names

Table 17.7 describes the most common export options understood by Red Hat.

Table 17.7 Common export options for Red Hat

a. Unlike most operating systems, Red Hat allows UIDs other than root to be collapsed. Look up the squash_uids and all_squash options for more details.

Red Hat’s NFS software has the unusual feature of allowing subdirectories