| SHAREMGR(8) | Maintenance Commands and Procedures | SHAREMGR(8) |
sharemgr subcommand [options]
add-share [-nth] [-r resource-name] [-d "description text"] -s sharepath group
create [-nvh] [-P proto [-p property=value]] group
delete [-nvh] [-P proto] [-f] group
disable [-nvh] [-a | group...]
enable [-nvh] [-a | group...]
list [-vh] [-P proto]
move-share [-nv] -s sharepath destination-group
remove-share [-fnvh] -s sharepath group
set [-nvh] -P proto [-p property=value]... [-S optionset] [-s sharepath] group
set-share [-nh] [-r resource] [-d "description text"] -s sharepath group
show [-pvxh] [-P proto] [group]...
unset [-nvh] -P proto [-S optionset] [-p property]... group
share [-F fstype] [-p] [-o optionlist] [-d description] [pathname [resourcename]]
unshare [-F fstype] [-p] [-o optionlist] sharepath
A group name must conform to service management facility (SMF) (see smf(7)) service-naming conventions, thus is limited to starting with an alphabetic character, with the rest of the name consisting only of alphanumeric characters plus - (hyphen) and _ (underbar).
Subcommands that result in a configuration change support a dry-run option. When dry-run (-n) is specified, the syntax and validity of the command is tested but the configuration is not actually updated.
For all subcommands, the -h option lists usage and help information.
For subcommands with the verbose (-v) option, additional information will be provided. For example, in conjunction with the -n option, verbose mode will also indicate whether the current user has sufficient permissions to accomplish the operation.
There are two groups that are created automatically. The default group always exists and covers legacy NFS shares only. The zfs group will be created when ZFS shares are enabled.
The options shown in the SYNOPSIS section are described in the context of each subcommand. All subcommands except list and show require root privileges or that you assume the Primary Administrator role.
The following subcommands follow sharemgr on a command line. Commands take the form:
% sharemgr <subcommand> [options]
create [-nvh] [-P proto [-p property=value]] group
If -n is specified, the command checks only the validity of the command and that the group does not already exist.
If no protocol is specified, all known protocols are enabled for the specified group. If a protocol is specified, only that protocol is enabled. You can specify properties for a specified protocol.
If group exists, use of -P adds the specified protocol to that group.
As an example of the create subcommand, the following command creates a new group with the name mygroup.
# sharemgr create mygroup
Because no protocol was specified in the preceding command, all defined protocols will be enabled on the group.
delete [-nvh] [-P proto] [-f] group
If you specify a protocol, rather than deleting the whole group, this subcommand deletes the protocol from the group.
The -n option can be used to test the syntax of the command.
As an example, the following command removes the group mygroup from the configuration if it is empty.
# sharemgr delete mygroup
The following command removes any existing shares prior to removing the group.
# sharemgr delete -f mygroup
Note the use of the force (-f) option, above.
list [-vh] [-P proto]
If a protocol is specified, list only those groups that have the specified protocol defined.
If the verbose option is specified, the current state of the group and all protocols enabled on the group are listed as well. For example:
# sharemgr list -v mygroup enabled nfs rdonlygrp disabled nfs
show [-pvxh] [-P proto] [group...]
If the verbose option is specified, the resource name and description of each share is displayed if they are defined. Otherwise, only the share paths are displayed. Also, when temporary shares are listed, they are prefixed with an asterisk (*).
If the -p option is specified, all options defined for the protocols of the group are displayed, in addition to the display without options. If the -P option is used, the output is limited to those groups that have the specified protocol enabled. If the -x option is specified, output is in XML format and the -p and -v options are ignored, because all information is included in the XML.
The following example illustrates the use of the -p option.
# sharemgr show -p mygroup
default nfs=()
* /data/backup
mygroup nfs=(nosuid=true)
/export/home/home0
/export/home/home1
The following example illustrates the use of the -v option.
# sharemgr show -v mygroup
mygroup
HOME0=/export/home/home0 "Home directory set 0"
HOME1=/export/home/home1 "Home directory set 1"
ZFS managed shares are handled in a way similar to the way NFS shares are handled. These shares appear as subgroups within the parent group zfs. The subgroups are always prefixed with zfs/ and use the ZFS dataset name for the rest of the name. The mount point and any sub-mounts that inherit sharing are shown as the shares of the subgroup. For example:
# sharemgr show -vp zfs
zfs nfs=()
zfs/ztest
/ztest
/ztest/backups
set [-nvh] -P proto [-S optionset] [-p property=value]* [-s share path] group
The -P option is required and must specify a valid protocol.
Optionsets are protocol-specific sets of properties that can be negotiated by the protocol client. For NFS, optionsets are equivalent to security modes as defined in nfssec(7). If -S optionset is specified, the properties are applied to the selected optionset. Otherwise they are applied to the general optionset.
Together, -P and -S select a specific view of the group's options on which to work.
Property values are strings. A specified property is set to a new value if the property already exists or is added to the protocol if it does not already exist.
In the general case, at least one property must be set. If -S is specified, properties can be omitted and the specified optionset is enabled for the protocol.
The -s option allows setting properties on a per-share basis. While this is supported, it should be limited to managing legacy shares and to the occasional need for an override of a group-level property or placing an additional property on one share within a group.
An example of this subcommand:
# sharemgr set -P nfs -p anon=1234 mygroup
The preceding command adds the property anon=1234 to the nfs view of group mygroup. If mygroup has existing shares, they will all be reshared with the new property value(s).
unset [-nvh] -P proto [-S optionset] [-p property]* [-s sharepath ] group
In the general case, at least one property must be set. If -S is specified, properties can be omitted and the specified optionset is removed from the protocol.
The -s option allows removing a share-specific property.
An example of this subcommand:
# sharemgr unset -P nfs -p anon mygroup
The preceding command removes the anon= property from the nfs view of group mygroup. If mygroup has existing shares, they will all be reshared with the new property value(s).
add-share [-nth] [-r resource-name] [-d "description text"] -s sharepath group
The -s option is mandatory and takes a full directory path.
If either or both of -d and -r are specified, they specify values associated with the share. -d provides a description string to document the share and -r provides a protocol-independent resource name. Resource names are not used by NFS at this time but can be specified. These names currently follow the same naming rules as group names.
The temporary option (-t) results in the share being shared but not stored in the configuration repository. This option is intended for shares that should not survive a reboot or server restart, or for testing purposes. Temporary shares are indicated in the show subcommand output with an asterisk (*) preceding the share.
If sharepath is a ZFS path and that path is added to the zfs group, sharemgr creates a new ZFS subgroup; the new share is added to that subgroup. Any ZFS sub-filesystems under the ZFS filesystem designated by sharepath will inherit the shared status of sharepath.
The effect of the add-share subcommand on a ZFS dataset is determined by the values of the sharesmb and sharenfs properties of that dataset.
See zfs(8) for a description of the sharesmb and sharenfs properties.
The following are examples of the add-share subcommand.
# sharemgr add-share -s /export/home/home0 -d "home \ directory set 0" -r HOME0 mygroup # sharemgr add-share -s /export/home/home1 -d "home \ directory set 1" -r HOME1 mygroup
The preceding commands add /export/home/home0 and /export/home/home1 to the group mygroup. A descriptive comment and a resource name are included.
move-share [-nvh] -s sharepath destination-group
The following is an example of this subcommand.
# sharemgr move-share -s /export/home/home1 newgroup
Assuming /export/home/home1 is in the group mygroup, the preceding command moves /export/home/home1 to the group newgroup and unshares and then reshares the directory with the properties associated with newgroup.
remove-share [-fnvh] -s sharepath group
You must specify the full path for sharepath. For group, use the subgroup as displayed in the output of the sharemgr show command. Note that if there are subshares that were created by inheritance, these will be removed, along with the parent shares.
set-share [-nvh] [-r resource] [-d "description text"] -s sharepath group
# sharemgr set-share -r current_name=new_name -s sharepath group
enable [-nvh] [group... | -a]
An enabled group will be shared whenever the corresponding SMF service instance is enabled. sharemgr will start the SMF service instance if it is not currently online.
disable [-nvh] [group... | -a]
A disabled group will not be shared even if the corresponding SMF service instance is online. This feature is useful when you do not want a group of shares to be started at boot time.
start [-vh] [-P proto] [group... | -a]
A group will not start sharing if it is in the sharemgr disabled state. However, the corresponding SMF service instance will be started.
Note that the start subcommand is similar to the shareall(8) command in that it starts up only the configured shares. That is, the enabled shares will start being shared, but the configuration state is left the same. The command:
# sharemgr start -a
...is equivalent to:
# shareall
stop [-vh] [-P proto] [group... | -a]
Note that the stop subcommand is similar to the unshareall(8) command in that all active shares are unshared, but the configuration is left the same. That is, the shares are stopped but the service instances are left enabled. The command:
# sharemgr stop -a
...is equivalent to:
# unshareall
share [-F fstype] [-p] [-o optionlist] [-d description] [pathname [resourcename]]
unshare [-F fstype] [-p] [-o optionlist] sharepath
The general properties supported for NFS are:
abe=boolean
disabled
enabled
aclok=boolean
ad-container
The AD container is specified as a comma-separated list of attribute name-value pairs using the LDAP distinguished name (DN) or relative distinguished name (RDN) format. The DN or RDN must be specified in LDAP format using the cn=, ou=, and dc= prefixes:
anon=uid
catia=boolean
If the catia property is set to true, the following character substitution is applied to file names.
CATIA CATIA V4 UNIX V5 Windows " \250 0x00a8 Dieresis * \244 0x00a4 Currency Sign / \370 0x00f8 Latin Small Letter O with Stroke : \367 0x00f7 Division Sign < \253 0x00ab Left-Pointing Double Angle Quotation Mark > \273 0x00bb Right-Pointing Double Angle Quotation Mark ? \277 0x00bf Inverted Question Mark \ \377 0x00ff Latin Small Letter Y with Dieresis | \246 0x00a6 Broken Bar
cksum=cksumlist
csc=value
The following are valid values for the csc property:
guestok=boolean
An idmap(8) name-based rule can be used to map guest to any local username, such as guest or nobody. If the local account has a password in /var/smb/smbpasswd the guest connection will be authenticated against that password. Any connection made using an account that maps to the local guest account will be treated as a guest connection.
Example name-based rule:
# idmap add winname:Guest unixuser:guest
index=file
log=tag
nosub=boolean
# mount -F nfs wool:/export/home/mnt
NFS Version 4 does not use the MOUNT protocol. The nosub option applies only to NFS Version 2 and Version 3 requests.
nosuid=boolean
public=boolean
NFS also supports negotiated optionsets for supported security modes. The security modes are documented in nfssec(7). The properties supported for these optionsets are:
charset=access-list
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.
ro=access-list
rw=access-list
none=access-list
root=access-list
root_mapping=uid
window=value
The general properties supported for SMB are:
encrypt=string
When set to disabled, the server will not ask clients to encrypt requests. When set to enabled, the server will ask clients to encrypt requests, but will not require that they do so. Any message than can be encrypted will be encrypted. When set to required, the server will deny access to or disconnect any client that does not support encryption or fails to encrypt requests that they should.
In other words, the enabled behavior is that any message that CAN be encrypted SHOULD be encrypted, while the required behavior is that any message that CAN be encrypted MUST be encrypted.
This property is not defined by default.
ro=access-list
rw=access-list
none=access-list
hostname
netgroup
domainname.suffix
NIS
DNS or LDAP
The domain name suffix is distinguished from hostnames and netgroups by a prefixed dot. For example:
rw=.mydomain.example.com
A single dot can be used to match a hostname with no suffix. For example, the specification:
rw=.
...matches mydomain but not mydomain.example.com. This feature can be used to match hosts resolved through NIS rather than DNS and LDAP.
network
=@mynet
...is 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. 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.
A prefixed minus sign (-) denies access to a 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 netgroup engineering, then:
rw=-terra:engineering
...denies access to terra, but:
rw=engineering:-terra
...grants access to terra.
98
other non-zero
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
| Interface Stability | Committed |
| November 22, 2021 | OmniOS |