shareutility makes local file systems available for mounting by remote systems. It starts the nfsd(1M) and mountd(1M) daemons if they are not already running.
If no argument is specified, then
displays all file systems currently shared, including NFS file systems and
file systems shared through other distributed file system packages.
Clients that match the access_list for one of these properties will be assumed to be using that character set and file and path names will be converted to UTF-8 for the server.
Allows remapping the group ID (gid) in the incoming request to some other gid. This effectively changes the identity of the user in the request to that of some other local user.
For clients where the gid in the incoming request is clnt and the client matches the access_list, change the group ID to srv. If clnt is asterisk (*), all groups are mapped by this rule. If clnt is omitted, all unknown groups are mapped by this rule. If srv is set to -1, access is denied. If srv is omitted, the gid is mapped to UID_NOBODY.
The particular mappings are separated in the gidmap= option by tilde (~) and are evaluated in the specified order until a match is found. Both root= and root_mapping= options (if specified) are evaluated before the gidmap= option. The gidmap= option is skipped in the case where the client matches the root= option.
The gidmap= option is evaluated before the anon= option.
This option is supported only for AUTH_SYS.
Setting the nohide option on a filesystem causes it to no longer be hidden in this manner, and the client will be able to move from the parent filesystem to this one without noticing the change. However, some NFS clients or applications may not function correctly when this option is used. In particular, files on different underlying filesystems may appear to have the same inode numbers. The nohide option only applies to NFS Version 2 and Version 3 requests.
mount -F nfs fooey:/export/home/mnt
NFS Version 4 does not use the MOUNT protocol. The nosub option only applies to NFS Version 2 and Version 3 requests.
Each sec= option specifies modes that apply to any subsequent window=, rw, ro, rw=, ro=, and root= options that are provided before another sec= option. Each additional sec= resets the security mode context, so that more window=, rw, ro, rw=, ro=, and root= options can be supplied for additional modes.
Allows remapping the user ID (uid) in the incoming request to some other uid. This effectively changes the identity of the user in the request to that of some other local user.
For clients where the uid in the incoming request is clnt and the client matches the access_list, change the user ID to srv. If clnt is asterisk (*), all users are mapped by this rule. If clnt is omitted, all unknown users are mapped by this rule. If srv is set to -1, access is denied. If srv is omitted, the uid is mapped to UID_NOBODY.
The particular mappings are separated in the uidmap= option by tilde (~) and are evaluated in the specified order until a match is found. Both root= and root_mapping= options (if specified) are evaluated before the uidmap= option. The uidmap= option is skipped in the case where the client matches the root= option.
The uidmap= option is evaluated before the anon= option.
This option is supported only for AUTH_SYS.
NIS 172.16.45.9 --> "myhost"
DNS or LDAP 172.16.45.9 --> "myhost.mydomain.mycompany.com"
The domain name suffix is distinguished from hostnames and netgroups by a prefixed dot. For example,
A single dot can be used to match a hostname with no suffix. For example,
matches “mydomain” but not “mydomain.mycompany.com”. This feature can be used to match hosts resolved through NIS rather than DNS and LDAP.
would be equivalent to:
=@172.16 or =@172.16.0.0
The network prefix assumes an octet-aligned netmask determined from the zeroth octet in the low-order part of the address up to and including the high-order octet, if you want to specify a single IP address (see below). In the case where network prefixes are not byte-aligned, the syntax allows a mask length to be specified explicitly following a slash (/) delimiter. For example,
=@theothernet/17 or =@172.16.132/22
where the mask is the number of leftmost contiguous significant bits in the corresponding IP address.
When specifying individual IP addresses, use the same @ notation described above, without a netmask specification. For example:
Multiple, individual IP addresses would be specified, for example, as:
A prefixed minus sign (-) denies access to that component of access_list. The list is searched sequentially until a match is found that either grants or denies access, or until the end of the list is reached. For example, if host “terra” is in the “engineering” netgroup, then
denies access to “terra” but
grants access to “terra”.
share_nfsutility exits 0 on success, and >0 if an error occurs.
share -o log /export
The default global logging parameters are used since no tag identifier is specified. The location of the log file, as well as the necessary logging work files, is specified by the global entry in /etc/nfs/nfslog.conf. The nfslogd(1M) daemon runs only if at least one file system entry in /etc/dfs/dfstab is shared with logging enabled upon starting or rebooting the system. Simply sharing a file system with logging enabled from the command line does not start the nfslogd(1M).
share -o uidmap=100:joe:@10.0.0.1 /export
If one or more explicit sec= options are presented, sys must appear in one of the options mode lists for accessing using the AUTH_SYS security mode to be allowed. For example:
share -F nfs /var share -F nfs -o sec=sys /var
grants read-write access to any host using AUTH_SYS, but
share -F nfs -o sec=dh /var
grants no access to clients that use AUTH_SYS.
Unlike previous implementations of
share_nfs, access checking for the
window=, rw, ro,
rw=, and ro= options is done per NFS
request, instead of per mount request.
Combining multiple security modes can be a security hole in situations where the ro= and rw= options are used to control access to weaker security modes. In this example,
share -F nfs -o sec=dh,rw,sec=sys,rw=hosta /var
an intruder can forge the IP address for “hosta” (albeit on each NFS request) to side-step the stronger controls of AUTH_DES. Something like:
share -F nfs -o sec=dh,rw,sec=sys,ro /var
is safer, because any client (intruder or legitimate) that avoids AUTH_DES only gets read-only access. In general, multiple security modes per share command should only be used in situations where the clients using more secure modes get stronger access than clients using less secure modes.
If rw= and ro= options are specified in the same sec= clause, and a client is in both lists, the order of the two options determines the access the client gets. If client “hosta” is in two netgroups, “group1” and “group2”, in this example, the client would get read-only access:
share -F nfs -o ro=group1,rw=group2 /var
In this example “hosta” would get read-write access:
share -F nfs -o rw=group2,ro=group1 /var
If within a sec= clause, both the ro and rw= options are specified, for compatibility, the order of the options rule is not enforced. All hosts would get read-only access, with the exception to those in the read-write list. Likewise, if the ro= and rw options are specified, all hosts get read-write access with the exceptions of those in the read-only list.
The ro= and rw= options are guaranteed to work over UDP and TCP but may not work over other transport providers.
The root= option with AUTH_SYS is guaranteed to work over UDP and TCP but may not work over other transport providers.
The root= option with AUTH_DES is guaranteed to work over any transport provider.
There are no interactions between the root= option and the rw, ro, rw=, and ro= options. Putting a host in the root list does not override the semantics of the other options. The access the host gets is the same as when the root= option is absent. For example, the following share command denies access to “hostb”:
share -F nfs -o ro=hosta,root=hostb /var
The following gives read-only permissions to “hostb”:
share -F nfs -o ro=hostb,root=hostb /var
The following gives read-write permissions to “hostb”:
share -F nfs -o ro=hosta,rw=hostb,root=hostb /var
If the file system being shared is a symbolic link to a valid pathname, the canonical path (the path which the symbolic link follows) is shared. For example, if /export/foo is a symbolic link to /export/bar, the following share command results in /export/bar as the shared pathname (and not /export/foo):
share -F nfs /export/foo
This line in the /etc/dfs/dfstab file shares the /disk file system read-only at boot time:
share -F nfs -o ro /disk
The mountd(1M) process
allows the processing of a path name that contains a symbolic link. This
allows the processing of paths that are not themselves explicitly shared
share_nfs. For example,
/export/foo might be a symbolic link that refers to
/export/bar which has been specifically shared. When
the client mounts /export/foo the mountd processing
follows the symbolic link and responds with the
/export/bar. The NFS Version 4 protocol does not use
the mountd processing and the client's use of
/export/foo does not work as it does with NFS
Version 2 and Version 3 and the client receives an error when attempting to
The nohide option violates RFC 1094, Network File System Protocol Specification and RFC 1813, NFS: Network File System Version 3 Protocol Specification
The nohide option is provided for compatibility with Linux NFS.
|March 23, 2017||OmniOS|