zfs share -o share.nfs=on | off specific_options
The share utility defines and publishes a NFS share,
which makes a local file system available for mounting by remote systems.
It starts the nfsd(8) and mountd(8) daemons if they are not already
You can use the share command to create and publish
a ZFS file system share, but this is considered a legacy operation. See zfs(8) for information about setting
the share.nfs property or using the zfs share command
to create and publish NFS shares.
The following options are supported:
Specify the NFS file sharing protocol.
Publish all defined shares.
Specify specific_options in a comma-separated
list of keywords and attribute-value-assertions for interpretation by the
NFS protocol. By default, a share is published with read-write access to all
clients, unless a specific option overrides the default access. specific_options
can be any combination of the following:
Allows the NFS server to do access control for NFS
Version 2 clients. When aclok is set
on the server, maximal access is given to all clients.
For example, with aclok set, if
anyone has read permissions, then everyone does. If
aclok is not set, minimal
access is given to all clients.
Set uid to be the effective user ID of unknown
users. By default, unknown users are given the
effective user ID
If uid is set to -1, when
using NFSv3, unknown users will be denied access. All
NFSv4 mount attempts will also be denied.
All clients will be assumed to be using the specified character
set (see list in following description) and file and path names will be converted
to UTF-8 for the server.
Where charset is one of: cp932,
euc-cn, euc-jp, euc-jpms,
euc-kr, euc-tw, iso8859-1,
iso8859-2, iso8859-5, iso8859-6,
iso8859-7, iso8859-8, iso8859-9,
iso8859-13, iso8859-15, koi8-r,
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.
Load file rather than a listing of the
directory containing this file when the directory is referenced by an NFS
By default only unlabeled files are available to NFS
clients. When this option is enabled, access may be
granted to files and directories whose labels are
dominated by the user's clearance. The user's clearance
is retrieved from the NFS server's name service after
mapping the NFS client's identity to a local identity.
This option requires that the service
Enables NFS server logging for the specified file system. The optional tag
determines the location of the related log files. The
tag is defined in
/etc/nfs/nfslog.conf. If no
tag is specified, the
default values associated with the
/etc/nfs/nfslog.conf is used.
Support of NFS server logging is only available for NFS
Version 2 and Version 3 requests.
Allows NFS servers to not return fabricated ACLs to NFS clients.
The default behavior for NFS servers is to fabricate ACLs. If noaclfab is
set, then the NFS server does not fabricate ACLs, which is the appropriate
choice if the underlying filesystem does not support the POSIX Draft ACL.
Access is disallowed to all clients. The ro or rw
options can override none.
Access is not allowed to any client that matches the access list. The exception is when the
access list is an asterisk (*), in
which case ro or
rw can override
Prevents clients from mounting subdirectories of shared directories.
For example, if /export is shared with the nosub option
on server fooey then a NFS client
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.
By default, clients are allowed to create files on the shared file system with the
setgid mode enabled. Specifying
nosuid causes the server file
system to silently ignore any attempt to enable the
setgid mode bits.
Moves the location of the public file handle from root
(/) to the exported directory
for WebNFS-enabled browsers and
clients. This option does not enable
WebNFS is always on. Only one
file system per server may use this option. Any other
option, including the –ro=list and
–rw=list options can be included
with the public option.
Share is published with read-only access to all clients.
Share is published with read-only access to the clients listed in
the rw suboption for the clients
specified. Note that if a client matches a member of
as well, then the client is published with read and
write access. See
Root users from all hosts have root access.
Only root users from the hosts specified in access_list have root
access. See access_list
below. By default, no host has root access, so root
users are mapped to an anonymous user
ID (see the
option described above). Netgroups can be used if the
file system shared is using UNIX authentication
For a client that is allowed root access, map the root UID to the specified user ID.
Share is published with read and write access to all clients.
Share is published with read and write access to the clients
listed in access_list; overrides the ro suboption
for the clients specified. See access_list below.
:mode]. . .
Publishes a share by using one or more of the specified security
modes. The mode in the sec=
mode option must be a node name supported on the client. If
the sec= option is not specified, the default security
mode used is AUTH_SYS. Multiple sec= options
can be specified on the command line, although each mode can appear only once.
The security modes are defined in nfssec(7).
Each sec= option specifies modes that apply to any subsequent 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 rw,
root= options can be supplied
for additional modes.
If the option sec=none is
specified when the client uses AUTH_NONE, or if the client
uses a security mode that is not one that the file system is shared with,
then the credential of each NFS request is treated as unauthenticated.
See the anon=uid option for
a description of how unauthenticated requests are handled.
Provide a comment that describes the file system to be shared.
Display all defined shares.
The access_list argument is either the string “
*” to represent all hosts or a colon-separated list whose
components may be any number of the following:
The name of a host. With a server configured for DNS or
LDAP naming in the nsswitchhosts entry,
any hostname must be represented as a fully qualified DNS or
LDAP name. The hostname specified must be the canonical name for
this host and must match the hostname returned on the reverse lookup of the
incoming IP address of the NFS client.
A netgroup contains a number of hostnames. With a server configured
for DNS or LDAP naming in the nsswitch
hosts entry, any hostname in a netgroup must
be represented as a fully qualified DNS or LDAP name.
If the explicit_netgroups setting is enabled, netgroup
entries in share access lists must be prefixed with the '%' character to
distinguish them from hostnames. See
for a description of the explicit_netgroups setting.
domain name suffix
To use domain membership the server must use DNS or
LDAP to resolve hostnames to IP addresses; that
is, the hosts entry in the /etc/nsswitch.conf must
specify dns or ldap ahead of nis,
since only DNS and LDAP return the full
domain name of the host. Other name services like NIS cannot
be used to resolve hostnames on the server because when mapping an IP address
to a hostname they do not return domain information. For example,
NIS 172.16.45.9 --> "myhost"
DNS or LDAP 172.16.45.9 -->
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.example.com
. This feature can be used to match hosts resolved through NIS
rather than DNS and LDAP.
The network or subnet component is preceded by an at-sign
(@). It can be a name, an IPv4 or IPv6 address. If a name,
it is converted to an address by getnetbyname(3C). For example,
would be equivalent to:
=@172.16 or =@172.16.0.0
For an IPv4 address, 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 left most contiguous significant
bits in the corresponding IP address.
For an IPv6 address, the address must be enclosed in a pair of square
brackets. Otherwise, the first occurrence of an IPv6 colon would be interpreted
as the separator between the addresses.
Network mask length is specified explicitly following a slash (/) delimiter.
...where the mask is the number of left most contiguous significant
bits in the corresponding IP network 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.
The following operands are supported:
The pathname of the file system to be shared.
Example 1 Define and Publish an NFS Share
The following example shows how to use the legacy share
command to define and publish the /export/manuals file
# share -F NFS /export/manuals
The following example shows how to use the zfs set command
to share a ZFS file system.
# zfs set share.nfs=on tank/data
The following example shows how to create a named NFS share,
tank/public%pubshare, with the
share.nfs.public option rather than setting this option
on the ZFS file system, tank/public, because this property is
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 (/export/foo -> /export/bar),
the following share command results in
/export/bar as the shared pathname, and not
# share –F nfs /export/foo
If the client attempts to mount server:/export/foo, the results
depend on the version of the NFS protocol that is used. With NFS Version 2 and
Version 3, the effect will be as though the client has tried to mount
With NFS Version 4, the situation is more complicated. If the symbolic link itself
is in a directory that is shared, the effect will be as though the client has tried
to mount server:/export/bar. If the symbolic link is located in a
directory that is not shared, the client will receive an error.