Managing CIFS Shares (Task Map)

You can add, view, and update CIFS shares. A directory must exist before it can be shared. For more information about CIFS shares, see CIFS Shares.

The following table points to the tasks that you can use to manage CIFS shares.

How to Configure Cross-Protocol Locking

The CIFS protocol assumes mandatory locking, but UNIX traditionally uses advisory locking. The Solaris OS can be configured to use mandatory locking on a per mount basis by using the non-blocking mandatory locking (nbmand) mount option.

When set, the nbmand mount option enforces mandatory cross-protocol share reservations and byte-range locking.

When the nbmand mount option is not set, the Solaris CIFS service will enforce mandatory share reservations and byte-range locking internally for all CIFS clients. However, without nbmand set, there is only limited coordination with NFS and local processes.

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Set the nbmand mount option for an existing file system by doing one of the following:

   • Set the option by using the mount command.

     # mount -o nbmand=on fsname

     For example, the following command sets the nbmand mount option for the ztank/myfs file system:

     # mount -o nbmand ztank/myfs

   • Set the option by using the zfs create command.

     When using the ZFS file system, you can also set the nbmand option when the file system is created, so that the file system uses nbmand automatically:

     # zfs create -o nbmand=on fsname

     The following example combines the nbmand option with the mixed-case sensitivity option:

     # zfs create -o casesensitivity=mixed -o nbmand=on -o mountpoint=mntpt ztank/myfs

How to Create a CIFS Share (zfs)

This procedure describes how to use the ZFS file system sharesmb property to create shares on the Solaris CIFS service.

To create an autohome share, you must have defined autohome rules. For more information, see How to Create a Specific Autohome Share Rule.

1. Become superuser, assume an equivalent role, obtain the solaris.smf.value.smb and solaris.smf.manage.smb RBAC authorizations, or use the “SMB Management” RBAC profile, which is part of the “File System Management” profile.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Create a ZFS pool and a mixed-case ZFS file system that supports cross-protocol locking.

   # zpool create pool-name vdev # zfs create -o casesensitivity=mixed -o nbmand=on fsname

3. Enable SMB sharing for the ZFS file system.

   # zfs set sharesmb=on fsname

   ---

   Note –

   The resource name for the share is automatically constructed by the zfs command when the share is created. The resource name is based on the dataset name, unless you specify a resource name. Any characters that are illegal for resource names are replaced by an underscore character (_).

   ---

   To specify a resource name for the share, specify a name for the sharesmb property, sharesmb=name=resource-name.

   When SMB shares are created on a ZFS file system, the SMB share name appears as an entry in the .zfs/shares directory. You can use the ls command to show the share-level ACLs on the entries in this directory. You can also use the chmod command to modify the share-level ACLs on the entries in this directory. See the ls(1) and chmod(1) man pages.

4. Verify how the file system is shared.

   # sharemgr show -vp

Example 3–3 Using sharesmb to Manage CIFS Shares

The following examples use the sharesmb property to enable SMB sharing for ZFS pools and file systems.

• Inherited SMB sharing for ZFS file systems in a pool. The following commands create a pool and enable SMB sharing for that pool. When you create the ZFS file systems in that pool, the file systems inherit the SMB sharing as well as the resource name.

  # zpool create sandbox c0t3d0 # zfs set sharesmb=on sandbox # zfs create -o casesensitivity=mixed -o nbmand=on sandbox/fs1 # zfs create -o casesensitivity=mixed -o nbmand=on sandbox/fs2

  The sharemgr show -vp command shows how the top level file system has a resource name of sandbox, but the children have the dataset name added to the resource name.

  # sharemgr show -vp default nfs=() mygroup smb=() zfs nfs=() smb=() zfs/sandbox smb=() sandbox=/sandbox sandbox_fs1=/sandbox/fs1 smb=() sandbox_fs2=/sandbox/fs2 smb=()

• SMB sharing for a ZFS file system. The following commands create a ZFS pool and a mixed-case file system that supports cross-protocol locking:

  # zpool create sandbox c0t3d0 # zfs create -o casesensitivity=mixed -o nbmand=on sandbox/fs1

  Next, you can enable SMB sharing for the sandbox/fs1 file system and for any of its children by setting the sharesmb property to on.

  # zfs set sharesmb=on sandbox/fs1

  Because CIFS shares must have a resource name, the ZFS file system constructs a resource name from the dataset name. Any characters in the dataset name that are illegal in resource names are replaced by the underscore character (_). In this example, the resource name sandbox_fs1 is based on the dataset name sandbox/fs1.

  You can use the sharemgr show -vp command to verify how the file system is shared.

  # sharemgr show -vp default nfs=() mygroup smb=() zfs nfs=() smb=() zfs/sandbox/fs1 smb=() sandbox_fs1=/sandbox/fs1

  The following commands create another file system in the sandbox pool called fs2 and associate that file system with the myshare resource name:

  # zfs create -o casesensitivity=mixed -o nbmand=on sandbox/fs2 # zfs set sharesmb=name=myshare sandbox/fs2

  Use the sharemgr show -vp command to verify how the file systems are shared.

  # sharemgr show -vp default nfs=() mygroup smb=() zfs nfs=() smb=() zfs/sandbox/fs1 smb=() sandbox_fs1=/sandbox/fs1 zfs/sandbox/fs2 smb=() myshare=/sandbox/fs2

  The following command creates a sub file system of sandbox/fs2 called sandbox/fs2/fs2_sub1:

  # zfs create -o casesensitivity=mixed -o nbmand=on sandbox/fs2/fs2_sub1

  This new file system inherits part of its resource name from its parent and also inherits sharing over SMB, if enabled. Because the resource name for sandbox/fs2 is myshare, the resource name for sandbox/fs2/fs2_sub1 is myshare_fs2_sub1.

  # sharemgr show -vp default nfs=() mygroup smb=() zfs nfs=() smb=() zfs/sandbox/fs1 smb=() sandbox_fs1=/sandbox/fs1 zfs/sandbox/fs2 smb=() myshare=/sandbox/fs2 myshare_fs2_sub1=/sandbox/fs2/fs2_sub1

  If you disable SMB sharing for sandbox/fs2, that file system and its children are affected.

  # zfs set sharesmb=off sandbox/fs2 # sharemgr show -vp default nfs=() mygroup smb=() zfs nfs=() smb=() zfs/sandbox/fs1 smb=() sandbox_fs1=/sandbox/fs1

  The sharemgr show -vp output shows that the sandbox/fs2 file system and its children are no longer shared over SMB.

Example 3–4 Using ls and chmod to Manage CIFS Share-Level ACLs

The following example shows how to view the share-level ACLs on CIFS shares in the .zfs/shares directory. This example also shows how to use the chmod command to modify the ACLs on these shares. Finally, the example shows how to verify that the ACL has been correctly updated by using the ls command. For more information about using the chmod command to modify ACLs, see the chmod(1) man page.

The ACLs are stored on resources located in the .zfs/shares subdirectory in the root of the shared file system. In this example, the shared file system is /zpool/cosmos and one resource, pluto, is stored in the .zfs/shares directory for this file system.

After changing to the /zpool/cosmos/.zfs/shares directory, you can use the ls -lv command to view the ACL information on the resources in that directory.

# cd /zpool/cosmos/.zfs/shares
# ls -lv
total 2
----------+  1 root     root           0 Feb  8 18:35 pluto
     0:everyone@:read_data/write_data/append_data/read_xattr/write_xattr
         /execute/delete_child/read_attributes/write_attributes/delete
         /read_acl/write_acl/write_owner/synchronize:allow

The ls -lv output shows that the pluto resource is owned by the root user and the root group. The everyone ACL entry covers all other users who are not the root user or part of the root group. The everyone ACL entry shows that everyone has all access privileges, which is the default.

Next, use the chmod command to add a user, terry, who only has read access to the pluto resource. After running the chmod command, the ls -lv command shows you the new ACL entry for user terry. Note that the ACL entry for everyone is unchanged.

# chmod A+user:terry:read_data/read_xattr/read_attributes/read_acl:allow pluto
# ls -lv
total 2
-rwxrwxrwx+  1 root     root           0 Feb  8 18:35 pluto
     0:user:terry:read_data/read_xattr/read_attributes/read_acl:allow
     1:everyone@:read_data/write_data/append_data/read_xattr/write_xattr
         /execute/delete_child/read_attributes/write_attributes/delete
         /read_acl/write_acl/write_owner/synchronize:allow

Use the chmod command to modify the ACL entry for user terry to permit all access privileges. Now, the ls -lv command shows that the ACL entry for user terry has been updated to have all access privileges.

# chmod A0=user:terry:read_data/write_data/append_data/read_xattr/ \
write_xattr/execute/delete_child/read_attributes/write_attributes/delete/ \
read_acl/write_acl/write_owner/synchronize:allow pluto
# ls -lv
total 2
-rwxrwxrwx+  1 root     root           0 Feb  8 18:35 pluto
     0:user:terry:read_data/write_data/append_data/read_xattr/write_xattr
         /execute/delete_child/read_attributes/write_attributes/delete
         /read_acl/write_acl/write_owner/synchronize:allow
     1:everyone@:read_data/write_data/append_data/read_xattr/write_xattr
         /execute/delete_child/read_attributes/write_attributes/delete
         /read_acl/write_acl/write_owner/synchronize:allow

How to Create a CIFS Share (sharemgr)

This procedure describes how to create a share definition on the Solaris CIFS service and make the share available to clients.

To create an autohome share, you must have defined autohome rules. For more information, see How to Create a Specific Autohome Share Rule.

1. Become superuser, assume an equivalent role, obtain the solaris.smf.value.smb and solaris.smf.manage.smb RBAC authorizations, or use the “SMB Management” RBAC profile, which is part of the “File System Management” profile.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Define a share in the default share group or in another share group.

   A share name can include any alphanumeric characters, but not the characters listed here:

   " / \ [ ] : | + ; , ? * =

   Create a share group and add a share to that group.

   # sharemgr create -P smb group-name # sharemgr add-share -r resource-name -s share-path group-name

3. If AD is enabled, specify the AD container where the share will be published.

   ---

   Note –

   The container must already exist for the share to be published in that container. The system does not create container objects in the AD tree.

   ---

   # sharemgr set [-hnv] -P smb [-S option-set] [-p property=value … \ [-s share-path] group-name

How to Modify CIFS Share Properties (sharemgr)

Use this procedure to change properties on a share.

1. Become superuser, assume an equivalent role, obtain the solaris.smf.value.smb and solaris.smf.manage.smb RBAC authorizations, or use the “SMB Management” RBAC profile, which is part of the “File System Management” profile.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Modify the CIFS share properties.

   • Modify properties for a single share.

     # sharemgr set-share [-r resource-name] [-d "description"] -s share-path group-name

     For example, the following command changes the description for the /files/acme.sales.logs share in the nw-sales group:

     # sharemgr set-share -d "Sales logs for Acme" -s /files/acme.sales.logs nw-sales

   • Modify properties for a share group.

     # sharemgr set [-hnv] -P smb [-S option-set] [-p property=value] … \ [-s share-path] group-name

     For example, in domain mode you can configure shares to be published in an AD container. The following command specifies that shares in the nw-sales share group will be published in the default container. Note that filesvr is the machine account of the system that is running the Solaris CIFS service.

     # sharemgr set -P smb -p ad-container=cn=filesvr,cn=Computers nw-sales

     If you want to publish shares to a non-default container, you must modify the ACLs of that container to give the Solaris CIFS service permission to publish and unpublish shares.

How to Remove a CIFS Share (sharemgr)

This procedure describes how to remove a CIFS share. When you remove a CIFS share, the definition of the share is removed from the server. You can re-create such a share with the sharemgr add-share command.

1. Become superuser, assume an equivalent role, obtain the solaris.smf.value.smb and solaris.smf.manage.smb RBAC authorizations, or use the “SMB Management” RBAC profile, which is part of the “File System Management” profile.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Remove a CIFS share.

   # sharemgr remove-share -s share-path group-name

   For example, to remove share /sales/share1 from share group mysharegroup, type:

   # sharemgr remove-share -s /sales/share1 mysharegroup

How to Create a Specific Autohome Share Rule

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 procedure describes how to configure autohome shares by adding rules to a configuration file.

For information about the smbautohome format, see Autohome Entries and the smbautohome(4) man page.

1. Become superuser, assume an equivalent role, obtain the solaris.smf.value.smb and solaris.smf.manage.smb RBAC authorizations, or use the “SMB Management” RBAC profile, which is part of the “File System Management” profile.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Edit the /etc/smbautohome file.

   An autohome entry must be on a single line in the following format:

   key	location	[container]

   1. Specify the user name in the key field.

      Usually this field is a user name, but it can also be one of the following:

      • +nsswitch – Uses the naming service to match users to home directories if no rule matches.

      • Asterisk (*) – Matches a user name to a home directory that uses the same name.

   2. Specify the location of the user's home directory in the location field.

      Specify the absolute path excluding the user name, or use one of the following substitution characters:

      • Question mark (?) – Substitutes for the first character of the user name.

      • Ampersand (&) – Substitutes for a complete user name.

      For example, the following rule maps to /home/a/amy:

      amy /home/?/&

      For more information about the path, see Autohome Shares.

How to Restrict Client Host Access to a CIFS Share (zfs)

This procedure describes how to use the ZFS file system sharesmb property to restrict access to a share based on a client's host address. This feature is known as host-based access control.

A client host is permitted to have only one of the following types of access to a share:

• Read-only access

• Read-write access

• No access

For more information about access lists, see the sharemgr(1M) man page.

1. Become superuser, assume an equivalent role, obtain the solaris.smf.value.smb and solaris.smf.manage.smb RBAC authorizations, or use the “SMB Management” RBAC profile, which is part of the “File System Management” profile.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Determine the kind of access you want to grant for each client host.

3. Restrict access by particular hosts to a dataset.

   # zfs set sharesmb=ro=hostname[:hostname] dataset # zfs set sharesmb=rw=hostname[:hostname] dataset # zfs set sharesmb=none=hostname[:hostname] dataset

   hostname can be a host name, a netgroup, or an IP address. dataset is the name of the dataset.

   You can specify the host access policy by combining the access settings in a single command. For example, the following command specifies how particular hosts can access files/acme.sales.logs. mercury and venus have read-write access, mars has read-only access, and neptune has no access.

   # zfs set sharesmb=rw=mercury:venus,ro=mars,none=neptune files/acme.sales.logs

   ---

   Note –

   Ensure that your existing dataset property values are not lost when changing the sharesmb property for that dataset. If you previously set sharesmb property values, specify them all again along with the new value on the zfs set command line. If the existing property values are not specified again, the values are lost or reset to default values, if appropriate.

   ---

How to Restrict Client Host Access to a CIFS Share (sharemgr)

This procedure describes how to use the sharemgr command to restrict access to a share group based on a client's host address. This feature is known as host-based access control.

A client host is permitted to have only one of the following types of access to a share:

• Read-only access

• Read-write access

• No access

For more information about access lists, see the sharemgr(1M) man page.

1. Become superuser, assume an equivalent role, obtain the solaris.smf.value.smb and solaris.smf.manage.smb RBAC authorizations, or use the “SMB Management” RBAC profile, which is part of the “File System Management” profile.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Determine the kind of access you want to grant for each client host.

3. Restrict access by particular hosts to a share group.

   # sharemgr set -P smb -p ro=hostname[:hostname] group-name # sharemgr set -P smb -p rw=hostname[:hostname] group-name # sharemgr set -P smb -p none=hostname[:hostname] group-name

   hostname can be a host name, a netgroup, or an IP address. group-name is the share group.

   You can specify the host access policy by combining the access settings in a single command. For example, the following command specifies how particular hosts can access the nw-sales share group. mercury and venus have read-write access, mars has read-only access, and neptune has no access.

   # sharemgr set -P smb -p rw=mercury:venus -p ro=mars -p none=neptune nw-sales