This chapter provides instructions on how to configure the Solaris CIFS service to run as a standalone server (workgroup mode) or in an existing Windows environment (domain mode). This chapter also describes how to manage CIFS shares to be accessed by CIFS clients.
Currently, the Solaris CIFS service runs only in the global zone.
This chapter covers the following topics:
For a high-level overview of the Solaris CIFS service configuration process, see Configuring the Solaris CIFS Service – Process Overview.
CIFS is an enhanced version of the SMB protocol, which allows CIFS clients to access files and resources from the CIFS service. The terms SMB and CIFS can be considered interchangeable.
Up-to-date troubleshooting information is available from the OpenSolaris CIFS Server project page.
For information about installing the Solaris CIFS service packages, see Getting Started With the Solaris CIFS Service wiki on the OpenSolaris CIFS Server project page.
This section provides information about configuring the Solaris CIFS service as a client to the WINS service. For information about configuring other applicable services, see Configuring the Solaris CIFS Service – Process Overview.
If you are integrating a Solaris CIFS service in an environment that has a WINS server, you can use Windows Internet Naming Service (WINS) for name resolution.
For information about excluding IP addresses from WINS resolution, see Excluding IP Addresses From WINS Name Resolution in the Solaris CIFS Service Troubleshooting wiki.
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.
Specify the IP address of the primary WINS server.
The primary WINS server is the server consulted first for NetBIOS name resolution.
# sharectl set -p wins_server_1=IP-address smb |
(Optional) Specify the IP address of the secondary WINS server.
If the primary WINS server does not respond, the system consults the secondary WINS server to perform NetBIOS name resolution.
# sharectl set -p wins_server_2=IP-address smb |
The following table points to the tasks that you can use to configure the operation mode of the Solaris CIFS server.
Task |
Description |
For Instructions |
---|---|---|
Configure the Solaris CIFS service in domain mode. |
Use the smbadm join -u username domain-name command to join the domain. | |
Configure the Solaris CIFS service in workgroup mode. |
Use the smbadm join -w workgroup-name command to join the workgroup. |
After successfully joining an AD domain, you can enable the Solaris CIFS service to publish CIFS shares in the AD directory. To do so, create or update CIFS shares and specify the share container for each share that you want to publish. To create CIFS shares, see How to Create a CIFS Share (zfs) and How to Create a CIFS Share (sharemgr).
If the Samba service is running on the Solaris system, you must disable it. See How to Disable the Samba Service.
If you change from workgroup mode to domain mode, or from domain mode to workgroup mode, you must restart the Solaris CIFS service. To restart the service, run the svcadm restart smb/server command.
The Active Directory (AD) service is a Windows 2000 namespace that is integrated with the Domain Name Service (DNS). AD runs only on domain controllers. In addition to storing and making data available, AD protects network objects from unauthorized access and replicates objects across a network so that data is not lost if one domain controller fails.
For the Solaris CIFS service to integrate seamlessly into a Windows AD environment, the following must exist on the network:
A Windows AD domain controller
An optional Active Directory DNS server that permits dynamic updates to use the dynamic DNS (DDNS) capability
The AD and DDNS clients rely on the Kerberos protocol to acquire the Kerberos ticket-granting ticket (TGT) for the specified AD domain. The system must be configured to use DNS for host lookup.
In order to participate in an AD domain, the system must be configured to use DNS for host lookup. Ensure that the /etc/nsswitch.conf and /etc/resolv.conf files are configured correctly for the appropriate AD domain.
In the /etc/krb5/krb5.conf file, specify the fully qualified AD domain name, in uppercase characters, as the default realm. Also, specify the fully qualified host name of the domain controller as the value for the kdc, admin_server, and kpasswd_server parameters.
The following example /etc/krb5/krb5.conf file is for an AD domain called EXAMPLE.COM, and the AD domain controller system is called dc.example.com. The fully qualified names are used for the domain and the domain controller.
[libdefaults] default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = dc.example.com admin_server = dc.example.com kpasswd_server = dc.example.com kpasswd_protocol = SET_CHANGE } [domain_realm] .example.com = EXAMPLE.COM |
For descriptions of the sections and parameters used in this sample file, see the krb5.conf(4) man page and Configuring Kerberos Clients (Task Map) in System Administration Guide: Security Services.
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.
Enable the Solaris CIFS service.
# svcadm enable -r smb/server |
When you specify the -r option, all services on which smb/server depends are started if they are not already running.
To successfully complete the join process, ensure that the system clock on the Solaris system is within five minutes of the system clock of the domain controller (DC).
You can accomplish this task in one of these ways:
Manually adjust the system clock on either the Solaris system or the DC to match the other.
Configure both the Solaris system and the DC to use the same time source (NTP server).
Synchronize the system clock on the Solaris system with the system clock of the DC by running the following command on the Solaris system:
# ntpdate DC-hostname |
For example, to synchronize with the DC called dc.westsales.example.com, type:
# ntpdate dc.westsales.example.com |
Join the Windows domain.
# smbadm join -u username domain-name |
where username is the domain administrator or a user with Domain Administrator privileges, and domain-name is a fully qualified NetBIOS or DNS domain name.
This example shows the steps taken to configure the Solaris CIFS service in domain mode. User dana has Domain Administrator privileges. The name of the domain being joined is westsales.example.com.
# svcadm enable -r smb/server # smbadm join -u dana westsales.example.com Enter domain password: Joining 'westsales.example.com' ... this may take a minute ... Successfully joined domain 'westsales.example.com' |
After you join a workgroup, you can access CIFS shares. To create CIFS shares, see How to Create a CIFS Share (zfs) and How to Create a CIFS Share (sharemgr).
If you change from workgroup mode to domain mode, or from domain mode to workgroup mode, you must restart the Solaris CIFS service. To restart the service, run the svcadm restart smb/server command.
If the Samba service is running on the Solaris system, you must disable it. See How to Disable the Samba Service.
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.
Enable the Solaris CIFS service.
# svcadm enable -r smb/server |
This command enables the Solaris CIFS service and any service on which it depends, such as the idmap service.
(Optional) Change the Solaris CIFS service to operate in a different workgroup.
By default, the Solaris CIFS service operates in a workgroup called WORKGROUP.
# smbadm join -w workgroup-name |
Edit the /etc/pam.conf file to support creation of an encrypted version of the user's password for CIFS.
Add the following line to the end of the file:
other password required pam_smb_passwd.so.1 nowarn |
See the pam_smb_passwd(5) man page.
Specify the password for existing local users.
The Solaris CIFS service cannot use the Solaris encrypted version of the local user's password for authentication. Therefore, you must generate an encrypted version of the local user's password for the Solaris CIFS service to use. When the SMB PAM module is installed, the passwd command generates such an encrypted version of the password.
# passwd username |
This example shows how to configure the Solaris CIFS service in workgroup mode. The name of the workgroup being joined is myworkgroup.
# svcadm enable -r smb/server # smbadm join -w myworkgroup |
Then, use the sharesmb property to configure CIFS sharing for an existing ZFS dataset called ztank/myfs.
# zfs set sharesmb=on ztank/myfs |
Finally, install the PAM module and generate the password for user cal.
# passwd cal |
Now, you are ready to have CIFS clients access the CIFS shares on your Solaris CIFS service.
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.
Task |
Description |
For Instructions |
---|---|---|
Configure cross-protocol locking. |
Use the mount or the zfs create command to configure cross-protocol locking. These commands enable this locking by setting the nbmand option. | |
Create a CIFS share by using the ZFS file system sharesmb property. |
Use this procedure if you want to make a file or directory available to clients. You might use this procedure if you are familiar with the ZFS file system sharenfs property. | |
Create a CIFS share by using the sharemgr command. |
Use this procedure if you want to make a file or directory available to clients. If you specify an AD container, sharemgr will attempt to publish those shares in AD. | |
Modify the properties of a CIFS share by using the sharemgr command. |
Use this procedure to change share property values. | |
Remove a CIFS share by using the sharemgr command. |
When you remove a share, it can no longer be accessed by a system. If you are connected to the share when it is removed, the share is not removed until there are no more connections to that share. At that time, the share is removed. | |
Create an autohome share rule. |
Specify custom share rules for autohome shares. | |
Restrict host access to a share by using the ZFS file system sharesmb property. |
Use this procedure if you want to restrict access to a client host in one of the following ways: read-write access, read-only access, or no access. You might use this procedure if you are familiar with the ZFS file system sharenfs property. | |
Restrict host access to a share group by using the sharemgr command. |
Use this procedure if you want to restrict access to a client host in one of the following ways: read-write access, read-only access, or no access. |
How to Restrict Client Host Access to a CIFS Share (sharemgr) |
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.
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.
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 |
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 |
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.
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.
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 |
If AD is enabled, specify the AD container where the share will be published.
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 |
Use this procedure to change properties on a share.
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.
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.
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.
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.
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 |
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.
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.
Edit the /etc/smbautohome file.
An autohome entry must be on a single line in the following format:
key location [container]
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.
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.
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.
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.
Determine the kind of access you want to grant for each client host.
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 |
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.
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.
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.
Determine the kind of access you want to grant for each client host.
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 |
This section describes how to manage CIFS groups and privileges for the Solaris CIFS service.
CIFS groups apply only to users that are connected through CIFS.
For information about CIFS groups and local users, see Local CIFS Groups.
The following table points to the tasks that you can use to manage CIFS groups through the Solaris CIFS service.
You use the smbadm(1M) command to manage CIFS groups on the system that runs the Solaris CIFS service.
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.
Choose the name of the group to create.
You might choose a name that reflects a common set of tasks that the group can perform or the organization to which the group members belong.
Create the CIFS group.
# smbadm create [-d description] group-name |
The -d option is used to specify a textual description of the CIFS group.
For example, to create a group called wsales, type:
# smbadm create -d "Sales Force for the Western Region" wsales |
In order to provide proper identity mapping between CIFS groups and Solaris groups, a CIFS group must have a corresponding Solaris group. This requirement has two consequences. First, the group name must conform to the intersection of the Windows and Solaris group name rules. Thus, a CIFS group name can be up to eight (8) characters long and contain only lowercase characters and numbers. Second, a Solaris group has to be created before a CIFS group can be created. The Solaris group is created by using the groupadd command. See the groupadd(1M) man page.
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.
Add a user to the CIFS group.
# smbadm add-member -m member-name [[-m member-name] …] group-name |
member-name can be specified as [domain-name\]username or [domain-name/]username. The domain name is the domain in which the user can be authenticated. By default, the domain name is the name of the domain that you joined.
The backslash character (\) is a shell special character and must be quoted. For instance, escape the backslash character with another backslash character: domain\\username. For more information about handling shell special characters, see the man page for your shell.
For example, to add user terry of the sales domain to the wsales group, type:
# smbadm add-member -m sales\\terry wsales |
To add a local user to a CIFS group, specify the Solaris host name rather than the domain name. For example, to add local user terry of the solarsystem host to the wsales group, type:
# smbadm add-member -m solarsystem\\terry wsales |
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.
Remove a user from the CIFS group.
# smbadm remove-member -m member-name [[-m member-name] …] group-name |
member-name can be specified as [domain-name\]username or [domain-name/]username. The domain name is the domain in which the user can be authenticated. By default, the domain name is the name of the domain that you joined.
The backslash character (\) is a shell special character and must be quoted. For instance, escape the backslash character with another backslash character: domain\\username. For more information about handling shell special characters, see the man page for your shell.
For example, to remove user terry of the sales domain from the wsales group, type:
# smbadm remove-member -m sales\\terry wsales |
To remove a local user from a CIFS group, specify the Solaris host name rather than the domain name. For example, to remove local user terry of the solarsystem host from the wsales group, type:
# smbadm remove-member -m solarsystem\\terry wsales |
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.
Modify one or more CIFS group properties.
# smbadm set -p property=value [[-p property=value] …] group-name |
You can specify one or more property-value pairs on the command line. Each property-value pair must be preceded by the -p option. Valid values for privileges are on or off. The value of the description property is an arbitrary text string.
For example, to grant the backup privilege and to modify the description of the wsales group, type:
# smbadm set -p backup=on \ -p description="Sales force for the Western region" wsales |
The Samba and CIFS services cannot be used together on a single Solaris system. If you want to run the Solaris CIFS service, you must first ensure that a running Samba service is disabled.
If your Solaris system is running the Samba service, disable it before starting the Solaris CIFS service.
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.
Verify that the Samba service is running.
# svcs | grep samba |
For example, the following command shows that the Samba service is running:
# svcs | grep samba legacy_run Aug_03 lrc:/etc/rc3_d/S90samba |
Disable the Samba service.
# svcadm disable svc:/network/samba # svcadm disable svc:/network/wins |