1.\" $NetBSD: exports.5,v 1.23 2003/08/07 11:25:34 agc Exp $ 2.\" 3.\" Copyright (c) 1989, 1991, 1993 4.\" The Regents of the University of California. All rights reserved. 5.\" 6.\" Redistribution and use in source and binary forms, with or without 7.\" modification, are permitted provided that the following conditions 8.\" are met: 9.\" 1. Redistributions of source code must retain the above copyright 10.\" notice, this list of conditions and the following disclaimer. 11.\" 2. Redistributions in binary form must reproduce the above copyright 12.\" notice, this list of conditions and the following disclaimer in the 13.\" documentation and/or other materials provided with the distribution. 14.\" 3. Neither the name of the University nor the names of its contributors 15.\" may be used to endorse or promote products derived from this software 16.\" without specific prior written permission. 17.\" 18.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 19.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 20.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 21.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 22.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 23.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 24.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 25.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 26.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 27.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 28.\" SUCH DAMAGE. 29.\" 30.\" @(#)exports.5 8.3 (Berkeley) 3/29/95 31.\" 32.Dd March 29, 1995 33.Dt EXPORTS 5 34.Os 35.Sh NAME 36.Nm exports 37.Nd define remote mount points for 38.Tn NFS 39mount requests 40.Sh SYNOPSIS 41.Nm exports 42.Sh DESCRIPTION 43The 44.Nm exports 45file specifies remote mount points for the 46.Tn NFS 47mount protocol per the 48.Tn NFS 49server specification; see 50.%T "Network File System Protocol Specification \\*(tNRFC\\*(sP 1094, Appendix A" 51and 52.%T "NFS: Network File System Version 3 Specification, Appendix I" . 53.Pp 54Each line in the file 55(other than comment lines that begin with a #) 56specifies the mount point(s) and export flags within one local server 57filesystem for one or more hosts. 58A host may be specified only once for each local filesystem on the 59server and there may be only one default entry for each server 60filesystem that applies to all other hosts. 61The latter exports the filesystem to the ``world'' and should 62be used only when the filesystem contains public information. 63.Pp 64If you have modified the 65.Pa /etc/exports 66file, send the mountd a SIGHUP to make it re-read the 67.Pa /etc/exports 68file: ``kill -HUP `cat /var/run/mountd.pid`''. 69.Pp 70In a mount entry, 71the first field(s) specify the directory path(s) within a server filesystem 72that can be mounted on by the corresponding client(s). 73There are two forms of this specification. 74The first is to list all mount points as absolute 75directory paths separated by whitespace. 76The second is to specify the pathname of the root of the filesystem 77followed by the 78.Fl alldirs 79flag; 80this form allows the host(s) to mount at any point within the filesystem, 81including regular files if the 82.Fl r 83option is used on mountd. Note that the 84.Fl alldirs 85option should not be used as a security measure to make clients mount 86only those subdirectories that they should have access to. A client 87can still access the whole filesystem via individual RPCs if it 88wanted to, even if just one subdirectory has been mounted. 89The pathnames must not have any symbolic links in them and should not have 90any "." or ".." components. 91Mount points for a filesystem may appear on multiple lines each with 92different sets of hosts and export options. 93.Pp 94The second component of a line specifies how the filesystem is to be 95exported to the host set. 96The option flags specify whether the filesystem 97is exported read-only or read-write and how the client uid is mapped to 98user credentials on the server. 99.Pp 100Export options are specified as follows: 101.Pp 102.Sm off 103.Fl maproot No = Sy user 104.Sm on 105The credential of the specified user is used for remote access by root. 106The credential includes all the groups to which the user is a member 107on the local machine (see 108.Xr id 1 ) . 109The user may be specified by name or number. 110.Pp 111.Sm off 112.Fl maproot No = Sy user:group1:group2:... 113.Sm on 114The colon separated list is used to specify the precise credential 115to be used for remote access by root. 116The elements of the list may be either names or numbers. 117Note that user: should be used to distinguish a credential containing 118no groups from a complete credential for that user. 119.Pp 120.Sm off 121.Fl mapall No = Sy user 122.Sm on 123or 124.Sm off 125.Fl mapall No = Sy user:group1:group2:... 126.Sm on 127specifies a mapping for all client uids (including root) 128using the same semantics as 129.Fl maproot . 130.Pp 131The option 132.Fl r 133is a synonym for 134.Fl maproot 135in an effort to be backward compatible with older export file formats. 136.Pp 137In the absence of 138.Fl maproot 139and 140.Fl mapall 141options, remote accesses by root will result in using a credential of -2:-2. 142All other users will be mapped to their remote credential. 143If a 144.Fl maproot 145option is given, 146remote access by root will be mapped to that credential instead of -2:-2. 147If a 148.Fl mapall 149option is given, 150all users (including root) will be mapped to that credential in 151place of their own. 152.Pp 153The 154.Fl kerb 155option specifies that the Kerberos authentication server should be 156used to authenticate and map client credentials. This option is currently 157not implemented. 158.Pp 159The 160.Fl ro 161option specifies that the filesystem should be exported read-only 162(default read/write). 163The option 164.Fl o 165is a synonym for 166.Fl ro 167in an effort to be backward compatible with older export file formats. 168.Pp 169The 170.Fl noresvport 171option specifies that NFS RPC calls for the filesystem do not have to come 172from reserved ports. Normally, clients are required to use reserved 173ports for operations. Using this option decreases the security of your 174system. 175.Pp 176The 177.Fl noresvmnt 178option specifies that mount RPC requests for the filesystem do not have 179to come from reserved ports. Normally, clients are required to use reserved 180ports for mount requests. Using this option decreases the security of 181your system. 182.Pp 183WebNFS exports strictly according to the spec (RFC 2054 and RFC 2055) can 184be done with the 185.Fl public 186flag. However, this flag in itself allows r/w access to all files in 187the filesystem, not requiring reserved ports and not remapping uids. It 188is only provided to conform to the spec, and should normally not be used. 189For a WebNFS export, 190use the 191.Fl webnfs 192flag, which implies 193.Fl public , 194.Sm off 195.Fl mapall No = Sy nobody 196.Sm on 197and 198.Fl ro . 199.Pp 200A 201.Sm off 202.Fl index No = Sy file 203.Sm on 204option can be used to specify a file whose handle will be returned if 205a directory is looked up using the public filehandle (WebNFS). This 206is to mimic the behavior of URLs. If no 207.Fl index 208option is specified, a directory filehandle will be returned as usual. 209The 210.Fl index 211option only makes sense in combination with the 212.Fl public 213or 214.Fl webnfs 215flags. 216.Pp 217.Bf -symbolic 218Warning: exporting a filesystem both using WebNFS and read/write in 219the normal way to other hosts should be avoided in an environment 220that is vulnerable to IP spoofing. 221.Ef 222WebNFS enables any client to get filehandles to the exported filesystem. 223Using IP spoofing, a client could then pretend to be a host to which 224the same filesystem was exported read/write, and use the handle to 225gain access to that filesystem. 226.Pp 227The third component of a line specifies the host set to which the line applies. 228If no host set is specified, the filesystem is exported to everyone. 229The set may be specified in three ways. 230The first way is to list the host name(s) separated by white space. 231(Standard internet ``dot'' addresses may be used in place of names.) 232The second way is to specify a ``netgroup'' as defined in the netgroup file (see 233.Xr netgroup 5 ) . 234A netgroup that contains an item that does have a host entry 235is treated like an error. 236The third way is to specify an internet subnetwork using a network and 237network mask that is defined as the set of all hosts with addresses within 238the subnetwork. 239This latter approach requires less overhead within the 240kernel and is recommended for cases where the export line refers to a 241large number of clients within an administrative subnet. 242.Pp 243The first two cases are specified by simply listing the name(s) separated 244by whitespace. 245All names are checked to see if they are ``netgroup'' names 246first and are assumed to be hostnames otherwise. 247Using the full domain specification for a hostname can normally 248circumvent the problem of a host that has the same name as a netgroup. 249The third case is specified by the flag 250.Sm off 251.Fl network No = Sy netname 252.Sm on 253and optionally 254.Sm off 255.Fl mask No = Sy netmask . 256.Sm on 257If the mask is not specified, it will default to the mask for that network 258class (A, B or C; see 259.Xr inet 4 ) . 260.Pp 261Scoped IPv6 address must carry scope identifier as documented in 262.Xr inet6 4 . 263For example, 264.Dq fe80::%ne2/10 265is used to specify fe80::/10 on ne2 interface. 266.Pp 267For example: 268.Bd -literal -offset indent 269/usr /usr/local -maproot=0:10 friends 270/usr -maproot=daemon grumpy.cis.uoguelph.ca 131.104.48.16 271/usr -ro -mapall=nobody 272/u -maproot=bin: -network 131.104.48 -mask 255.255.255.0 273/a -network 192.168.0/24 274/a -network 3ffe:1ce1:1:fe80::/64 275/u2 -maproot=root friends 276/u2 -alldirs -kerb -network cis-net -mask cis-mask 277.Ed 278.Pp 279Given that 280.Sy /usr , 281.Sy /u 282and 283.Sy /u2 284are 285local filesystem mount points, the above example specifies the following: 286.Sy /usr 287is exported to hosts 288.Em friends 289where friends is specified in the netgroup file 290with users mapped to their remote credentials and 291root mapped to uid 0 and group 10. 292It is exported read-write and the hosts in ``friends'' can mount either /usr 293or /usr/local. 294It is exported to 295.Em 131.104.48.16 296and 297.Em grumpy.cis.uoguelph.ca 298with users mapped to their remote credentials and 299root mapped to the user and groups associated with ``daemon''; 300it is exported to the rest of the world as read-only with 301all users mapped to the user and groups associated with ``nobody''. 302.Pp 303.Sy /u 304is exported to all hosts on the subnetwork 305.Em 131.104.48 306with root mapped to the uid for ``bin'' and with no group access. 307.Pp 308.Sy /u2 309is exported to the hosts in ``friends'' with root mapped to uid and groups 310associated with ``root''; 311it is exported to all hosts on network ``cis-net'' allowing mounts at any 312directory within /u2 and mapping all uids to credentials for the principal 313that is authenticated by a Kerberos ticket. 314.Pp 315.Sy /a 316is exported to the network 192.168.0.0, with a netmask of 255.255.255.0. 317However, the netmask length in the entry for /a is not specified through 318a -mask option, but through the /prefix notation. 319.Pp 320.Sy /a 321is also exported to the IPv6 network 3ffe:1ce1:1:fe80:: address, using 322the upper 64 bits as the prefix. Note that, unlike with IPv4 network 323addresses, the specified network address must be complete, and not just 324contain the upper bits. With IPv6 addresses, the -mask option must not 325be used. 326.Sh FILES 327.Bl -tag -width /etc/exports -compact 328.It Pa /etc/exports 329The default remote mount-point file. 330.El 331.Sh SEE ALSO 332.Xr netgroup 5 , 333.Xr mountd 8 , 334.Xr nfsd 8 , 335.Xr showmount 8 336.Sh BUGS 337The export options are tied to the local mount points in the kernel and 338must be non-contradictory for any exported subdirectory of the local 339server mount point. 340It is recommended that all exported directories within the same server 341filesystem be specified on adjacent lines going down the tree. 342You cannot specify a hostname that is also the name of a netgroup. 343Specifying the full domain specification for a hostname can normally 344circumvent the problem. 345