Penguin
Recent Changes
Annotated edit history of exports(5) version 1, including all changes. View license author blame.
Rev Author # Line
1 perry 1 EXPORTS
2 !!!EXPORTS
3 NAME
4 SYNOPSIS
5 DESCRIPTION
6 EXAMPLE
7 CAVEATS
8 FILES
9 DIAGNOSTICS
10 SEE ALSO
11 ----
12 !!NAME
13
14
15 exports - NFS file systems being exported
16 !!SYNOPSIS
17
18
19 __/etc/exports__
20 !!DESCRIPTION
21
22
23 The file ''/etc/exports'' serves as the access control
24 list for file systems which may be exported to NFS clients.
25 It is used by both the NFS mount daemon, mountd(8)
26 and the NFS file server daemon nfsd(8).
27
28
29 The file format is similar to the SunOS ''exports'' file,
30 except that several additional options are permitted. Each
31 line contains a mount point and a list of machine or
32 netgroup names allowed to mount the file system at that
33 point. An optional parenthesized list of mount parameters
34 may follow each machine name. Blank lines are ignored, and a
35 # introduces a comment to the end of the line. Entries may
36 be continued across newlines using a backslash.
37
38
39 __Machine Name Formats__
40
41
42 NFS clients may be specified in a number of
43 ways:
44
45
46 single host
47
48
49 This is the most common format. You may specify a host
50 either by an abbreviated name recognizued be the resolver,
51 the fully qualified domain name, or an IP
52 address.
53
54
55 netgroups
56
57
58 NIS netgroups may be given as ''@group''. Only the host
59 part of all netgroup members is extracted and added to the
60 access list. Empty host parts or those containing a single
61 dash (-) are ignored.
62
63
64 wildcards
65
66
67 Machine names may contain the wildcard characters ''*''
68 and ''?''. This can be used to make the ''exports''
69 file more compact; for instance, ''*.cs.foo.edu'' matches
70 all hosts in the domain ''cs.foo.edu''. However, these
71 wildcard characters do not match the dots in a domain name,
72 so the above pattern does not include hosts such as
73 ''a.b.cs.foo.edu''.
74
75
76 IP networks
77
78
79 You can also export directories to all hosts on an IP (sub-)
80 network simultaneously. This is done by specifying an IP
81 address and netmask pair as
82 ''address/netmask''.
83
84
85 __=public__
86
87
88 This is a special ``hostname'' that identifies the given
89 directory name as the public root directory (see the section
90 on WebNFS in nfsd(8) for a discussion of WebNFS and
91 the public root handle). When using this convention,
92 __=public__ must be the only entry on this line, and must
93 have no export options associated with it. Note that this
94 does ''not'' actually export the named directory; you
95 still have to set the exports options in a separate
96 entry.
97
98
99 The public root path can also be specified by invoking
100 ''nfsd'' with the __--public-root__ option. Multiple
101 specifications of a public root will be
102 ignored.
103
104
105 __General Options__
106
107
108 ''mountd'' and ''nfsd'' understand the following
109 export options:
110
111
112 ''secure''
113
114
115 This option requires that requests originate on an internet
116 port less than IPPORT_RESERVED (1024). This option is on by
117 default. To turn it off, specify
118 ''insecure''.
119
120
121 ''rw''
122
123
124 Allow the client to modify files and directories. The
125 default is to restrict the client to read-only request,
126 which can be made explicit by using the ''ro''
127 option.
128
129
130 ''noaccess''
131
132
133 This makes everything below the directory inaccessible for
134 the named client. This is useful when you want to export a
135 directory hierarchy to a client, but exclude certain
136 subdirectories. The client's view of a directory flagged
137 with noaccess is very limited; it is allowed to read its
138 attributes, and lookup `.' and `..'. These are also the only
139 entries returned by a readdir.
140
141
142 ''link_relative''
143
144
145 Convert absolute symbolic links (where the link contents
146 start with a slash) into relative links by prepending the
147 necessary number of ../'s to get from the directory
148 containing the link to the root on the server. This has
149 subtle, perhaps questionable, semantics when the file
150 hierarchy is not mounted at its root.
151
152
153 ''link_absolute''
154
155
156 Leave all symbolic link as they are. This is the default
157 operation.
158
159
160 __Anonymous Entries__
161
162
163 Entries where hosts are not specified are known as anonymous
164 entries. They have different default settings compared to
165 normal entries. The differences include ''all_squash'',
166 ''no_secure'', and ''ro''.
167
168
169 __User ID Mapping__
170
171
172 ''nfsd'' bases its access control to files on the server
173 machine on the uid and gid provided in each NFS RPC request.
174 The normal behavior a user would expect is that she can
175 access her files on the server just as she would on a normal
176 file system. This requires that the same uids and gids are
177 used on the client and the server machine. This is not
178 always true, nor is it always desirable.
179
180
181 Very often, it is not desirable that the root user on a
182 client machine is also treated as root when accessing files
183 on the NFS server. To this end, uid 0 is normally mapped to
184 a different id: the so-called anonymous or ''nobody''
185 uid. This mode of operation (called `root squashing') is the
186 default, and can be turned off with
187 ''no_root_squash''.
188
189
190 By default, ''nfsd'' tries to obtain the anonymous uid
191 and gid by looking up user ''nobody'' in the password
192 file at startup time. If it isn't found, a uid and gid of -2
193 (i.e. 65534) is used. These values can also be overridden by
194 the ''anonuid'' and ''anongid'' options.
195
196
197 In addition to this, ''nfsd'' lets you specify arbitrary
198 uids and gids that should be mapped to user nobody as well.
199 Finally, you can map all user requests to the anonymous uid
200 by specifying the ''all_squash'' option.
201
202
203 For the benefit of installations where uids differ between
204 different machines, ''nfsd'' provides several mechanism
205 to dynamically map server uids to client uids and vice
206 versa: static mapping files, NIS-based mapping, and
207 ''ugidd''-based mapping.
208
209
210 ''ugidd''-based mapping is enabled with the
211 ''map_daemon'' option, and uses the UGID RPC protocol.
212 For this to work, you have to run the ugidd(8)
213 mapping daemon on the client host. It is the least secure of
214 the three methods, because by running ''ugidd'',
215 everybody can query the client host for a list of valid user
216 names. You can protect yourself by restricting access to
217 ''ugidd'' to valid hosts only. This can be done by
218 entering the list of valid hosts into the ''hosts.allow''
219 or ''hosts.deny'' file. The service name is ''ugidd''.
220 For a description of the file's syntax, please read
221 ''hosts_access''(5).
222
223
224 Static mapping is enabled by using the ''map_static''
225 option, which takes a file name as an argument that
226 describes the mapping. NIS-based mapping queries the
227 client's NIS server to obtain a mapping from user and group
228 names on the server host to user and group names on the
229 client.
230
231
232 Here's the complete list of mapping options:
233
234
235 ''root_squash''
236
237
238 Map requests from uid/gid 0 to the anonymous uid/gid. Note
239 that this does not apply to any other uids that might be
240 equally sensitive, such as user ''bin''.
241
242
243 ''no_root_squash''
244
245
246 Turn off root squashing. This option is mainly useful for
247 diskless clients.
248
249
250 ''squash_uids'' and ''squash_gids''
251
252
253 This option specifies a list of uids or gids that should be
254 subject to anonymous mapping. A valid list of ids looks like
255 this:
256
257
258 ''squash_uids=0-15,20,25-50''
259
260
261 Usually, your squash lists will look a lot
262 simpler.
263
264
265 ''all_squash''
266
267
268 Map all uids and gids to the anonymous user. Useful for
269 NFS-exported public FTP directories, news spool directories,
270 etc. The opposite option is ''no_all_squash'', which is
271 the default setting.
272
273
274 ''map_daemon''
275
276
277 This option turns on dynamic uid/gid mapping. Each uid in an
278 NFS request will be translated to the equivalent server uid,
279 and each uid in an NFS reply will be mapped the other way
280 round. This option requires that ''rpc.ugidd''(8) runs on
281 the client host. The default setting is ''map_identity'',
282 which leaves all uids untouched. The normal squash options
283 apply regardless of whether dynamic mapping is requested or
284 not.
285
286
287 ''map_static''
288
289
290 This option enables static mapping. It specifies the name of
291 the file that describes the uid/gid mapping,
292 e.g.
293
294
295 ''map_static=/etc/nfs/foobar.map''
296
297
298 The file's format looks like this
299
300
301 # Mapping for client foobar:
302 # remote local
303 uid 0-99 - # squash these
304 uid 100-500 1000 # map 100-500 to 1000-1500
305 gid 0-49 - # squash these
306 gid 50-100 700 # map 50-100 to 700-750
307
308
309 ''map_nis''
310
311
312 This option enables NIS-based uid/gid mapping. For instance,
313 when the server encounters the uid 123 on the server, it
314 will obtain the login name associated with it, and contact
315 the NFS client's NIS server to obtain the uid the client
316 associates with the name.
317
318
319 In order to do this, the NFS server must know the client's
320 NIS domain. This is specified as an argument to the
321 ''map_nis'' options, e.g.
322
323
324 ''map_nis=foo.com''
325
326
327 Note that it may not be sufficient to simply specify the NIS
328 domain here; you may have to take additional actions before
329 ''nfsd'' is actually able to contact the server. If your
330 distribution uses the NYS library, you can specify one or
331 more NIS servers for the client's domain in
332 ''/etc/yp.conf''. If you are using a different NIS
333 library, you may have to obtain a special ypbind(8)
334 daemon that can be configured via
335 ''yp.conf''.
336
337
338 ''anonuid'' and ''anongid''
339
340
341 These options explicitly set the uid and gid of the
342 anonymous account. This option is primarily useful for
343 PC/NFS clients, where you might want all requests appear to
344 be from one user. As an example, consider the export entry
345 for __/home/joe__ in the example section below, which
346 maps all requests to uid 150 (which is supposedly that of
347 user joe).
348 !!EXAMPLE
349
350
351 # sample /etc/exports file
352 / master(rw) trusty(rw,no_root_squash)
353 /projects proj*.local.domain(rw)
354 /usr *.local.domain(ro) @trusted(rw)
355 /home/joe pc001(rw,all_squash,anonuid=150,anongid=100)
356 /pub (ro,insecure,all_squash)
357 /pub/private (noaccess)
358 The first line exports the entire filesystem to machines master and trusty. In addition to write access, all uid squashing is turned off for host trusty. The second and third entry show examples for wildcard hostnames and netgroups (this is the entry `@trusted'). The fourth line shows the entry for the PC/NFS client discussed above. Line 5 exports the public FTP directory to every host in the world, executing all requests under the nobody account. The ''insecure'' option in this entry also allows clients with NFS implementations that don't use a reserved port for NFS. The last line denies all NFS clients access to the private directory.
359 !!CAVEATS
360
361
362 Unlike other NFS server implementations, this ''nfsd''
363 allows you to export both a directory and a subdirectory
364 thereof to the same host, for instance ''/usr'' and
365 ''/usr/X11R6''. In this case, the mount options of the
366 most specific entry apply. For instance, when a user on the
367 client host accesses a file in ''/usr/X11R6'', the mount
368 options given in the ''/usr/X11R6'' entry apply. This is
369 also true when the latter is a wildcard or netgroup
370 entry.
371 !!FILES
372
373
374 /etc/exports
375 !!DIAGNOSTICS
376
377
378 An error parsing the file is reported using syslogd(8) as
379 level NOTICE from a DAEMON whenever nfsd(8) or mountd(8) is
380 started up. Any unknown host is reported at that time, but
381 often not all hosts are not yet known to named(8) at boot
382 time, thus as hosts are found they are reported with the
383 same syslogd(8) parameters.
384 !!SEE ALSO
385
386
387 mountd(8), nfsd(8)
388 ----
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.