1share_nfs(1M) System Administration Commands share_nfs(1M)
2
6 share_nfs - make local NFS file systems available for mounting by
7 remote systems
8
10 share [-d description] [-F nfs] [-o specific_options] pathname
11
14 The share utility makes local file systems available for mounting by
15 remote systems. It starts the nfsd(1M) and mountd(1M) daemons if they
16 are not already running.
17 If no argument is specified, then share displays all file systems cur‐
20 rently shared, including NFS file systems and file systems shared
21 through other distributed file system packages.
22
24 The following options are supported:
25 -d description
27 Provide a comment that describes the file system to be shared.
29 -F nfs
32 Share NFS file system type.
34 -o specific_options
37 Specify specific_options in a comma-separated list of keywords and
39 attribute-value-assertions for interpretation by the file-system-
40 type-specific command. If specific_options is not specified, then
41 by default sharing is read-write to all clients. specific_options
42 can be any combination of the following:
43 aclok
45 Allows the NFS server to do access control for NFS Version 2
47 clients (running SunOS 2.4 or earlier). When aclok is set on
48 the server, maximal access is given to all clients. For exam‐
49 ple, with aclok set, if anyone has read permissions, then
50 everyone does. If aclok is not set, minimal access is given to
51 all clients.
52 anon=uid
55 Set uid to be the effective user ID of unknown users. By
57 default, unknown users are given the effective user ID
58 UID_NOBODY. If uid is set to −1, access is denied.
59 charset=access_list
62 Where charset is one of: euc-cn, euc-jp, euc-jpms, euc-kr, euc-
64 tw, iso8859-1, iso8859-2, iso8859-5, iso8859-6, iso8859-7,
65 iso8859-8, iso8859-9, iso8859-13, iso8859-15, koi8-r.
66 Clients that match the access_list for one of these properties
68 will be assumed to be using that character set and file and
69 path names will be converted to UTF-8 for the server.
70 index=file
73 Load file rather than a listing of the directory containing
75 this file when the directory is referenced by an NFS URL.
76 log=tag
79 Enables NFS server logging for the specified file system. The
81 optional tag determines the location of the related log files.
82 The tag is defined in etc/nfs/nfslog.conf. If no tag is speci‐
83 fied, the default values associated with the global tag in
84 etc/nfs/nfslog.conf is used. Support of NFS server logging is
85 only available for NFS Version 2 and Version 3 requests.
86 none=access_list
89 Access is not allowed to any client that matches the access
91 list. The exception is when the access list is an asterisk (*),
92 in which case ro or rw can override none.
93 nosub
96 Prevents clients from mounting subdirectories of shared direc‐
98 tories. For example, if /export is shared with the nosub option
99 on server fooey then a NFS client cannot do:
100 mount -F nfs fooey:/export/home/mnt
102 NFS Version 4 does not use the MOUNT protocol. The nosub option
105 only applies to NFS Version 2 and Version 3 requests.
106 nosuid
109 By default, clients are allowed to create files on the shared
111 file system with the setuid or setgid mode enabled. Specifying
112 nosuid causes the server file system to silently ignore any
113 attempt to enable the setuid or setgid mode bits.
114 public
117 Moves the location of the public file handle from root (/) to
119 the exported directory for WebNFS-enabled browsers and clients.
120 This option does not enable WebNFS service; WebNFS is always
121 on. Only one file system per server may use this option. Any
122 other option, including the -ro=list and -rw=list options can
123 be included with the public option.
124 ro
127 Sharing is read-only to all clients.
129 ro=access_list
132 Sharing is read-only to the clients listed in access_list;
134 overrides the rw suboption for the clients specified. See
135 access_list below.
136 root=access_list
139 Only root users from the hosts specified in access_list have
141 root access. See access_list below. By default, no host has
142 root access, so root users are mapped to an anonymous user ID
143 (see the anon=uid option described above). Netgroups can be
144 used if the file system shared is using UNIX authentication (
145 AUTH_SYS).
146 root_mapping=uid
149 For a client that is allowed root access, map the root UID to
151 the specified user id.
152 rw
155 Sharing is read-write to all clients.
157 rw=access_list
160 Sharing is read-write to the clients listed in access_list;
162 overrides the ro suboption for the clients specified. See
163 access_list below.
164 sec=mode[:mode]...
167 Sharing uses one or more of the specified security modes. The
169 mode in the sec=mode option must be a node name supported on
170 the client. If the sec= option is not specified, the default
171 security mode used is AUTH_SYS. Multiple sec= options can be
172 specified on the command line, although each mode can appear
173 only once. The security modes are defined in nfssec(5).
174 Each sec= option specifies modes that apply to any subsequent
176 window=, rw, ro, rw=, ro= and root= options that are provided
177 before another sec=option. Each additional sec= resets the
178 security mode context, so that more window=, rw, ro, rw=, ro=
179 and root= options can be supplied for additional modes.
180 sec=none
183 If the option sec=none is specified when the client uses
185 AUTH_NONE, or if the client uses a security mode that is not
186 one that the file system is shared with, then the credential of
187 each NFS request is treated as unauthenticated. See the
188 anon=uid option for a description of how unauthenticated
189 requests are handled.
190 secure
193 This option has been deprecated in favor of the sec=dh option.
195 window=value
198 When sharing with sec=dh, set the maximum life time (in sec‐
200 onds) of the RPC request's credential (in the authentication
201 header) that the NFS server allows. If a credential arrives
202 with a life time larger than what is allowed, the NFS server
203 rejects the request. The default value is 30000 seconds (8.3
204 hours).
205 access_list
209 The access_list argument is a colon-separated list whose components may
210 be any number of the following:
211 hostname
213 The name of a host. With a server configured for DNS or LDAP naming
215 in the nsswitch "hosts" entry, any hostname must be represented as
216 a fully qualified DNS or LDAP name.
217 netgroup
220 A netgroup contains a number of hostnames. With a server configured
222 for DNS or LDAP naming in the nsswitch "hosts" entry, any hostname
223 in a netgroup must be represented as a fully qualified DNS or LDAP
224 name.
225 domain name suffix
228 To use domain membership the server must use DNS or LDAP to resolve
230 hostnames to IP addresses; that is, the "hosts" entry in the
231 /etc/nsswitch.conf must specify "dns" or "ldap" ahead of "nis" or
232 "nisplus", since only DNS and LDAP return the full domain name of
233 the host. Other name services like NIS or NIS+ cannot be used to
234 resolve hostnames on the server because when mapping an IP address
235 to a hostname they do not return domain information. For example,
236 NIS or NIS+ 172.16.45.9 --> "myhost"
238 and
241 DNS or LDAP 172.16.45.9 -->
243 "myhost.mydomain.mycompany.com"
244 The domain name suffix is distinguished from hostnames and net‐
247 groups by a prefixed dot. For example,
248 rw=.mydomain.mycompany.com
250 A single dot can be used to match a hostname with no suffix. For
252 example,
253 rw=.
255 matches "mydomain" but not "mydomain.mycompany.com". This feature
257 can be used to match hosts resolved through NIS and NIS+ rather
258 than DNS and LDAP.
259 network
262 The network or subnet component is preceded by an at-sign (@). It
264 can be either a name or a dotted address. If a name, it is con‐
265 verted to a dotted address by getnetbyname(3SOCKET). For example,
266 =@mynet
268 would be equivalent to:
270 =@172.16 or =@172.16.0.0
272 The network prefix assumes an octet-aligned netmask determined from
274 the zeroth octet in the low-order part of the address up to and
275 including the high-order octet, if you want to specify a single IP
276 address (see below). In the case where network prefixes are not
277 byte-aligned, the syntax allows a mask length to be specified
278 explicitly following a slash (/) delimiter. For example,
279 =@theothernet/17 or =@172.16.132/22
281 ...where the mask is the number of leftmost contiguous significant
283 bits in the corresponding IP address.
284 When specifying individual IP addresses, use the same @ notation
286 described above, without a netmask specification. For example:
287 =@172.16.132.14
289 Multiple, individual IP addresses would be specified, for example,
292 as:
293 root=@172.16.132.20:@172.16.134.20
295 A prefixed minus sign (−) denies access to that component of
301 access_list. The list is searched sequentially until a match is found
302 that either grants or denies access, or until the end of the list is
303 reached. For example, if host "terra" is in the "engineering" netgroup,
304 then
305 rw=-terra:engineering
307 denies access to terra but
312 rw=engineering:-terra
314 grants access to terra.
319
321 The following operands are supported:
322 pathname
324 The pathname of the file system to be shared.
326
329 Example 1 Sharing A File System With Logging Enabled
330 The following example shows the /export file system shared with logging
333 enabled:
334 example% share -o log /export
337 The default global logging parameters are used since no tag identifier
342 is specified. The location of the log file, as well as the necessary
343 logging work files, is specified by the global entry in /etc/nfs/nfs‐
344 log.conf. The nfslogd(1M) daemon runs only if at least one file system
345 entry in /etc/dfs/dfstab is shared with logging enabled upon starting
346 or rebooting the system. Simply sharing a file system with logging
347 enabled from the command line does not start the nfslogd(1M).
348
351 The following exit values are returned:
352 0
354 Successful completion.
356 >0
359 An error occurred.
361
364 /etc/dfs/fstypes
365 list of system types, NFS by default
367 /etc/dfs/sharetab
370 system record of shared file systems
372 /etc/nfs/nfslogtab
375 system record of logged file systems
377 /etc/nfs/nfslog.conf
380 logging configuration file
382
385 See attributes(5) for descriptions of the following attributes:
386 ┌─────────────────────────────┬─────────────────────────────┐
391 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
392 ├─────────────────────────────┼─────────────────────────────┤
393 │Availability │SUNWnfssu │
394 └─────────────────────────────┴─────────────────────────────┘
395
397 mount(1M), mountd(1M), nfsd(1M), nfslogd(1M), share(1M), unshare(1M),
398 getnetbyname(3SOCKET), nfslog.conf(4), netgroup(4), attributes(5),
399 nfssec(5)
400
402 If the sec= option is presented at least once, all uses of the window=,
403 rw, ro, rw=, ro= and root= options must come after the first sec=
404 option. If the sec= option is not presented, then sec=sys is implied.
405 If one or more explicit sec= options are presented, sys must appear in
408 one of the options mode lists for accessing using the AUTH_SYS security
409 mode to be allowed. For example:
410 share -F nfs /var
412 share -F nfs -o sec=sys /var
413 grants read-write access to any host using AUTH_SYS, but
418 share -F nfs -o sec=dh /var
420 grants no access to clients that use AUTH_SYS.
425 Unlike previous implementations of share_nfs, access checking for the
428 window=, rw, ro, rw=, and ro= options is done per NFS request, instead
429 of per mount request.
430 Combining multiple security modes can be a security hole in situations
433 where the ro= and rw= options are used to control access to weaker
434 security modes. In this example,
435 share -F nfs -o sec=dh,rw,sec=sys,rw=hosta /var
437 an intruder can forge the IP address for hosta (albeit on each NFS
442 request) to side-step the stronger controls of AUTH_DES. Something
443 like:
444 share -F nfs -o sec=dh,rw,sec=sys,ro /var
446 is safer, because any client (intruder or legitimate) that avoids
451 AUTH_DES only gets read-only access. In general, multiple security
452 modes per share command should only be used in situations where the
453 clients using more secure modes get stronger access than clients using
454 less secure modes.
455 If rw=, and ro= options are specified in the same sec= clause, and a
458 client is in both lists, the order of the two options determines the
459 access the client gets. If client hosta is in two netgroups - group1
460 and group2 - in this example, the client would get read-only access:
461 share -F nfs -o ro=group1,rw=group2 /var
463 In this example hosta would get read-write access:
468 share -F nfs -o rw=group2,ro=group1 /var
470 If within a sec= clause, both the ro and rw= options are specified, for
475 compatibility, the order of the options rule is not enforced. All hosts
476 would get read-only access, with the exception to those in the read-
477 write list. Likewise, if the ro= and rw options are specified, all
478 hosts get read-write access with the exceptions of those in the read-
479 only list.
480 The ro= and rw= options are guaranteed to work over UDP and TCP but may
483 not work over other transport providers.
484 The root= option with AUTH_SYS is guaranteed to work over UDP and TCP
487 but may not work over other transport providers.
488 The root= option with AUTH_DES is guaranteed to work over any transport
491 provider.
492 There are no interactions between the root= option and the rw, ro, rw=,
495 and ro= options. Putting a host in the root list does not override the
496 semantics of the other options. The access the host gets is the same as
497 when the root= options is absent. For example, the following share com‐
498 mand denies access to hostb:
499 share -F nfs -o ro=hosta,root=hostb /var
501 The following gives read-only permissions to hostb:
506 share -F nfs -o ro=hostb,root=hostb /var
508 The following gives read-write permissions to hostb:
513 share -F nfs -o ro=hosta,rw=hostb,root=hostb /var
515 If the file system being shared is a symbolic link to a valid pathname,
520 the canonical path (the path which the symbolic link follows) are
521 shared. For example, if /export/foo is a symbolic link to /export/bar
522 (/export/foo -> /export/bar), the following share command results in
523 /export/bar as the shared pathname (and not /export/foo).
524 example# share -F nfs /export/foo
526 An NFS mount of server:/export/foo results in server:/export/bar really
531 being mounted.
532 This line in the /etc/dfs/dfstab file shares the /disk file system
535 read-only at boot time:
536 share -F nfs -o ro /disk
538 The same command entered from the command line does not share the /disk
543 file system unless there is at least one file system entry in the
544 /etc/dfs/dfstab file. The mountd(1M) and nfsd(1M) daemons only run if
545 there is a file system entry in /etc/dfs/dfstab when starting or
546 rebooting the system.
547 The mountd(1M) process allows the processing of a path name the con‐
550 tains a symbolic link. This allows the processing of paths that are not
551 themselves explicitly shared with share_nfs. For example, /export/foo
552 might be a symbolic link that refers to /export/bar which has been
553 specifically shared. When the client mounts /export/foo the mountd pro‐
554 cessing follows the symbolic link and responds with the /export/bar.
555 The NFS Version 4 protocol does not use the mountd processing and the
556 client's use of /export/foo does not work as it does with NFS Version 2
557 and Version 3 and the client receives an error when attempting to mount
558 /export/foo.
559SunOS 5.11 6 May 2009 share_nfs(1M)