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.
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.
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 |
Enable SMB sharing for the ZFS file system.
# zfs set sharesmb=on fsname |
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.
Verify how the file system is shared.
# sharemgr show -vp |
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.
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 |