Go to main content

Managing SMB File Sharing and Windows Interoperability in Oracle® Solaris 11.4

Exit Print View

Updated: November 2020

SMB Shares

A share makes a directory accessible to SMB clients on the network. Each share is identified by a name. An SMB client sees only the share name, not the server's path to the shared directory.

Note -  A share and a directory are independent entities. Removing a share does not affect the underlying directory.

Shares are commonly used to provide network access to home directories on a network file server. Each user is assigned a home directory. A share is persistent and remains defined regardless of whether users are connected to the server.

The SMB server provides a special kind of share called an autohome SMB share. An autohome share is a transient share of a user's home directory that is created when a user logs in and removed when the user logs out.

When a user browses the system, only statically defined shares and the user's autohome share will be listed.

SMB Share Properties

For information about creating an SMB share, see How to Create an SMB Share (zfs).

Use the zfs set and zfs share commands to set share properties that modify the attributes and behavior of an SMB share. For information about the zfs set and zfs share commands, see the zfs(8) man page.

For more information about setting share properties for ZFS file systems, see Sharing and Unsharing ZFS File Systems in Managing ZFS File Systems in Oracle Solaris 11.4.

For complete descriptions of the following properties, see the share_smb(8) and zfs_share(8) man pages. The two types of share properties are global and protocol-specific.

The global share properties include the following:

  • desc – Specifies an optional description of the share

  • path – Specifies the mount point of the share

The protocol-specific share properties for the SMB protocol include the following:

  • abe – Enables or disables access-based enumeration for a share

  • ad-container – Specifies the name of an AD container in which to publish a share

  • catia – Specifies whether to perform CATIA character substitution

  • cont_avail – Enables or disables continuous availability to a share

  • csc – Sets the client-side caching policy

  • dfsroot – Enables or disables DFS root support on a share

  • encrypt – Configures SMB encryption at the share level

  • guestok – Enables or disables guest access to a share

  • none, ro, rw – Sets host-based access rules for a share

  • oplocks – Specifies the share-level oplocks configuration for the share

  • bypasstraverse – Specifies whether to bypass traverse checking for the share

The SMB server provides a per-share configuration property to support client-side caching for offline files. Although the SMB server enables you to configure this feature, only the client manages client-side caching and access to offline files. You can use the zfs command to configure this feature by setting the csc property for a share.

Valid values for the csc property are:

  • manual Permits clients 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 Permits clients to automatically cache files from the specified share for offline use, and permits file-by-file reintegration.

  • vdo Permits clients to automatically cache files from the specified share for offline use, permits file-by-file reintegration, and permits clients to work from their local cache even while offline.

  • disabled Disables client-side caching for the specified share.

SMB Share Access Control

The SMB server uses the following access-control mechanisms to limit access to data shared by using SMB:

  • Host-based access control limits access to shares based on which client system is making the request.

  • Share ACLs limit user and group access to shares.

  • File and directory ACLs limit user and group access to individual files and directories.

Host-based access control is applied first and grants or denies access to the client system. If the client system is granted access, the share ACL is then applied to grant or deny access to the user. Finally, the individual file and directory ACLs are consulted. You can access the data shared by using SMB only if all three access control mechanisms allow the access.

Shares are always created with the default share ACL and, unless otherwise specified when the share is created, default host-based access control. You can apply non-default share ACLs to the share after the share is created.

Host-Based Access Control to SMB Shares

Host-based access control enables you to limit the access of a host or group of hosts to an SMB share. This host-based access control is enforced only for SMB access, not for local access or access through other protocols. By default, all hosts have full access to a share. The SMB server enforces host-based access control each time a client requests a connection to a share.

You can use the zfs set and share commands to specify host-based access control on a share. For more information, see How to Restrict Client Host Access to an SMB Share (zfs). For more information about share command, see the share(8) man page. For more information about zfs command, see the zfs(8) man page. For more information about SMB shares, see the share_smb(8) man page. For information about the available options for sharing ZFS file system, see the zfs_share(8) man page.

Access Control Lists on SMB Shares

An ACL on a ZFS share provides the same level of access control as a Windows ACL does for its shares. Each share can have an ACL that includes entries to specify which types of access are allowed or denied to users and groups. Like host-based access control, this mechanism is a share-level form of access control and does not apply to local file access.

These share ACLs are only available for ZFS shares. You can manage a ZFS share's ACL in the Oracle Solaris OS by using the chmod and ls commands. For more information, see the chmod(1) and ls(1) man pages. You can also manage these ACLs by using the Windows share management GUI on a Windows client. For more information, see Setting ACLs on ZFS Files in Securing Files and Verifying File Integrity in Oracle Solaris 11.4.

Although a ZFS file system is used to store a share's ACL, the access control is enforced by the SMB server each time a client requests a connection to a share. Access control lists are enforced only for SMB access, not for local access or access through other protocols. The default ACL setting permits full access to everyone.

Administrators with appropriate privileges can set ACL entries to audit access attempts to specific files. For more information about auditing events related to specific files, see New Feature – Per-Object Logging of Audit Events in Managing Auditing in Oracle Solaris 11.4. For information about how to specify files that must be audited, see Specifying Files or Directories to Be Audited in Managing Auditing in Oracle Solaris 11.4. For information about how to access SMB authentications using the audit tools, see SMB Auditing.

Note -  You cannot specify an ACL on an autohome share. Autohome shares are created at runtime with a predefined, unmodifiable ACL that grants full control to the owner. Only the autohome share owner can access the share.

SMB Autohome Shares

The autohome share feature eliminates the administrative task of defining and maintaining home directory shares for each user that accesses the system through the SMB protocol. The system creates autohome shares when a user logs in, and removes them when the user logs out. This process reduces the administrative effort needed to maintain user accounts, and increases the efficiency of service resources.

For example, if /home is a home directory that contains subdirectories for users auser and buser, you can manually define the shares as follows:





However, defining and maintaining directory shares in this way for each user is inconvenient. Instead, you can use the autohome feature.

To configure the autohome feature, you need to specify autohome share rules. For example, if a user's home directory is /fort/buser, the autohome path is /fort. The temporary share is named buser. Note that the user's home directory name must be the same as the user's login name. See How to Create a Specific Autohome Share Rule.

When a user logs in, the SMB server looks for a subdirectory that matches the user's name based on any rules that have been specified. If the server finds a match and if that share does not already exist, the subdirectory is added as a transient share. When the user logs out, the server removes that transient share.

Some Windows clients log a user out after 15 minutes of inactivity, which results in the autohome share disappearing from the list of defined shares. This behavior is expected for SMB autohome shares. Even after an SMB autohome share is removed, the share reappears when the user attempts to access the system (for example, in an Explorer window).

Note -  If you are using autohome share, you cannot allow other users to access files in your home directory. All autohome shares are removed when the SMB server is restarted.

SMB Autohome Entries

The SMB server can automatically share home directories when an SMB client connects. The autohome map file, /etc/smbautohome, uses the search options and rules to determine whether to share a home directory when an SMB client connects to the server.

For example, the following entries specify the autohome rules for a particular environment:

+nsswitch             dc=ads,dc=oracle,dc=com,ou=users
auser    /home/?/&    dc=ads,dc=oracle,dc=com,ou=users

The nsswitch autohome entry uses the naming service to match users to home directories. The second autohome entry specifies that the home directory for user auser is /home/a/auser.

SMB Autohome Map Entry Format

A map entry uses the following format:

key location [ container ]

Specifies a user name


Specifies the fully qualified path for the user's home directory


Specifies an optional AD container

An AD container name is specified as a comma-separated list of attribute name-value pairs. The attributes use the LDAP distinguished name (DN) or relative distinguished name (RDN) format.

The DN or RDN must be specified in LDAP format by using the following prefixes:

  • cn= represents the common name.

  • ou= represents the organizational unit.

  • dc= represents the domain component.

cn=, ou=, and dc= are attribute types. For more information about AD container attribute names and values, see the share_smb(8) man page.

SMB Autohome Map Key Substitution

The autohome feature supports the following wildcard substitutions for the value of the key field:

  • The ampersand (&) is expanded to the value of the key field for the entry in which it occurs. In the following example, & expands to auser:

    auser /home/&
  • The question mark (?) is expanded to the value of the first character in the key field for the entry in which it occurs. In the following example, the path is expanded to /home/aa/auser:

    auser /home/??/&
Wildcard Rule

When supplied in the key field, the asterisk (*) is recognized as the "catch-all" entry. This type of entry matches any key not previously matched.

For example, the following entry would map any user to a home directory in /home in which the home directory name was the same as the user name:

*    /home/&

Note -  The wildcard rule is applied only if an appropriate rule is not matched by another map entry.
nsswitch Map

The nsswitch map is used to request that the home directory be obtained from a password database, such as the local, NIS, or LDAP database. If an AD path is appended, it is used to publish shares.


Like the asterisk wildcard entry, the nsswitch map is searched only if an appropriate rule is not matched by another map entry.

Note -  The wildcard and nsswitch rules are mutually exclusive. Do not include an nsswitch rule if a wildcard rule has already been defined.