• Choose a category
• All
• Classic-Fiction

Several options modify the way a filesystem is exported to the network:

rw

Permits NFS clients to read from or write to the filesystem. This option is the default; i.e., if none of rw, ro, ro=client_list, or rw=client_list are specified, then read/write access to the world is granted.

ro

Prevents NFS clients from writing to the filesystem. Read-only restrictions are enforced when a client performs an operation on an NFS filesystem: if the client has mounted the filesystem with read and write permissions, but the server specified ro when exporting it, any attempt by the client to write to the filesystem will fail, with "Read-only filesystem" or "Permission denied" messages.

rw=client_list

Limits the set of hosts that may write to the filesystem to the NFS clients identified in client_list.

A client_list has the form of a colon-separated list of components, such that a component is one of the following:

hostname

The hostname of the NFS client.

netgroup

The NIS directory services support the concept of a set of hostnames named collectively as a netgroup. See Chapter 7 for a description on how to set up netgroups under NIS.

DNS domain

An Internet Domain Name Service domain is indicated by a preceding dot. For example:

# share -o rw=.widget.com /export2

grants access to any host in the widget.com domain. In order for this to work, the NFS server must be using DNS as its primary directory service ahead of NIS (see Chapter 4).

netmask

A netmask is indicated by a preceding at-sign (@) and possibly by a suffix with a slash and length to indicate the number of bits in the netmask. Examples will help here:

# share -o rw=@129.100.0.0 /export

# share -o rw=@193.150.145.63/27 /export2

The notation of four decimal values separated by periods is known as a dotted quad.

In the first example, any client with an Internet Protocol (IP) address such that its first two octets are 129 and 100 (in decimal), will get read/write access to /export.

In the second example, a client with an address such that the first 27 bits match the first 27 bits of 193.150.145.63 will get read/write access. The notation 193.150.145.63/27 is an example of classless addressing, which was previously discussed in Section 1.3.3.

So in the second example, a client with an address of 193.150.145.33would get access, but another client with the address 193.150.145.128would not. Chapter 6 clarifies this.

Table 6-2. Netmask matching

Client Address dotted quad

Client Address hexadecimal

Netmask dotted quad

Netmask hexadecimal

Access?

193.150.145.33

0xc1969121

193.150.145.63/27

0xc1969120

Yes

193.150.145.128

0xc1969180

193.150.145.63/27

0xc1969120

No

-component

Each component in the client_list can be prefixed with a minus sign (-) to offer negative matching. This indicates that the component should not get access, even if it is included in another component in the client_list. For example:

# share -o rw=-wrench.widget.com:.widget.com /dir

would exclude the host wrench in the domain widget.com, but would give access to all other hosts in the domain widget.com. Note that order matters. If you did this:

# share -o rw=.widget.com:-wrench.widget.com /dir

host wrench would not be denied access. In other words, the NFS server will stop processing the client_list once it gets a positive or negative match.

ro=client_list

Limits the set of hosts that may read (but not write to) the filesystem to the NFS clients identified in client_list. The form of client_list is the same as that described for the rw=client_list option.

anon=uid

Maps anonymous, or unknown, users to the user identifier uid. Anonymous users are those that do not present valid credentials in their NFS requests. Note that an anonymous user is not one that does not appear in the server's password file or NIS passwd map. If no credentials are included with the NFS request, it is treated as an anonymous request. NFS clients can submit requests from