Print this page
2988 nfssrv: need ability to go to submounts for v3 and v2 protocols
Portions contributed by: Marcel Telka <marcel.telka@nexenta.com>
Portions contributed by: Jean McCormack <jean.mccormack@nexenta.com>
Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com>
Reviewed by: Alek Pinchuk <alek.pinchuk@nexenta.com>
Reviewed by: Dan Fields <dan.fields@nexenta.com>
Reviewed by: Dan McDonald <danmcd@joyent.com>
Change-Id: I6fdf110cc17e789353c4442b83a46cb80643456e
| 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
13 13 are 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,
39 39 if anyone has read permissions, then everyone does.
40 40 If 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 + nohide By default, if server exports two filesystems, one of
104 + which is mounted as a child of the other, NFS Version
105 + 2 and Version 3 clients must mount both filesystems
106 + explicitly in order to access them. If a client only
107 + mounts the parent, it will see an empty directory at
108 + the location where the other filesystem is mounted.
109 +
110 + Setting the nohide option on a filesystem causes it
111 + to no longer be hidden in this manner, and the client
112 + will be able to move from the parent filesystem to
113 + this one without noticing the change. However, some
114 + NFS clients or applications may not function
115 + correctly when this option is used. In particular,
116 + files on different underlying filesystems may appear
117 + to have the same inode numbers. The nohide option
118 + only applies to NFS Version 2 and Version 3 requests.
119 +
103 120 noaclfab By default, the NFS server will fabricate POSIX-draft
104 121 style ACLs in response to ACL requests from NFS
105 122 Version 2 or Version 3 clients accessing shared file
106 123 systems that do not support POSIX-draft ACLs (such as
107 124 ZFS). Specifying noaclfab disables this behavior.
108 125
109 126 none=access_list
110 127 Access is not allowed to any client that matches the
111 128 access list. The exception is when the access list
112 129 is an asterisk (*), in which case ro or rw can
113 130 override none.
114 131
115 132 nosub Prevents clients from mounting subdirectories of
116 133 shared directories. For example, if /export is
117 134 shared with the nosub option on server "fooey" then a
118 135 NFS client cannot do:
119 136
120 137 mount -F nfs fooey:/export/home/mnt
121 138
122 139 NFS Version 4 does not use the MOUNT protocol. The
123 140 nosub option only applies to NFS Version 2 and
124 141 Version 3 requests.
125 142
126 143 nosuid By default, clients are allowed to create files on
127 144 the shared file system with the setuid or setgid mode
128 145 enabled. Specifying nosuid causes the server file
129 146 system to silently ignore any attempt to enable the
130 147 setuid or setgid mode bits.
131 148
132 149 public Moves the location of the public file handle from
133 150 root (/) to the exported directory for WebNFS-enabled
134 151 browsers and clients. This option does not enable
135 152 WebNFS service; WebNFS is always on. Only one file
136 153 system per server may use this option. Any other
137 154 option, including the ro=list and rw=list options can
138 155 be included with the public option.
139 156
140 157 ro Sharing is read-only to all clients.
141 158
142 159 ro=access_list
143 160 Sharing is read-only to the clients listed in
144 161 access_list; overrides the rw suboption for the
145 162 clients specified. See access_list below.
146 163
147 164 root=access_list
148 165 Only root users from the hosts specified in
149 166 access_list have root access. See access_list below.
150 167 By default, no host has root access, so root users
151 168 are mapped to an anonymous user ID (see the anon=uid
152 169 option described above). Netgroups can be used if
153 170 the file system shared is using UNIX authentication
154 171 (AUTH_SYS).
155 172
156 173 root_mapping=uid
157 174 For a client that is allowed root access, map the
158 175 root UID to the specified user id.
159 176
160 177 rw Sharing is read-write to all clients.
161 178
162 179 rw=access_list
163 180 Sharing is read-write to the clients listed in
164 181 access_list; overrides the ro suboption for the
165 182 clients specified. See access_list below.
166 183
167 184 sec=mode[:mode]...
168 185 Sharing uses one or more of the specified security
169 186 modes. The mode in the sec=mode option must be a
170 187 mode name supported on the client. If the sec=
171 188 option is not specified, the default security mode
172 189 used is AUTH_SYS. Multiple sec= options can be
173 190 specified on the command line, although each mode can
174 191 appear only once. The security modes are defined in
175 192 nfssec(5).
176 193
177 194 Each sec= option specifies modes that apply to any
178 195 subsequent window=, rw, ro, rw=, ro=, and root=
179 196 options that are provided before another sec= option.
180 197 Each additional sec= resets the security mode
181 198 context, so that more window=, rw, ro, rw=, ro=, and
182 199 root= options can be supplied for additional modes.
183 200
184 201 sec=none If the option sec=none is specified when the client
185 202 uses AUTH_NONE, or if the client uses a security mode
186 203 that is not one that the file system is shared with,
187 204 then the credential of each NFS request is treated as
188 205 unauthenticated. See the anon=uid option for a
189 206 description of how unauthenticated requests are
190 207 handled.
191 208
192 209 secure This option has been deprecated in favor of the
193 210 sec=dh option.
194 211
195 212 uidmap=mapping[~mapping]...
196 213 Where mapping is: [clnt]:[srv]:access_list
197 214
198 215 Allows remapping the user ID (uid) in the incoming
199 216 request to some other uid. This effectively changes
200 217 the identity of the user in the request to that of
201 218 some other local user.
202 219
203 220 For clients where the uid in the incoming request is
204 221 clnt and the client matches the access_list, change
205 222 the user ID to srv. If clnt is asterisk (*), all
206 223 users are mapped by this rule. If clnt is omitted,
207 224 all unknown users are mapped by this rule. If srv is
208 225 set to -1, access is denied. If srv is omitted, the
209 226 uid is mapped to UID_NOBODY.
210 227
211 228 The particular mappings are separated in the uidmap=
212 229 option by tilde (~) and are evaluated in the
213 230 specified order until a match is found. Both root=
214 231 and root_mapping= options (if specified) are
215 232 evaluated before the uidmap= option. The uidmap=
216 233 option is skipped in the case where the client
217 234 matches the root= option.
218 235
219 236 The uidmap= option is evaluated before the anon=
220 237 option.
221 238
222 239 This option is supported only for AUTH_SYS.
223 240
224 241 window=value
225 242 When sharing with sec=dh, set the maximum life time
226 243 (in seconds) of the RPC request's credential (in the
227 244 authentication header) that the NFS server allows.
228 245 If a credential arrives with a life time larger than
229 246 what is allowed, the NFS server rejects the request.
230 247 The default value is 30000 seconds (8.3 hours).
231 248
232 249 access_list
233 250 The access_list argument is a colon-separated list whose components may
234 251 be any number of the following:
235 252
236 253 hostname The name of a host. With a server configured for DNS or LDAP
237 254 naming in the nsswitch hosts entry, any hostname must be
238 255 represented as a fully qualified DNS or LDAP name.
239 256
240 257 netgroup A netgroup contains a number of hostnames. With a server
241 258 configured for DNS or LDAP naming in the nsswitch hosts entry,
242 259 any hostname in a netgroup must be represented as a fully
243 260 qualified DNS or LDAP name.
244 261
245 262 domain name suffix
246 263 To use domain membership the server must use DNS or LDAP to
247 264 resolve hostnames to IP addresses; that is, the hosts entry in
248 265 the /etc/nsswitch.conf must specify dns or ldap ahead of nis
249 266 since only DNS and LDAP return the full domain name of the
250 267 host. Other name services like NIS cannot be used to resolve
251 268 hostnames on the server because when mapping an IP address to a
252 269 hostname they do not return domain information. For example,
253 270
254 271 NIS 172.16.45.9 --> "myhost"
255 272
256 273 and
257 274
258 275 DNS or LDAP 172.16.45.9 --> "myhost.mydomain.mycompany.com"
259 276
260 277 The domain name suffix is distinguished from hostnames and
261 278 netgroups by a prefixed dot. For example,
262 279
263 280 rw=.mydomain.mycompany.com
264 281
265 282 A single dot can be used to match a hostname with no suffix.
266 283 For example,
267 284
268 285 rw=.
269 286
270 287 matches "mydomain" but not "mydomain.mycompany.com". This
271 288 feature can be used to match hosts resolved through NIS rather
272 289 than DNS and LDAP.
273 290
274 291 network The network or subnet component is preceded by an at-sign (@).
275 292 It can be either a name or a dotted address. If a name, it is
276 293 converted to a dotted address by getnetbyname(3SOCKET). For
277 294 example,
278 295
279 296 =@mynet
280 297
281 298 would be equivalent to:
282 299
283 300 =@172.16 or =@172.16.0.0
284 301
285 302 The network prefix assumes an octet-aligned netmask determined
286 303 from the zeroth octet in the low-order part of the address up
287 304 to and including the high-order octet, if you want to specify a
288 305 single IP address (see below). In the case where network
289 306 prefixes are not byte-aligned, the syntax allows a mask length
290 307 to be specified explicitly following a slash (/) delimiter.
291 308 For example,
292 309
293 310 =@theothernet/17 or =@172.16.132/22
294 311
295 312 where the mask is the number of leftmost contiguous significant
296 313 bits in the corresponding IP address.
297 314
298 315 When specifying individual IP addresses, use the same @
299 316 notation described above, without a netmask specification. For
300 317 example:
301 318
302 319 =@172.16.132.14
303 320
304 321 Multiple, individual IP addresses would be specified, for
305 322 example, as:
306 323
307 324 root=@172.16.132.20:@172.16.134.20
308 325
309 326 A prefixed minus sign (-) denies access to that component of access_list.
310 327 The list is searched sequentially until a match is found that either
311 328 grants or denies access, or until the end of the list is reached. For
312 329 example, if host "terra" is in the "engineering" netgroup, then
313 330
314 331 rw=-terra:engineering
315 332
316 333 denies access to "terra" but
317 334
318 335 rw=engineering:-terra
319 336
320 337 grants access to "terra".
321 338
322 339 OPERANDS
323 340 The following operands are supported:
324 341
325 342 pathname The pathname of the file system to be shared.
326 343
327 344 FILES
328 345 /etc/dfs/fstypes list of system types, NFS by default
329 346
330 347 /etc/dfs/sharetab system record of shared file systems
331 348
332 349 /etc/nfs/nfslogtab system record of logged file systems
333 350
334 351 /etc/nfs/nfslog.conf logging configuration file
335 352
336 353 EXIT STATUS
337 354 The share_nfs utility exits 0 on success, and >0 if an error occurs.
338 355
339 356 EXAMPLES
340 357 Example 1 Sharing A File System With Logging Enabled
341 358 The following example shows the /export file system shared with logging
342 359 enabled:
343 360
344 361 share -o log /export
345 362
346 363 The default global logging parameters are used since no tag identifier is
347 364 specified. The location of the log file, as well as the necessary
348 365 logging work files, is specified by the global entry in
349 366 /etc/nfs/nfslog.conf. The nfslogd(1M) daemon runs only if at least one
350 367 file system entry in /etc/dfs/dfstab is shared with logging enabled upon
351 368 starting or rebooting the system. Simply sharing a file system with
352 369 logging enabled from the command line does not start the nfslogd(1M).
353 370
354 371 Example 2 Remap A User Coming From The Particular NFS Client
355 372 The following example remaps the user with uid 100 at client 10.0.0.1 to
356 373 user joe:
357 374
358 375 share -o uidmap=100:joe:@10.0.0.1 /export
359 376
360 377 SEE ALSO
361 378 mount(1M), mountd(1M), nfsd(1M), nfslogd(1M), share(1M), unshare(1M),
362 379 getnetbyname(3SOCKET), netgroup(4), nfslog.conf(4), acl(5),
363 380 attributes(5), nfssec(5)
364 381
365 382 NOTES
366 383 If the sec= option is presented at least once, all uses of the window=,
367 384 rw, ro, rw=, ro=, and root= options must come after the first sec=
368 385 option. If the sec= option is not presented, then sec=sys is implied.
369 386
370 387 If one or more explicit sec= options are presented, sys must appear in
371 388 one of the options mode lists for accessing using the AUTH_SYS security
372 389 mode to be allowed. For example:
373 390
374 391 share -F nfs /var
375 392 share -F nfs -o sec=sys /var
376 393
377 394 grants read-write access to any host using AUTH_SYS, but
378 395
379 396 share -F nfs -o sec=dh /var
380 397
381 398 grants no access to clients that use AUTH_SYS.
382 399
383 400 Unlike previous implementations of share_nfs, access checking for the
384 401 window=, rw, ro, rw=, and ro= options is done per NFS request, instead of
385 402 per mount request.
386 403
387 404 Combining multiple security modes can be a security hole in situations
388 405 where the ro= and rw= options are used to control access to weaker
389 406 security modes. In this example,
390 407
391 408 share -F nfs -o sec=dh,rw,sec=sys,rw=hosta /var
392 409
393 410 an intruder can forge the IP address for "hosta" (albeit on each NFS
394 411 request) to side-step the stronger controls of AUTH_DES. Something like:
395 412
396 413 share -F nfs -o sec=dh,rw,sec=sys,ro /var
397 414
398 415 is safer, because any client (intruder or legitimate) that avoids
399 416 AUTH_DES only gets read-only access. In general, multiple security modes
400 417 per share command should only be used in situations where the clients
401 418 using more secure modes get stronger access than clients using less
402 419 secure modes.
403 420
404 421 If rw= and ro= options are specified in the same sec= clause, and a
405 422 client is in both lists, the order of the two options determines the
406 423 access the client gets. If client "hosta" is in two netgroups, "group1"
407 424 and "group2", in this example, the client would get read-only access:
408 425
409 426 share -F nfs -o ro=group1,rw=group2 /var
410 427
411 428 In this example "hosta" would get read-write access:
412 429
413 430 share -F nfs -o rw=group2,ro=group1 /var
414 431
415 432 If within a sec= clause, both the ro and rw= options are specified, for
416 433 compatibility, the order of the options rule is not enforced. All hosts
417 434 would get read-only access, with the exception to those in the read-write
418 435 list. Likewise, if the ro= and rw options are specified, all hosts get
419 436 read-write access with the exceptions of those in the read-only list.
420 437
421 438 The ro= and rw= options are guaranteed to work over UDP and TCP but may
422 439 not work over other transport providers.
423 440
424 441 The root= option with AUTH_SYS is guaranteed to work over UDP and TCP but
425 442 may not work over other transport providers.
426 443
427 444 The root= option with AUTH_DES is guaranteed to work over any transport
428 445 provider.
429 446
430 447 There are no interactions between the root= option and the rw, ro, rw=,
431 448 and ro= options. Putting a host in the root list does not override the
432 449 semantics of the other options. The access the host gets is the same as
433 450 when the root= option is absent. For example, the following share
434 451 command denies access to "hostb":
435 452
436 453 share -F nfs -o ro=hosta,root=hostb /var
437 454
438 455 The following gives read-only permissions to "hostb":
439 456
440 457 share -F nfs -o ro=hostb,root=hostb /var
441 458
442 459 The following gives read-write permissions to "hostb":
443 460
444 461 share -F nfs -o ro=hosta,rw=hostb,root=hostb /var
445 462
446 463 If the file system being shared is a symbolic link to a valid pathname,
447 464 the canonical path (the path which the symbolic link follows) is shared.
448 465 For example, if /export/foo is a symbolic link to /export/bar, the
449 466 following share command results in /export/bar as the shared pathname
450 467 (and not /export/foo):
451 468
452 469 share -F nfs /export/foo
453 470
454 471 An NFS mount of server:/export/foo results in server:/export/bar really
455 472 being mounted.
456 473
457 474 This line in the /etc/dfs/dfstab file shares the /disk file system read-
458 475 only at boot time:
459 476
460 477 share -F nfs -o ro /disk
461 478
462 479 The mountd(1M) process allows the processing of a path name that contains
|
↓ open down ↓ |
350 lines elided |
↑ open up ↑ |
463 480 a symbolic link. This allows the processing of paths that are not
464 481 themselves explicitly shared with share_nfs. For example, /export/foo
465 482 might be a symbolic link that refers to /export/bar which has been
466 483 specifically shared. When the client mounts /export/foo the mountd
467 484 processing follows the symbolic link and responds with the /export/bar.
468 485 The NFS Version 4 protocol does not use the mountd processing and the
469 486 client's use of /export/foo does not work as it does with NFS Version 2
470 487 and Version 3 and the client receives an error when attempting to mount
471 488 /export/foo.
472 489
490 + The nohide option violates RFC 1094, Network File System Protocol
491 + Specification and RFC 1813, NFS: Network File System Version 3 Protocol
492 + Specification
493 +
494 + The nohide option is provided for compatibility with Linux NFS.
495 +
473 496 illumos March 23, 2017 illumos
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX