Skip Navigation Links | |
Exit Print View | |
man pages section 1M: System Administration Commands Oracle Solaris 11.1 Information Library |
- make SMB shares available for mounting by remote systems
share -F smb [-a [-o specific-options] [-d description] pathname sharename | [-A]]
zfs set share.smb=on | off filesystem|filesystem%share
zfs share -o share.smb=on | off specific_options filesystem|filesystem%share
The share command defines and publishes a SMB share, which makes a local file system available for mounting by remote systems.
You can modify the behavior of SMB shares by setting property values with either the share, the zfs set command or the zfs share command. See the share(1M) and zfs(1M) man pages.
The share command has the following options:
Share SMB 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 SMB 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 properties supported by a given file system.
Provide a comment that describes the file system to be shared.
Display all defined shares.
The following SMB share properties are supported and can be set by the zfs and share commands:
Sets the access-based enumeration (ABE) policy for a share. When set to true, ABE filtering is enabled on this share and directory entries to which the requesting user has no access will be omitted from directory listings returned to the client. When set to false or not defined, ABE filtering will not be performed on this share. This property is not defined by default.
Disable ABE for this share.
Enable ABE for this share.
Specifies the AD container in which to publish shares.
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 following example uses the share command to specify the AD container:
$ share -F smb -o abe=true,ad-container=cn=sales,ou=mycompany,dc=com /export/home
The following example uses the zfs sare command to specify the AD container:
$ zfs share -o share.smb=on -o share.smb.ad-container=cn=sales,ou=mycompany,dc=com -o share.smb.abe=on rpool/export/home%share1
The DN or RDN must be specified in LDAP format using the cn=, ou=, and dc= prefixes:
cn represents the common name
ou represents the organizational unit
dc represents the domain component
cn=, ou= and dc= are attribute types. The attribute type used to describe an object's RDN is called the naming attribute, which, for ADS, includes the following object classes:
cn for the user object class
ou for the organizational unit (OU) object class
dc for the domainDns object class
Specifies whether to perform CATIA character substitution. CATIA V4 uses characters in file names that are considered to be invalid by Windows. A CATIA V4 file could be inaccessible to Windows clients if the file name contains any of the characters that are considered illegal in Windows. By default, CATIA character substitution is not performed. See Managing SMB File Sharing and Windows Interoperability in Oracle Solaris 11.1.
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
Sets the client-side caching policy for a share. Client-side caching is a client feature and offline files are managed entirely by the clients.
The following are valid values for the csc property:
manual – Clients are permitted to cache files from the specified share for offline use as requested by users. However, automatic file-by-file reintegration is not permitted. manual is the default value.
auto – Clients are permitted to automatically cache files from the specified share for offline use and file-by-file reintegration is permitted.
vdo – Clients are permitted to automatically cache files from the specified share for offline use, file-by-file reintegration is permitted, and clients are permitted to work from their local cache even while offline.
disabled – Client-side caching is not permitted for this share.
Marks a share as a distributed file system (DFS) root share to distinguish it from a regular share. By default, dfsroot is not defined. If dfsroot is false or not defined, the share is not a DFS root share.
Sets the guest access policy for the share. When set to true guest access is allowed on this share. When set to false or not defined guest access is not allowed on this share. This property is not defined by default.
An idmap(1M) name-based rule can be used to map guest to any local user name, 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.
The following name-based rule maps the Windows Guest user to the UNIX guest user:
# idmap add winname:Guest unixuser:guest
Specifies that 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 none.
Specifies that sharing is read-only to the clients listed in access-list. Overrides the rw suboption for the clients specified. See access-list.
Specifies that sharing is read-write to the clients listed in access-list. Overrides the ro suboption for the clients specified. See access-list.
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:
Specifies the name of a host. hostname must be a fully qualified DNS or LDAP name when the host specifies these naming schemes in the hosts portion of the nsswitch.conf file.
A netgroup contains a number of host names. Any hostname in a netgroup must be a fully qualified DNS or LDAP name when the host specifies these naming schemes in the hosts portion of the nsswitch.conf file.
To use domain membership, the server must use DNS or LDAP to resolve host names to IP addresses. This means that the hosts entry of the /etc/nsswitch.conf file must specify dns or ldap before nis. You must do this because only DNS and LDAP return the full domain name of the host.
Other naming services, such as NIS, cannot be used to resolve host names on the server because these naming services do not return domain information. For example, the following shows how NIS, DNS, and LDAP return host name information for the 172.16.45.9 IP address:
Returns: myhost
Returns: myhost.mydomain.mycompany.com
The domain name suffix is distinguished from host names and netgroups by a prefixed dot. For example, rw=.mydomain.mycompany.com matches all host names in mydomain.mycompany.com.
The rw=. notation uses a single dot to match a host name that has no suffix. This notation matches mydomain but not mydomain.mycompany.com. This feature can be used to match hosts that are resolved by NIS rather than by DNS and LDAP.
The network or subnet component is preceded by an at-sign character (@). It can be either a network name or a dotted address.
A network name is converted to a dotted address by using getnetbyname(3SOCKET). For example, =@mynet is equivalent to =@172.16 or =@172.16.0.0.
The network prefix assumes an octet-aligned netmask. The netmask is determined from the zeroth octet in the low-order part of the address up to and including the high-order octet. If network prefixes are not byte-aligned, the syntax permits a mask length to be explicitly specified 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 previously, but do not use a netmask specification. For example, =@172.16.132.14.
You can use a colon character (:) to separate multiple, individual IP addresses. For example, root=@172.16.132.20:@172.16.134.20.
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, specifying rw=-terra:engineering denies access to terra. However, specifying rw=engineering:-terra grants access to terra.
Example 1 Setting a Share Property
The following examples use the zfs share and share commands to create and publish an SMB share.
The following example shows how to use the zfs share command to create and publish an SMB share that also enables guest access:
# zfs share -o share.smb=on -o share.smb.guestok=on tank/home%hshare
The following example shows how to use the share command to enable guest access on a share:
# share -F smb -o guestok=true /tank/home
Example 2 Viewing the Share Properties
The following examples show how to use the zfs get command and the /etc/dfs/sharetab file to view share properties:
The zfs get command enables you to view share properties on the tank/home dataset:
# zfs get share.smb tank/home%hshare NAME PROPERTY VALUE SOURCE tank/home%hshare share.smb on local
The /etc/dfs/sharetab file shows all the active shares on the system. The entry for each share shows the properties set and their values:
# grep home /etc/dfs/sharetab /tank/home hshare smb guestok
System record of shared file systems
See attributes(5) for descriptions of the following attributes:
|
idmap(1M), share(1M), zfs(1M), zfs(1M), getnetbyname(3SOCKET), netgroup(4), attributes(5)