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