Print this page
nits pt 2
Fix nits
Updated wording
5032 share_nfs(1m): Documentation for "noaclfab" is needed
| Split |
Close |
| Expand all |
| Collapse all |
--- old/usr/src/man/man1m/share_nfs.1m.man.txt
+++ new/usr/src/man/man1m/share_nfs.1m.man.txt
1 1 SHARE_NFS(1M) Maintenance Commands SHARE_NFS(1M)
2 2
3 3 NAME
4 4 share_nfs - make local NFS file systems available for mounting by remote
5 5 systems
6 6
7 7 SYNOPSIS
8 8 share [-d description] [-F nfs] [-o specific_options] pathname
9 9
10 10 DESCRIPTION
11 11 The share utility makes local file systems available for mounting by
12 12 remote systems. It starts the nfsd(1M) and mountd(1M) daemons if they are
13 13 not already running.
14 14
15 15 If no argument is specified, then share displays all file systems
16 16 currently shared, including NFS file systems and file systems shared
17 17 through other distributed file system packages.
18 18
19 19 OPTIONS
20 20 The following options are supported:
21 21
22 22 -d description
23 23 Provide a comment that describes the file system to be shared.
24 24
25 25 -F nfs Share NFS file system type.
26 26
27 27 -o specific_options
28 28 Specify specific_options in a comma-separated list of keywords
29 29 and attribute-value-assertions for interpretation by the file-
30 30 system-type-specific command. If specific_options is not
31 31 specified, then by default sharing is read-write to all
32 32 clients. specific_options can be any combination of the
33 33 following:
34 34
35 35 aclok Allows the NFS server to do access control for NFS
36 36 Version 2 clients (running SunOS 2.4 or earlier).
37 37 When aclok is set on the server, maximal access is
38 38 given to all clients. For example, with aclok set, if
39 39 anyone has read permissions, then everyone does. If
40 40 aclok is not set, minimal access is given to all
41 41 clients.
42 42
43 43 anon=uid Set uid to be the effective user ID of unknown users.
44 44 By default, unknown users are given the effective
45 45 user ID UID_NOBODY. If uid is set to -1, access is
46 46 denied.
47 47
48 48 charset=access_list
49 49 Where charset is one of: euc-cn, euc-jp, euc-jpms,
50 50 euc-kr, euc-tw, iso8859-1, iso8859-2, iso8859-5,
51 51 iso8859-6, iso8859-7, iso8859-8, iso8859-9,
52 52 iso8859-13, iso8859-15, koi8-r.
53 53
54 54 Clients that match the access_list for one of these
55 55 properties will be assumed to be using that character
56 56 set and file and path names will be converted to
57 57 UTF-8 for the server.
58 58
59 59 gidmap=mapping[~mapping]...
60 60 Where mapping is: [clnt]:[srv]:access_list
61 61
62 62 Allows remapping the group ID (gid) in the incoming
63 63 request to some other gid. This effectively changes
64 64 the identity of the user in the request to that of
65 65 some other local user.
66 66
67 67 For clients where the gid in the incoming request is
68 68 clnt and the client matches the access_list, change
69 69 the group ID to srv. If clnt is asterisk (*), all
70 70 groups are mapped by this rule. If clnt is omitted,
71 71 all unknown groups are mapped by this rule. If srv
72 72 is set to -1, access is denied. If srv is omitted,
73 73 the gid is mapped to UID_NOBODY.
74 74
75 75 The particular mappings are separated in the gidmap=
76 76 option by tilde (~) and are evaluated in the
77 77 specified order until a match is found. Both root=
78 78 and root_mapping= options (if specified) are
79 79 evaluated before the gidmap= option. The gidmap=
80 80 option is skipped in the case where the client
81 81 matches the root= option.
82 82
83 83 The gidmap= option is evaluated before the anon=
84 84 option.
85 85
86 86 This option is supported only for AUTH_SYS.
87 87
88 88 index=file
89 89 Load file rather than a listing of the directory
90 90 containing this file when the directory is referenced
91 91 by an NFS URL.
92 92
|
↓ open down ↓ |
92 lines elided |
↑ open up ↑ |
93 93 log[=tag]
94 94 Enables NFS server logging for the specified file
95 95 system. The optional tag determines the location of
96 96 the related log files. The tag is defined in
97 97 /etc/nfs/nfslog.conf. If no tag is specified, the
98 98 default values associated with the global tag in
99 99 /etc/nfs/nfslog.conf are used. Support of NFS server
100 100 logging is only available for NFS Version 2 and
101 101 Version 3 requests.
102 102
103 + noaclfab By default, the NFS server will fabricate POSIX-draft
104 + style ACLs in response to ACL requests from NFS
105 + Version 2 or Version 3 clients accessing shared file
106 + systems that do not support POSIX-draft ACLs (such as
107 + ZFS). Specifying noaclfab disables this behavior.
108 +
103 109 none=access_list
104 110 Access is not allowed to any client that matches the
105 111 access list. The exception is when the access list is
106 112 an asterisk (*), in which case ro or rw can override
107 113 none.
108 114
109 115 nosub Prevents clients from mounting subdirectories of
110 116 shared directories. For example, if /export is shared
111 117 with the nosub option on server "fooey" then a NFS
112 118 client cannot do:
113 119
114 120 mount -F nfs fooey:/export/home/mnt
115 121
116 122 NFS Version 4 does not use the MOUNT protocol. The
117 123 nosub option only applies to NFS Version 2 and
118 124 Version 3 requests.
119 125
120 126 nosuid By default, clients are allowed to create files on
121 127 the shared file system with the setuid or setgid mode
122 128 enabled. Specifying nosuid causes the server file
123 129 system to silently ignore any attempt to enable the
124 130 setuid or setgid mode bits.
125 131
126 132 public Moves the location of the public file handle from
127 133 root (/) to the exported directory for WebNFS-enabled
128 134 browsers and clients. This option does not enable
129 135 WebNFS service; WebNFS is always on. Only one file
130 136 system per server may use this option. Any other
131 137 option, including the ro=list and rw=list options can
132 138 be included with the public option.
133 139
134 140 ro Sharing is read-only to all clients.
135 141
136 142 ro=access_list
137 143 Sharing is read-only to the clients listed in
138 144 access_list; overrides the rw suboption for the
139 145 clients specified. See access_list below.
140 146
141 147 root=access_list
142 148 Only root users from the hosts specified in
143 149 access_list have root access. See access_list below.
144 150 By default, no host has root access, so root users
145 151 are mapped to an anonymous user ID (see the anon=uid
146 152 option described above). Netgroups can be used if the
147 153 file system shared is using UNIX authentication
148 154 (AUTH_SYS).
149 155
150 156 root_mapping=uid
151 157 For a client that is allowed root access, map the
152 158 root UID to the specified user id.
153 159
154 160 rw Sharing is read-write to all clients.
155 161
156 162 rw=access_list
157 163 Sharing is read-write to the clients listed in
158 164 access_list; overrides the ro suboption for the
159 165 clients specified. See access_list below.
160 166
161 167 sec=mode[:mode]...
162 168 Sharing uses one or more of the specified security
163 169 modes. The mode in the sec=mode option must be a mode
164 170 name supported on the client. If the sec= option is
165 171 not specified, the default security mode used is
166 172 AUTH_SYS. Multiple sec= options can be specified on
167 173 the command line, although each mode can appear only
168 174 once. The security modes are defined in nfssec(5).
169 175
170 176 Each sec= option specifies modes that apply to any
171 177 subsequent window=, rw, ro, rw=, ro=, and root=
172 178 options that are provided before another sec= option.
173 179 Each additional sec= resets the security mode
174 180 context, so that more window=, rw, ro, rw=, ro=, and
175 181 root= options can be supplied for additional modes.
176 182
177 183 sec=none If the option sec=none is specified when the client
178 184 uses AUTH_NONE, or if the client uses a security mode
179 185 that is not one that the file system is shared with,
180 186 then the credential of each NFS request is treated as
181 187 unauthenticated. See the anon=uid option for a
182 188 description of how unauthenticated requests are
183 189 handled.
184 190
185 191 secure This option has been deprecated in favor of the
186 192 sec=dh option.
187 193
188 194 uidmap=mapping[~mapping]...
189 195 Where mapping is: [clnt]:[srv]:access_list
190 196
191 197 Allows remapping the user ID (uid) in the incoming
192 198 request to some other uid. This effectively changes
193 199 the identity of the user in the request to that of
194 200 some other local user.
195 201
196 202 For clients where the uid in the incoming request is
197 203 clnt and the client matches the access_list, change
198 204 the user ID to srv. If clnt is asterisk (*), all
199 205 users are mapped by this rule. If clnt is omitted,
200 206 all unknown users are mapped by this rule. If srv is
201 207 set to -1, access is denied. If srv is omitted, the
202 208 uid is mapped to UID_NOBODY.
203 209
204 210 The particular mappings are separated in the uidmap=
205 211 option by tilde (~) and are evaluated in the
206 212 specified order until a match is found. Both root=
207 213 and root_mapping= options (if specified) are
208 214 evaluated before the uidmap= option. The uidmap=
209 215 option is skipped in the case where the client
210 216 matches the root= option.
211 217
212 218 The uidmap= option is evaluated before the anon=
213 219 option.
214 220
215 221 This option is supported only for AUTH_SYS.
216 222
217 223 window=value
218 224 When sharing with sec=dh, set the maximum life time
219 225 (in seconds) of the RPC request's credential (in the
220 226 authentication header) that the NFS server allows. If
221 227 a credential arrives with a life time larger than
222 228 what is allowed, the NFS server rejects the request.
223 229 The default value is 30000 seconds (8.3 hours).
224 230
225 231 access_list
226 232 The access_list argument is a colon-separated list whose components may
227 233 be any number of the following:
228 234
229 235 hostname The name of a host. With a server configured for DNS or LDAP
230 236 naming in the nsswitch hosts entry, any hostname must be
231 237 represented as a fully qualified DNS or LDAP name.
232 238
233 239 netgroup A netgroup contains a number of hostnames. With a server
234 240 configured for DNS or LDAP naming in the nsswitch hosts entry,
235 241 any hostname in a netgroup must be represented as a fully
236 242 qualified DNS or LDAP name.
237 243
238 244 domain name suffix
239 245 To use domain membership the server must use DNS or LDAP to
240 246 resolve hostnames to IP addresses; that is, the hosts entry in
241 247 the /etc/nsswitch.conf must specify dns or ldap ahead of nis or
242 248 nisplus, since only DNS and LDAP return the full domain name of
243 249 the host. Other name services like NIS or NIS+ cannot be used
244 250 to resolve hostnames on the server because when mapping an IP
245 251 address to a hostname they do not return domain information.
246 252 For example,
247 253
248 254 NIS or NIS+ 172.16.45.9 --> "myhost"
249 255
250 256 and
251 257
252 258 DNS or LDAP 172.16.45.9 --> "myhost.mydomain.mycompany.com"
253 259
254 260 The domain name suffix is distinguished from hostnames and
255 261 netgroups by a prefixed dot. For example,
256 262
257 263 rw=.mydomain.mycompany.com
258 264
259 265 A single dot can be used to match a hostname with no suffix.
260 266 For example,
261 267
262 268 rw=.
263 269
264 270 matches "mydomain" but not "mydomain.mycompany.com". This
265 271 feature can be used to match hosts resolved through NIS and
266 272 NIS+ rather than DNS and LDAP.
267 273
268 274 network The network or subnet component is preceded by an at-sign (@).
269 275 It can be either a name or a dotted address. If a name, it is
270 276 converted to a dotted address by getnetbyname(3SOCKET). For
271 277 example,
272 278
273 279 =@mynet
274 280
275 281 would be equivalent to:
276 282
277 283 =@172.16 or =@172.16.0.0
278 284
279 285 The network prefix assumes an octet-aligned netmask determined
280 286 from the zeroth octet in the low-order part of the address up
281 287 to and including the high-order octet, if you want to specify a
282 288 single IP address (see below). In the case where network
283 289 prefixes are not byte-aligned, the syntax allows a mask length
284 290 to be specified explicitly following a slash (/) delimiter. For
285 291 example,
286 292
287 293 =@theothernet/17 or =@172.16.132/22
288 294
289 295 where the mask is the number of leftmost contiguous significant
290 296 bits in the corresponding IP address.
291 297
292 298 When specifying individual IP addresses, use the same @
293 299 notation described above, without a netmask specification. For
294 300 example:
295 301
296 302 =@172.16.132.14
297 303
298 304 Multiple, individual IP addresses would be specified, for
299 305 example, as:
300 306
301 307 root=@172.16.132.20:@172.16.134.20
302 308
303 309 A prefixed minus sign (-) denies access to that component of access_list.
304 310 The list is searched sequentially until a match is found that either
305 311 grants or denies access, or until the end of the list is reached. For
306 312 example, if host "terra" is in the "engineering" netgroup, then
307 313
308 314 rw=-terra:engineering
309 315
310 316 denies access to "terra" but
311 317
312 318 rw=engineering:-terra
313 319
314 320 grants access to "terra".
315 321
316 322 OPERANDS
317 323 The following operands are supported:
318 324
319 325 pathname The pathname of the file system to be shared.
320 326
321 327 FILES
322 328 /etc/dfs/fstypes list of system types, NFS by default
323 329
324 330 /etc/dfs/sharetab system record of shared file systems
325 331
326 332 /etc/nfs/nfslogtab system record of logged file systems
327 333
328 334 /etc/nfs/nfslog.conf logging configuration file
329 335
330 336 EXIT STATUS
331 337 The share_nfs utility exits 0 on success, and >0 if an error occurs.
332 338
333 339 EXAMPLES
334 340 Example 1 Sharing A File System With Logging Enabled
335 341 The following example shows the /export file system shared with logging
336 342 enabled:
337 343
338 344 share -o log /export
339 345
340 346 The default global logging parameters are used since no tag identifier is
341 347 specified. The location of the log file, as well as the necessary logging
342 348 work files, is specified by the global entry in /etc/nfs/nfslog.conf.
343 349 The nfslogd(1M) daemon runs only if at least one file system entry in
344 350 /etc/dfs/dfstab is shared with logging enabled upon starting or rebooting
345 351 the system. Simply sharing a file system with logging enabled from the
|
↓ open down ↓ |
233 lines elided |
↑ open up ↑ |
346 352 command line does not start the nfslogd(1M).
347 353
348 354 Example 2 Remap A User Coming From The Particular NFS Client
349 355 The following example remaps the user with uid 100 at client 10.0.0.1 to
350 356 user joe:
351 357
352 358 share -o uidmap=100:joe:@10.0.0.1 /export
353 359
354 360 SEE ALSO
355 361 mount(1M), mountd(1M), nfsd(1M), nfslogd(1M), share(1M), unshare(1M),
356 - getnetbyname(3SOCKET), netgroup(4), nfslog.conf(4), attributes(5),
357 - nfssec(5)
362 + getnetbyname(3SOCKET), netgroup(4), nfslog.conf(4), acl(5),
363 + attributes(5), nfssec(5)
358 364
359 365 NOTES
360 366 If the sec= option is presented at least once, all uses of the window=,
361 367 rw, ro, rw=, ro=, and root= options must come after the first sec=
362 368 option. If the sec= option is not presented, then sec=sys is implied.
363 369
364 370 If one or more explicit sec= options are presented, sys must appear in
365 371 one of the options mode lists for accessing using the AUTH_SYS security
366 372 mode to be allowed. For example:
367 373
368 374 share -F nfs /var
369 375 share -F nfs -o sec=sys /var
370 376
371 377 grants read-write access to any host using AUTH_SYS, but
372 378
373 379 share -F nfs -o sec=dh /var
374 380
375 381 grants no access to clients that use AUTH_SYS.
376 382
377 383 Unlike previous implementations of share_nfs, access checking for the
378 384 window=, rw, ro, rw=, and ro= options is done per NFS request, instead of
379 385 per mount request.
380 386
381 387 Combining multiple security modes can be a security hole in situations
382 388 where the ro= and rw= options are used to control access to weaker
383 389 security modes. In this example,
384 390
385 391 share -F nfs -o sec=dh,rw,sec=sys,rw=hosta /var
386 392
387 393 an intruder can forge the IP address for "hosta" (albeit on each NFS
388 394 request) to side-step the stronger controls of AUTH_DES. Something like:
389 395
390 396 share -F nfs -o sec=dh,rw,sec=sys,ro /var
391 397
392 398 is safer, because any client (intruder or legitimate) that avoids
393 399 AUTH_DES only gets read-only access. In general, multiple security modes
394 400 per share command should only be used in situations where the clients
395 401 using more secure modes get stronger access than clients using less
396 402 secure modes.
397 403
398 404 If rw= and ro= options are specified in the same sec= clause, and a
399 405 client is in both lists, the order of the two options determines the
400 406 access the client gets. If client "hosta" is in two netgroups, "group1"
401 407 and "group2", in this example, the client would get read-only access:
402 408
403 409 share -F nfs -o ro=group1,rw=group2 /var
404 410
405 411 In this example "hosta" would get read-write access:
406 412
407 413 share -F nfs -o rw=group2,ro=group1 /var
408 414
409 415 If within a sec= clause, both the ro and rw= options are specified, for
410 416 compatibility, the order of the options rule is not enforced. All hosts
411 417 would get read-only access, with the exception to those in the read-write
412 418 list. Likewise, if the ro= and rw options are specified, all hosts get
413 419 read-write access with the exceptions of those in the read-only list.
414 420
415 421 The ro= and rw= options are guaranteed to work over UDP and TCP but may
416 422 not work over other transport providers.
417 423
418 424 The root= option with AUTH_SYS is guaranteed to work over UDP and TCP but
419 425 may not work over other transport providers.
420 426
421 427 The root= option with AUTH_DES is guaranteed to work over any transport
422 428 provider.
423 429
424 430 There are no interactions between the root= option and the rw, ro, rw=,
425 431 and ro= options. Putting a host in the root list does not override the
426 432 semantics of the other options. The access the host gets is the same as
427 433 when the root= option is absent. For example, the following share command
428 434 denies access to "hostb":
429 435
430 436 share -F nfs -o ro=hosta,root=hostb /var
431 437
432 438 The following gives read-only permissions to "hostb":
433 439
434 440 share -F nfs -o ro=hostb,root=hostb /var
435 441
436 442 The following gives read-write permissions to "hostb":
437 443
438 444 share -F nfs -o ro=hosta,rw=hostb,root=hostb /var
439 445
440 446 If the file system being shared is a symbolic link to a valid pathname,
441 447 the canonical path (the path which the symbolic link follows) is shared.
442 448 For example, if /export/foo is a symbolic link to /export/bar, the
443 449 following share command results in /export/bar as the shared pathname
444 450 (and not /export/foo):
445 451
446 452 share -F nfs /export/foo
447 453
448 454 An NFS mount of server:/export/foo results in server:/export/bar really
449 455 being mounted.
450 456
451 457 This line in the /etc/dfs/dfstab file shares the /disk file system read-
452 458 only at boot time:
453 459
454 460 share -F nfs -o ro /disk
455 461
456 462 The same command entered from the command line does not share the /disk
457 463 file system unless there is at least one file system entry in the
458 464 /etc/dfs/dfstab file. The mountd(1M) and nfsd(1M) daemons only run if
459 465 there is a file system entry in /etc/dfs/dfstab when starting or
460 466 rebooting the system.
461 467
462 468 The mountd(1M) process allows the processing of a path name the contains
|
↓ open down ↓ |
95 lines elided |
↑ open up ↑ |
463 469 a symbolic link. This allows the processing of paths that are not
464 470 themselves explicitly shared with share_nfs. For example, /export/foo
465 471 might be a symbolic link that refers to /export/bar which has been
466 472 specifically shared. When the client mounts /export/foo the mountd
467 473 processing follows the symbolic link and responds with the /export/bar.
468 474 The NFS Version 4 protocol does not use the mountd processing and the
469 475 client's use of /export/foo does not work as it does with NFS Version 2
470 476 and Version 3 and the client receives an error when attempting to mount
471 477 /export/foo.
472 478
473 -illumos November 10, 2014 illumos
479 +illumos December 16, 2016 illumos
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX