exports(4)                                                          exports(4)


NAME
     exports - list of directories being exported via NFS

SYNOPSIS
     /etc/exports

DESCRIPTION
     The file /etc/exports lists the directories that are being exported to
     NFS clients. It is created by the system administrator using a text
     editor. It is processed by exportfs(1M) at system startup and every time
     another entry is added to or removed from the list of exported
     directories. Processed content of this file is written to /etc/xtab file
     which is used by the mount request daemon, mountd(1M), each time a mount
     request is received.  exportfs should be re-executed after making changes
     to the file.

     Each entry in the file consists of a left justified directory name
     followed by the whitespace-separated list of netgroup(4) or machine names
     allowed to remote mount this directory followed by the list of options
     (see EXPORT OPTIONS below).

     A ``#'' anywhere in the file indicates a comment extending to the end of
     the line on which it appears.  A backslash ``\'' at the end of a line
     permits splitting long lines into shorter ones.  When splitting the
     options across multiple lines, the character immediately preceeding the
     backslash must be one of ``-'', ``='', ``:'', or ``,''.  Also, no
     whitespace may follow the backslash nor preceed the first character of
     the next line.

EXPORT OPTIONS
     The start of the option list is indicated by a hyphen. Multiple options
     are separated by commas. The default options are rw,anon=nobody.  The
     following options are supported:

     ro        Export the directory read-only. If not specified, the directory
               is exported read-write.

     rw=access_list
               Export the directory read-mostly. Read-mostly means exported
               read-only to most machines, but read-write to those hosts which
               match access_list specification (see ACCESS LIST below). If no
               hosts are specified, the directory is exported read-write to
               all.

     anon=uid  If a request comes from a host for uid 0 (typically ``root'')
               or from a host using null authentication, use uid as the
               effective user ID.  uid can be either a name or an integer user
               ID from /etc/passwd.  The default value for this option is
               ``nobody'' (uid -2).  Because uid 0 permits access to files
               regardless of permission and ownership, NFS servers change uid
               0 to the anonymous uid by default.  Use the root option to
               permit accesses from hosts using uid 0.  Setting the value of


               uid to -1 disables accesses from unknown users or from root on
               hosts not included in the root option.

     root=access_list
               Give root access only to the root (uid 0) users from a host,
               which matches the access_list specification (see ACCESS LIST
               below). The default is for no hosts to be granted root access.

     access=access_list
               Give access only to hosts which match the access_list
               specification. The default is to give access to any host, i.e.
               if no access option is specified, any host can mount an
               exported directory but the privilege levels will be decided
               based on root and rw options.

               Adding entries to the access_list for this option is similar to
               specifying the names between the exported directory name and
               the start of the option list, e.g.

                    /usr    bonnie clyde -ro

               has the same effect as

                    /usr    -ro,access=bonnie:clyde

               Please note that if an access option is used, a host which
               matches access_list specifications for root or rw options will
               be allowed access in addition to hosts which match access_list
               specification for this option, e.g. the following entry

                    /    -ro,access=foo,rw=bar,root=baz

               would give read-only access to host foo, read-write access to
               host bar and read-only and root access to host baz.  Access
               from host mumble will be denied.

     nohide    Allows a client who mounts this entry's parent filesystem to
               access files in this filesystem.  This is ``off'' by default,
               preventing a client who mounts this entry's parent filesystem
               from accessing files in this filesystem.  Clients who mount a
               filesystem containing a hidden filesystem access the directory
               on which the hidden child is mounted, not the child
               filesystem's root directory.  Be aware that using this option
               introduces a violation of RFC 1094, RFC 1813, and the XNFS
               specification.  Using this option may cause the server not to
               interoperate properly with non-IRIX clients, particularly older
               Linux clients.

               This option is applicable only if exported entry is a non-root
               mountpoint.  Starting from IRIX 6.5.29 exportfs(1M) will issue
               a warning and ignore nohide option if exported entry is either
               the root directory or is not a mountpoint.


     wsync     Causes all NFSv2 writes to this filesystem to be performed
               synchronously.  With this option, the server waits until
               written data is safely stored on a magnetic disk or other non-
               volatile medium before sending a positive response to the
               client.  Without this option, the server performs delayed
               writes (it responds positively to the client, then writes the
               data at its convenience or when a sync(2) is executed).
               Delaying writes provides a great performance boost, but also
               introduces the risk of losing data if the server crashes after
               the response but before the data is stored.  Use the wsync
               option if this risk is unacceptable.

     async     Causes all NFS writes to be performed asynchronously even if
               client requests synchronous write behaviour - the server will
               always perform delayed writes but will reply as if the data has
               been written to disk thus eliminating the need for a separate
               commit operations.

               Using this option can result in significant performance
               improvements but could lead to a data loss or corruption in the
               case of server crash.

     32bitclients
               Causes the server to mask off the high order 32 bits of
               directory cookies in NFS version 3 directory operations.  This
               option may be required when clients run 32-bit operating
               systems that assume the entire cookie is contained in 32 bits
               and reject responses containing version 3 cookies with high
               bits on.  IRIX 5.3 and Solaris 2.5 are examples of 32-bit
               operating systems with this behavior, which produces error
               messages like "Cannot decode response" on directory operations.
               XFS filesystems on the server can generate cookies with high
               bits on.  Exporting filesystems with the 32bitclients option
               causes these bits to be masked and prevents error messages.

     fsid=id   This allows the administrator to set the fsid value that will
               be returned in the fsid field of the attributes returned to the
               client.  This number is arbitrary but must uniquely identify
               the exported file system.  The purpose of this option is
               twofold.  First it provides a mechanism by which FailSafe can
               assign unique identifiers to exported file systems which may be
               failed over.  This identifier can be the same on all nodes of
               the cluster.  Secondly, it provides a way for administrators to
               work around NFS clients written to interpret and in some cases
               place restrictions on the fsid value returned in the
               attributes.  If this option is used for this second purpose, it
               should not be used in conjunction with the nohide option, and
               the option should be used for all exported file systems.  It is
               important to note that this option only affects the fsid
               contained in the file attributes.  File handles are constructed
               differently and do not use the fsid value in the file
               attributes.


     noxattr   Tell the NFS client that this filesystem does not support
               extended attributes. If doxattr option is specified when the
               filesystem is mounted, the client can be trusted to properly
               handle extended attributes.  Otherwise, when the client tries
               to retrieve or set extended attributes, the operation will not
               be supported.

     offline   Mark exported entry as being offline. All MOUNT, NFS, NLM and
               XATTR calls which would require access to such entry would be
               ignored without any errors. This option is used by Failsafe to
               aid resource failover.

     nomknod   Reject attempts to create a character or a block device node.
               Note that creation of named pipes or sockets is unaffected by
               this option.

     sec=mode[:mode]...
               Client must use one of the specified modes in the list to gain
               full access to the exported entity, any UIDs from a client
               which use a mode which is not on the list will be mapped to
               nobody.  If no sec option is specified, the default is the
               equivalent of using sec=sys which would use AUTH_UNIX.

               The supported modes are defined in nfssec.conf(4).

     no_auth_nlm
               Allow anonymous access to NLM (aka lockd) functionality -
               normally the client is expected to use the same RPC
               authentication mechanism with NLM as it is using with other NFS
               traffic. Some old NLM implementations particularly those which
               were using user-space lock manager process did not send user
               credentials with NLM calls which in combination with anon=-1
               meant that such calls were rejected by the server.

               By using this option server administrator can exempt NLM calls
               from obeying the rules for anon=-1. If both no_auth_nlm and
               anon=-1 are set then NLM calls with no user credentials (i.e.
               calls with AUTH_NONE) or calls with user ID of 0(zero) which
               are subject to ''root squashing'' will be processed by
               assigning user ID of nobody to the caller and performing
               standard permission checks.

               PLEASE NOTE that using no_auth_nlm compromises security of the
               server and therefore shall be used with care.

     directio=blocksz
               Instruct the server to attempt to do direct I/O if possible -
               any write request which is multiple of block size and is
               suitably aligned will be done directly to disk instead of going
               via the buffer cache.


               The block size for direct I/O is is calculated as two to the
               power of blocksz multiplied by 8192, e.g. blocksz=1 will
               attempt to do direct I/O for blocks of multiple of 16384 bytes,
               blocksz=2 - 32768, blocksz=3 - 65536 and up-to blocksz=15 which
               is equivalent of direct IO of blocks of 268435456 bytes or 256
               MiB.

     iponly    This is the tag used to notify rpc.mountd(1M) that all elements
               of the access lists are using network format. It is added
               automatically by exportfs(1M) and can be used by rpc.mountd(1M)
               to avoid doing reverse name lookup to check the access rights
               for a client.

               This is not an option which can be used in exports file or
               passed to exportfs(1M) command but it can appear amongst the
               options in the xtab file or in the output of exportfs(1M) or
               showmount(1M) commands. This tag first appeared in Irix 6.5.25.

     mandlock  Irix does not support mandatory file locking (see chmod(2) for
               details) over NFS. Prior to 6.5.28 this restriction was not
               enforced.  Starting from 6.5.28 if mandatory locking is enabled
               on a file then NFS server would return EACCES for any read or
               write request to the file.  This option can be used to return
               to pre-6.5.28 behaviour.

               PLEASE NOTE accessing files which have use mandatory locking
               over NFS could lead to infinite loop on a client.

ACCESS LIST
     The access_list is a colon-separated list whose components may be any
     number of the following:

     hostname  A name of a single host. The hostname in the access_list should
               match the name returned for the reverse hostname lookup, e.g.
               if a host is identified by an IP address, the primary name
               returned by gethostbyaddr should be used.

     netgroup  A netgroup name. Any host which is a member of a netgroup will
               match the netgroup element of an access_list.

               Normally an unadorned name is looked up first as a netgroup and
               then second as a hostname. By adding the optional percent sign
               (%) prefix to the netgroup names the second lookup is avoided.

               Please note that similar to the hostname entry, the names for
               hosts in the netgroup must match the primary names, returned
               for the reverse hostname lookup.

     network   An entry, which starts with an at-sign (@), is interpreted as a
               network specification. A host with IP address which matches a
               network specification will match a network entry in an
               access_list.


               The network specification consists of an IP network address in
               dotted notation and a netmask. The length of netmask can be
               either specified explicitly by adding the slash (/) sign
               followed by the number of valid bits in the netmask after the
               network address or it can be deduced from the network address
               by assuming that all zero octets at the end of the network
               address must be masked, e.g. the network specification

                    @128.167.58

               would have the netmask 255.255.255.0 and it would match the
               host with the IP address 128.167.58.40,  but not the host with
               IP address 128.167.59.1.  On the other hand, the network
               specification

                    @128.167.58.40/20

               would have the netmask 255.255.240.0 and would match both hosts
               from the previous example.

               An entry which matches single host's IP address is entered as
               @A.B.C.D, e.g.  @128.167.58.123.

     domain name suffix
               An entry, which start with dot (.), is interpreted as a domain
               name suffix and would match any host whose primary name has the
               same domain name suffix.   For example,

                    .sgi.com

               would match any host which primary name ends with sgi.com. A
               single dot matches any name, which does not have a domain
               component.

               The domain name suffix is only meaningful for the reverse
               hostname lookups which have a domain components, such as DNS.

     A minus prefix (-) of an element in an access_list denies access from a
     host which matches such element. Because access_list is searched
     sequentially until a match is found, the order in which elements appear
     in the list is important. For example, the access list

          @128.167.58:-www.sgi.com

     would allow access from any host in 128.167.58 subnet, including
     www.sgi.com, but

          -www.sgi.com:@128.167.58

     would prevent access from www.sgi.com while allowing access from other
     hosts in 128.167.58 subnet.


EXAMPLES
          /usr/local               # export to the world
          /usr      clients        # export to my clients
          /usr2     bonnie clyde   # export to only these machines
          /usr3     -anon=guest    # map client root & anonymous to guest
          /         -ro            # export the root filesystem
          /usr      -ro,nohide     # export all local filesystems read-only
          /ng       -ro,access=%groupA:groupB     # Two groups - A and B
          /nofoos   -ro,\
                    access=-foo.bar.com:.bar.com  # exclude foo, but allow other
          /d/local/src   \
                    -rw,anon=guest,root=bonnie    # multi-line example

     Exporting all your machine's local filesystems requires enumerating all
     local mount points and using nohide for filesystem other than root:

          /         -ro
          /usr      -ro,nohide
          /d        -ro,nohide


NOTE
     The nohide, noxattr, nomknod, offline and wsync options are specific to
     IRIX.

FILES
     /etc/exports

SEE ALSO
     exportfs(1M), mountd(1M), showmount(1M), netgroup(4), nfssec.conf(4),
     passwd(4).

WARNINGS
     You cannot export a directory that is either a parent- or a sub-directory
     of one that is currently exported and within the same filesystem.  It
     would be illegal, for example, to export both /usr and /usr/local if both
     directories resided in the same disk partition.

     While there is no hard-coded maximum length, extremely long export lists
     (hundreds of hosts or netgroups for a single exported directory) may
     cause mount requests for that exported directory to time out.

     In the Trusted IRIX environment filesystems should not be exported to
     non-Trusted clients. Trix clients should be explicitly defined when
     exporting (see examples).

     When new access list elements (see ACCESS LIST section) have been added
     in 6.5.21 an ambiguity has been created where a netgroup name which
     starts with a reserved character could be interpreted as a domain name
     suffix or a network address or a negated entry.  To preserve backward
     compatibility with pre-6.5.21 semantic each element of access list is
     tested as if it was a netgroup name first and if a netgroup is found, the


     element is treated as a netgroup. If the name starts with any of the
     special symbols, such as dot (.), at-sign (@) or minus (-), the warning
     message is printed.

     Client access control is done by performing the reverse, i.e. from
     address to hostname, name lookup and matching the names against the list
     of names saved while exporting an entry. To minimize the risk of false
     negative matches it is important to make sure that the hostnames used
     either as the elements in an access list or embedded in the netgroups
     have the same format as the names returned from a reverse name lookup. In
     most cases using fully qualified domain names is the most appropriate
     format.  To minimize the chance of name mismatches, exportfs(1M) would
     perform forward, i.e. from name to address, name lookup for all the
     hostname entries in an access list and will record all the names returned
     by the naming system for a host to be used for matching.


                                                                        Page 8