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