exports(4)
exports - list of directories being exported via NFS
As shipped in IRIX 6.5.22. Last changed in IRIX 6.5.22.
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 Linux clients. 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. 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. 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, offline and wsync options are specific to IRIX. FILES /etc/exports SEE ALSO exportfs(1M), mountd(1M), showmount(1M), netgroup(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).