exports - NFS file systems being exported (for Kernel
based NFS)
SYNOPSIS
/etc/exports
DESCRIPTION
The file /etc/exports serves as the access control list
for file systems which may be exported to NFS clients. It
is used by exportfs(8) to give information to mountd(8)
and to the kernel based NFS file server daemon nfsd(8).
The file format is similar to the SunOS exports file. Each
line contains an export point and a whitespace-separated
list of clients allowed to mount the file system at that
point. Each listed client may be immediately followed by a
parenthesized, comma-separated list of export options for
that client. No whitespace is permitted between a client
and its option list.
Blank lines are ignored. A pound sign ("#") introduces a
comment to the end of the line. Entries may be continued
across newlines using a backslash. If an export name con
tains spaces it should be quoted using double quotes. You
can also specify spaces or other unusual character in the
export name using a backslash followed by the character
code as three octal digits.
Machine Name Formats
NFS clients may be specified in a number of ways:
single host
This is the most common format. You may specify a
host either by an abbreviated name recognized be
the resolver, the fully qualified domain name, or
an IP address.
netgroups
NIS netgroups may be given as @group. Only the
host part of each netgroup members is consider in
checking for membership. Empty host parts or those
containing a single dash (-) are ignored.
wildcards
Machine names may contain the wildcard characters *
and ?. This can be used to make the exports file
more compact; for instance, *.cs.foo.edu matches
all hosts in the domain cs.foo.edu. However, these
wildcard characters do not match the dots in a
domain name, so the above pattern does not include
hosts such as a.b.cs.foo.edu.
You can also export directories to all hosts on an
IP (sub-) network simultaneously. This is done by
specifying an IP address and netmask pair as
address/netmask where the netmask can be specified
in dotted-decimal format, or as a contiguous mask
length (for example, either `/255.255.252.0' or
`/22' appended to the network base address result
in identical subnetworks with 10 bits of host).
Wildcard characters generally do not work on IP
addresses, though they may work by accident when
reverse DNS lookups fail.
General Options
exportfs understands the following export options:
secure This option requires that requests originate on an
internet port less than IPPORT_RESERVED (1024).
This option is on by default. To turn it off, spec
ify insecure.
rw Allow both read and write requests on this NFS vol
ume. The default is to disallow any request which
changes the filesystem. This can also be made
explicit by using the ro option.
async This option allows the NFS server to violate the
NFS protocol and reply to requests before any
changes made by that request have been committed to
stable storage (e.g. disc drive).
Using this option usually improves performance, but
at the cost that an unclean server restart (i.e. a
crash) can cause data to be lost or corrupted.
In releases of nfs-utils upto and including 1.0.0,
this option was the default. In this and future
releases, sync is the default, and async must be
explicit requested if needed. To help make system
adminstrators aware of this change, 'exportfs' will
issue a warning if neither sync nor async is speci
fied.
no_wdelay
This option has no effect if async is also set.
The NFS server will normally delay committing a
write request to disc slightly if it suspects that
another related write request may be in progress or
may arrive soon. This allows multiple write
requests to be committed to disc with the one oper
ation which can improve performance. If an NFS
server received mainly small unrelated requests,
this behaviour could actually reduce performance,
default can be explicitly requested with the wdelay
option.
nohide This option is based on the option of the same name
provided in IRIX NFS. Normally, if a server
exports two filesystems one of which is mounted on
the other, then the client will have to mount both
filesystems explicitly to get access to them. If
it just mounts the parent, it will see an empty
directory at the place where the other filesystem
is mounted. That filesystem is "hidden".
Setting the nohide option on a filesystem causes it
not to be hidden, and an appropriately authorised
client will be able to move from the parent to that
filesystem without noticing the change.
However, some NFS clients do not cope well with
this situation as, for instance, it is then possi
ble for two files in the one apparent filesystem to
have the same inode number.
The nohide option is currently only effective on
single host exports. It does not work reliably
with netgroup, subnet, or wildcard exports.
This option can be very useful in some situations,
but it should be used with due care, and only after
confirming that the client system copes with the
situation effectively.
The option can be explicitly disabled with hide.
no_subtree_check
This option disables subtree checking, which has
mild security implications, but can improve relia
bility is some circumstances.
If a subdirectory of a filesystem is exported, but
the whole filesystem isn't then whenever a NFS
request arrives, the server must check not only
that the accessed file is in the appropriate
filesystem (which is easy) but also that it is in
the exported tree (which is harder). This check is
called the subtree_check.
In order to perform this check, the server must
include some information about the location of the
file in the "filehandle" that is given to the
client. This can cause problems with accessing
files that are renamed while a client has them open
(though in many simple cases it will still work).
files inside directories to which only root has
access can only be accessed if the filesystem is
exported with no_root_squash (see below), even the
file itself allows more general access.
As a general guide, a home directory filesystem,
which is normally exported at the root and may see
lots of file renames, should be exported with sub
tree checking disabled. A filesystem which is
mostly readonly, and at least doesn't see many file
renames (e.g. /usr or /var) and for which subdirec
tories may be exported, should probably be exported
with subtree checks enabled.
The default of having subtree checks enabled, can
be explicitly requested with subtree_check.
insecure_locks
no_auth_nlm
This option (the two names are synonymous) tells
the NFS server not to require authentication of
locking requests (i.e. requests which use the NLM
protocol). Normally the NFS server will require a
lock request to hold a credential for a user who
has read access to the file. With this flag no
access checks will be performed.
Early NFS client implementations did not send cre
dentials with lock requests, and many current NFS
clients still exist which are based on the old
implementations. Use this flag if you find that
you can only lock files which are world readable.
The default behaviour of requiring authentication
for NLM requests can be explicitly requested with
either of the synonymous auth_nlm, or secure_locks.
User ID Mapping
nfsd bases its access control to files on the server
machine on the uid and gid provided in each NFS RPC
request. The normal behavior a user would expect is that
she can access her files on the server just as she would
on a normal file system. This requires that the same uids
and gids are used on the client and the server machine.
This is not always true, nor is it always desirable.
Very often, it is not desirable that the root user on a
client machine is also treated as root when accessing
files on the NFS server. To this end, uid 0 is normally
mapped to a different id: the so-called anonymous or
ing') is the default, and can be turned off with
no_root_squash.
By default, exportfs chooses a uid and gid of -2 (i.e.
65534) for squashed access. These values can also be over
ridden by the anonuid and anongid options. Finally, you
can map all user requests to the anonymous uid by specify
ing the all_squash option.
Here's the complete list of mapping options:
root_squash
Map requests from uid/gid 0 to the anonymous
uid/gid. Note that this does not apply to any other
uids that might be equally sensitive, such as user
bin.
no_root_squash
Turn off root squashing. This option is mainly use
ful for diskless clients.
all_squash
Map all uids and gids to the anonymous user. Useful
for NFS-exported public FTP directories, news spool
directories, etc. The opposite option is
no_all_squash, which is the default setting.
anonuid and anongid
These options explicitly set the uid and gid of the
anonymous account. This option is primarily useful
for PC/NFS clients, where you might want all
requests appear to be from one user. As an example,
consider the export entry for /home/joe in the
example section below, which maps all requests to
uid 150 (which is supposedly that of user joe).
EXAMPLE
# sample /etc/exports file
/ master(rw) trusty(rw,no_root_squash)
/projects proj*.local.domain(rw)
/usr *.local.domain(ro) @trusted(rw)
/home/joe pc001(rw,all_squash,anonuid=150,anongid=100)
/pub (ro,insecure,all_squash)
The first line exports the entire filesystem to machines
master and trusty. In addition to write access, all uid
squashing is turned off for host trusty. The second and
third entry show examples for wildcard hostnames and net
groups (this is the entry `@trusted'). The fourth line
shows the entry for the PC/NFS client discussed above.
Line 5 exports the public FTP directory to every host in
the world, executing all requests under the nobody
clients with NFS implementations that don't use a reserved
port for NFS.
FILES
/etc/exports
Man(1) output converted with
man2html