1.\" Copyright (c) 1989, 1991, 1993 2.\" The Regents of the University of California. All rights reserved. 3.\" 4.\" %sccs.include.redist.roff% 5.\" 6.\" @(#)exports.5 8.3 (Berkeley) 03/29/95 7.\" 8.Dd 9.Dt EXPORTS 5 10.Os 11.Sh NAME 12.Nm exports 13.Nd define remote mount points for 14.Tn NFS 15mount requests 16.Sh SYNOPSIS 17.Nm exports 18.Sh DESCRIPTION 19The 20.Nm exports 21file specifies remote mount points for the 22.Tn NFS 23mount protocol per the 24.Tn NFS 25server specification; see 26.%T "Network File System Protocol Specification \\*(tNRFC\\*(sP 1094, Appendix A" 27and 28.%T "NFS: Network File System Version 3 Specification, Appendix I" . 29.Pp 30Each line in the file 31(other than comment lines that begin with a #) 32specifies the mount point(s) and export flags within one local server 33filesystem for one or more hosts. 34A host may be specified only once for each local filesystem on the 35server and there may be only one default entry for each server 36filesystem that applies to all other hosts. 37The latter exports the filesystem to the ``world'' and should 38be used only when the filesystem contains public information. 39.Pp 40In a mount entry, 41the first field(s) specify the directory path(s) within a server filesystem 42that can be mounted on by the corresponding client(s). 43There are two forms of this specification. 44The first is to list all mount points as absolute 45directory paths separated by whitespace. 46The second is to specify the pathname of the root of the filesystem 47followed by the 48.Fl alldirs 49flag; 50this form allows the host(s) to mount at any point within the filesystem, 51including regular files if the 52.Fl r 53option is used on mountd. 54The pathnames must not have any symbolic links in them and should not have 55any "." or ".." components. 56Mount points for a filesystem may appear on multiple lines each with 57different sets of hosts and export options. 58.Pp 59The second component of a line specifies how the filesystem is to be 60exported to the host set. 61The option flags specify whether the filesystem 62is exported read-only or read-write and how the client uid is mapped to 63user credentials on the server. 64.Pp 65Export options are specified as follows: 66.Pp 67.Sm off 68.Fl maproot No = Sy user 69.Sm on 70The credential of the specified user is used for remote access by root. 71The credential includes all the groups to which the user is a member 72on the local machine (see 73.Xr id 1 ). 74The user may be specified by name or number. 75.Pp 76.Sm off 77.Fl maproot No = Sy user:group1:group2:... 78.Sm on 79The colon separated list is used to specify the precise credential 80to be used for remote access by root. 81The elements of the list may be either names or numbers. 82Note that user: should be used to distinguish a credential containing 83no groups from a complete credential for that user. 84.Pp 85.Sm off 86.Fl mapall No = Sy user 87.Sm on 88or 89.Sm off 90.Fl mapall No = Sy user:group1:group2:... 91.Sm on 92specifies a mapping for all client uids (including root) 93using the same semantics as 94.Fl maproot . 95.Pp 96The option 97.Fl r 98is a synonym for 99.Fl maproot 100in an effort to be backward compatible with older export file formats. 101.Pp 102In the absence of 103.Fl maproot 104and 105.Fl mapall 106options, remote accesses by root will result in using a credential of -2:-2. 107All other users will be mapped to their remote credential. 108If a 109.Fl maproot 110option is given, 111remote access by root will be mapped to that credential instead of -2:-2. 112If a 113.Fl mapall 114option is given, 115all users (including root) will be mapped to that credential in 116place of their own. 117.Pp 118The 119.Fl kerb 120option specifies that the Kerberos authentication server should be 121used to authenticate and map client credentials. 122This option requires that the kernel be built with the NFSKERB option. 123.Pp 124The 125.Fl ro 126option specifies that the filesystem should be exported read-only 127(default read/write). 128The option 129.Fl o 130is a synonym for 131.Fl ro 132in an effort to be backward compatible with older export file formats. 133.Pp 134The third component of a line specifies the host set to which the line applies. 135The set may be specified in three ways. 136The first way is to list the host name(s) separated by white space. 137(Standard internet ``dot'' addresses may be used in place of names.) 138The second way is to specify a ``netgroup'' as defined in the netgroup file (see 139.Xr netgroup 5 ). 140The third way is to specify an internet subnetwork using a network and 141network mask that is defined as the set of all hosts with addresses within 142the subnetwork. 143This latter approach requires less overhead within the 144kernel and is recommended for cases where the export line refers to a 145large number of clients within an administrative subnet. 146.Pp 147The first two cases are specified by simply listing the name(s) separated 148by whitespace. 149All names are checked to see if they are ``netgroup'' names 150first and are assumed to be hostnames otherwise. 151Using the full domain specification for a hostname can normally 152circumvent the problem of a host that has the same name as a netgroup. 153The third case is specified by the flag 154.Sm off 155.Fl network No = Sy netname 156.Sm on 157and optionally 158.Sm off 159.Fl mask No = Sy netmask . 160.Sm on 161If the mask is not specified, it will default to the mask for that network 162class (A, B or C; see 163.Xr inet 5 ). 164.Pp 165For example: 166.Bd -literal -offset indent 167/usr /usr/local -maproot=0:10 friends 168/usr -maproot=daemon grumpy.cis.uoguelph.ca 131.104.48.16 169/usr -ro -mapall=nobody 170/u -maproot=bin: -network 131.104.48 -mask 255.255.255.0 171/u2 -maproot=root friends 172/u2 -alldirs -kerb -network cis-net -mask cis-mask 173.Ed 174.Pp 175Given that 176.Sy /usr , 177.Sy /u 178and 179.Sy /u2 180are 181local filesystem mount points, the above example specifies the following: 182.Sy /usr 183is exported to hosts 184.Em friends 185where friends is specified in the netgroup file 186with users mapped to their remote credentials and 187root mapped to uid 0 and group 10. 188It is exported read-write and the hosts in ``friends'' can mount either /usr 189or /usr/local. 190It is exported to 191.Em 131.104.48.16 192and 193.Em grumpy.cis.uoguelph.ca 194with users mapped to their remote credentials and 195root mapped to the user and groups associated with ``daemon''; 196it is exported to the rest of the world as read-only with 197all users mapped to the user and groups associated with ``nobody''. 198.Pp 199.Sy /u 200is exported to all hosts on the subnetwork 201.Em 131.104.48 202with root mapped to the uid for ``bin'' and with no group access. 203.Pp 204.Sy /u2 205is exported to the hosts in ``friends'' with root mapped to uid and groups 206associated with ``root''; 207it is exported to all hosts on network ``cis-net'' allowing mounts at any 208directory within /u2 and mapping all uids to credentials for the principal 209that is authenticated by a Kerberos ticket. 210.Sh FILES 211.Bl -tag -width /etc/exports -compact 212.It Pa /etc/exports 213The default remote mount-point file. 214.El 215.Sh SEE ALSO 216.Xr netgroup 5 , 217.Xr mountd 8 , 218.Xr nfsd 8 , 219.Xr showmount 8 220.Sh BUGS 221The export options are tied to the local mount points in the kernel and 222must be non-contradictory for any exported subdirectory of the local 223server mount point. 224It is recommended that all exported directories within the same server 225filesystem be specified on adjacent lines going down the tree. 226You cannot specify a hostname that is also the name of a netgroup. 227Specifying the full domain specification for a hostname can normally 228circumvent the problem. 229