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