Solaris CIFS Service Troubleshooting

From Genunix

Copyright Notice

Contents

Solaris CIFS Troubleshooting

This chapter provides troubleshooting information for the Solaris CIFS service and the idmapd service, and includes a description of known limitations with the product components, as follows:

For more information about the Solaris CIFS service project, see the OpenSolaris CIFS Server project page. For more information about the Solaris CIFS client project, see the OpenSolaris CIFS Client project page. For more information about the identity mapping service project, see the Winchester project page.

For more information about Solaris CIFS, see the following:


Known Limitations

Caution - This is a beta release of the Solaris CIFS service for evaluation and OpenSolaris development. Do not use this service in production environments where service availability and data reliability are required.

This release of the Solaris CIFS service software is a preliminary implementation of the Solaris CIFS service. Most of the core CIFS/SMB facilities are provided and have been rigorously tested. However, some capabilities are not as complete or as robust as Sun expects to have them.

For instance, the Solaris CIFS service has the following limitations:

  • Do not use SXCE Build 93 for Solaris CIFS due to known problems; the issues are expected to be resolved in SXCE Build 94
  • Using NT Domains is not fully supported.
  • Operating with multiple AD domain controllers is not fully supported.

Performance testing of the Solaris CIFS service is underway, and Sun expects to bring this service up to production quality. For the time being, the Solaris CIFS service is disabled by default and must be enabled using service management framework (SMF) services. For more information, see "Configuring the Solaris CIFS Service Operation Mode (Task Map)" in the Solaris CIFS Administration Guide.

Troubleshooting Tips

  • Use the cifs-chkcfg.sh script to verify the system's Solaris CIFS service configuration. The script reports configuration errors. If the script reports no errors, your configuration should be okay.

    NOTE: The cifs-chkcfg.sh script does not currently verify Kerberos configuration.

    You must run this command as superuser or an appropriate role.

    Download the cifs-chkcfg.sh script.

  • Use the cifs-gendiag.sh script to generate helpful troubleshooting information about your Solaris CIFS environment.

    You must run this command as superuser or an appropriate role.

    You can include output from this command when you report a problem to the mailto:cifs-discuss@opensolaris.org discussion list.

    Download the cifs-gendiag.sh script.

Solaris CIFS Service Troubleshooting

The following are troubleshooting issues for the Solaris CIFS service.

File Name Case-Sensitivity Issues

Sometimes you might experience unexpected behavior when performing basic file operations. This behavior might be related to the file system being unable to handle case-insensitive operations.

CIFS clients usually expect a case-insensitive file system for correct operation. The use of a ZFS[tm] file system that has been created in mixed-case or case-insensitive mode should allow you to circumvent these problems.

To create such a ZFS file system, use the following command:

# zfs create -o casesensitivity=mixed fsname

Cannot Join a Windows Domain

To authenticate users from a Windows domain, the Solaris CIFS service must locate a domain controller, authenticate, and then add a computer account to the domain.

Users from the domain are not able to establish a connection to the Solaris CIFS service unless this process succeeds.

Checking the DNS Configuration

The Solaris CIFS service must be running for the smbadm join command to succeed.

If Active Directory (AD) is configured, the Solaris CIFS service attempts to locate the domain controller by means of DNS. If the service cannot locate the domain controller, configure DNS properly.

The following configuration issues might prevent you from configuring the Solaris CIFS service in domain mode:

  • Missing DNS domain. Ensure that the fully qualified AD domain name has been added to the search list or as the local domain in /etc/resolv.conf. If your configuration is incorrect, you might see the failed to join domain domain-name (INVALID_PARAMETER) error when attempting to join the domain.
  • Missing DNS server. Ensure that the IP address of the AD DNS server is added as the name server in /etc/resolv.conf. If your configuration is incorrect, you might see the failed to find any domain controllers error when attempting to join the domain.
  • DNS host lookup not used. Ensure that DNS is used for host lookup in the /etc/nsswitch.conf file.
Ensuring That Kerberos Is Correctly Configured

You might see the following error messages, which indicate that Kerberos is not correctly configured:

  • k5_kinit: KDC has no support for encryption type

    When this error occurs, you must reset the Domain Administrator password by re-entering the original password.

    This error is a known issue on Windows where DES encryption keys are not created for the administrator under certain circumstances. For more information, see Microsoft knowledge base article 248808.
  • k5_kinit: getting initial credentials (KDC reply did not match expectations)

    Ensure that the Kerberos Realm specified in the /etc/krb5/krb5.conf uses uppercase characters.
  • k5_kinit: getting initial credentials (Cannot resolve network address for KDC in requested realm)

    This problem can be corrected by ensuring that the configuration is correct in one of these ways:
    • Ensure that DNS is used for host lookup in the /etc/nsswitch.conf file.
    • Ensure that the IP address of the DNS server is added as the name server in the /etc/resolv.conf file.

      Check the resolve.conf file if you also see the following log entries:

      Jan 4 10:27:58 pb-49 smbd[101148]: [ID 290708 daemon.debug] NS Found 10.1.98.13 name server
      Jan 4 10:27:58 pb-49 smbd[101148]: [ID 290708 daemon.debug] NS Found 10.1.98.12 name server
      Jan 4 10:27:58 pb-49 smbd[101148]: [ID 327122 daemon.debug] NS Found 2 name servers
      Jan 4 10:27:58 pb-49 smbd[101148]: [ID 995127 daemon.error] dyndns: UDP send error (Bad file number)
      Jan 4 10:27:58 pb-49 smbd[101148]: [ID 342079 daemon.error] smb_ads: send/receive error
      Jan 4 10:27:58 pb-49 smbd[101148]: [ID 995127 daemon.error] dyndns: UDP send error (Bad file number)
      Jan 4 10:27:58 pb-49 smbd[101148]: [ID 342079 daemon.error] smb_ads: send/receive error
      Jan 4 10:27:58 pb-49 smbd[101148]: [ID 327097 daemon.error] smb_ads: No ADS host found from configured nameservers
Ensuring That You Specify the Correct Password for Your Domain User

The user that you specify on the smbadm join command line must have the correct password and the authority to create computer accounts. Typically, you must specify a user account that is a member of the Domain Administrators global group.

The following error message only appears if you supply the wrong password for the administrative user:

failed to join domain-name (LOGON_FAILURE)

This error message might also appear if packet signing is enabled on the domain controller. So, you must disable packet signing on the domain controller before you can successfully join a domain.

If you attempt to join as a domain user who does not have administrative privileges, the join fails with insufficient access error messages.

Ensuring That Your Domain User Has Sufficient Administrative Privileges

The user that you specify on the smbadm join command line must be a member of the Domain Administrators global group.

The following error message only appears if you attempt to join as a domain user who does not have administrative privileges. The join fails with insufficient access error messages.

smbd: failed joining domain-name (UNSUCCESSFUL)

Ensuring the Firewall Software Does Not Filter Out Needed Ports

Some firewall software might filter out certain ports that will prevent a Solaris CIFS server from successfully joining a domain.

For example, the following error message appears if the Kerberos Change & Set Password port is filtered out:

08:02:57 smbd[446]: [daemon.error] smb_krb5_setpwd: Result: (135207664)

The following network protocols are used by the smbd service during a domain join operation, and must be available for the Solaris CIFS service:

Network Protocol Default Port
Domain Name Service (DNS) 53
Kerberos V Authentication 88
Kerberos V Change & Set Password (SET_CHANGE) 464
Kerberos V Change & Set Password (RPCSEC_GSS) 749
LDAP 389
NetBIOS Datagram 138
NetBIOS Name Service 137
SMB-over-NetBIOS 139
SMB-over-TCP 445

Port assignment settings appear in the /etc/services file. For more information, see the services(4) man page.

Checking Intermittent Domain Connectivity

Checking the Domain Controller Selection

Sometimes the Solaris CIFS service might lose its connection to the domain controller. In such a situation, Windows users are denied access to the Solaris CIFS service.

The connection might be lost if the network experiences connectivity problems or if the primary domain controller fails.

The solution to any of these problems is to rejoin the Windows domain. See "How to Configure the Solaris CIFS Service in Domain Mode" in the Solaris CIFS Administration Guide.

idmapd Unable to Contact AD When in Workgroup Mode

The idmapd server attempts to contact AD even if the Solaris CIFS service is in workgroup mode. As a result, idmapd issues errors.

To work around this problem, remove all name-based mapping rules and ignore any errors from idmapd about its failure to contact AD.

Viewing Solaris CIFS Service Property Settings

Much of the Solaris CIFS service configuration uses the sharectl(1M) command to set properties. Before you change property values, you should view the current property settings by running the sharectl get smb command.

Excluding IP Addresses From WINS Name Resolution

When using WINS/NetBIOS, Windows domain controllers (DC) do not automatically respond to the IP address from which they received a request. They perform a WINS or NetBIOS cache lookup and for multihomed servers the DC can respond to a different IP address belonging to the server. If the IP address is not accessible to the DC, it will appear as if the DC has not responded to the server. Thus, it may be necessary to exclude some IP addresses when a multihomed server registers with WINS.

The following example shows how to configure the Solaris CIFS service as a WINS client. The primary WINS server is set to IP address 172.16.48.20, the secondary WINS server is set to IP address 172.16.48.21, and IP addresses 192.168.48.22 and 192.168.48.23 are excluded from WINS resolution.

# sharectl set -p wins_server_1=172.16.48.20 smb
# sharectl set -p wins_server_2=172.16.48.21 smb
# sharectl set -p wins_exclude=192.168.48.22,192.168.48.23 smb

Changes to Windows Group Membership and to User Mapping Do Not Take Effect

Windows clients use an access token to assign user data and group membership. This token is assigned when the client connects to the CIFS service. Any changes made to this token are not reflected until the next time the user connects.

To force changes to take effect immediately, the user must disconnect from the CIFS service by logging out of all connected workstations.

Windows Clients Cannot Connect by NetBIOS Name or Are Missing From Browse List or Network Neighborhood

A master browser is a server that is configured to manage CIFS/SMB browse lists and to respond to client requests for them. A Windows server is configured as a master browser by default.

The Solaris CIFS service is not configured as a master browser. The Solaris CIFS service dedicates all of its resources to file sharing.

For browsing to function correctly, each subnet or physical network segment must have a master browser. To make the Solaris CIFS service available through browse lists, the system on which it runs should be located on the same segment and subnet as a Windows server.

Configuring a Windows server improves the performance of browsing and might compensate for the lack of a master browser on some segments.

Cannot Set Share Security, All Shares Inherit the Security of the Directory Object

The security implementation of the Solaris CIFS service only secures files and directories. The effective security of a CIFS share is always the security of the directory to which it points.

Older Versions of Windows Cannot Copy Files Larger Than 4 Gbytes

You might see this problem if your client is running Windows 2000 or an older version of Windows.

  • If you are running a Windows 2000 client, apply the latest service pack.
  • If you are running a version older than Windows 2000, you might be able to work around the problem by using the Windows backup utility or by using a similar third-party product.

Cannot Use CIFS to Map Drives

To map a drive or to connect to a share, you must have read access to the directory to which the share points.

If the Solaris CIFS service is in domain mode, you must also be logged in to the domain.

To ensure that a user can connect to a share, do the following to check and modify permissions:

  1. Log in to the system that is running the Solaris CIFS service.
  2. Become superuser.
  3. Obtain the user name and group name of the owner.

    # ls -l pathname

    For example, the following output indicates that the share is a directory with 750 permissions. The owner is root and the group is sys.

    # ls -ld /vol1/data
    drwxr-x--- 41 root sys 1024 Jan 2 23:19 /vol1/data
  4. Determine the permissions necessary for the user to access the directory.
  5. Use the chmod command to change the permissions of the directory.

Cannot See the Security Tab From Windows Clients

Some Windows clients do not show the security tab unless you have permission to view or change security.

For information about how to view and modify share permissions, see #Cannot Use CIFS to Map Drives.


Microsoft Access or SQL Server Sessions Time Out After a Period of Inactivity

Applications can send SMB echo requests periodically to keep idle sessions open or to reconnect, as required, if a session times out due to inactivity. If an application appears unable to deal with an idle session timeout, the CIFS service keep_alive property can be set to 0 to disable the session inactivity timer.

# sharectl set -p keep_alive=0 smb

Cannot Add Windows Local Groups to Access Control List

Windows local groups cannot be used to assign security on remote systems. A local group can only be used on the individual computer on which it is created. A local group is not stored in the domain SAM database.

Windows domain controllers are an exception to this behavior. Domain controllers share a set of local groups that can only be shared with other domain controllers. To make security assignments to the Solaris CIFS service, use global groups.

The Solaris CIFS service has its own set of local groups that are provided for Windows compatibility purposes. These local groups permit a limited set of privileges, and they can also be used for security assignments to individual files and folders.

Note - Windows domain local groups are not supported.

CIFS Browsing Fails When sharesmb=on Is Set on a ZFS Pool

If you have a ZFS pool with datasets and you run the zfs set sharesmb=on command on the pool, the pool and all its datasets are shared, but unavailable for browsing by Windows systems.

To work around this problem, do the following:

  1. Determine whether your ZFS pool and dataset versions support CIFS shares.

    # zpool get version pool
    # zfs get version dataset


    Support for CIFS shares requires that ZFS pools be at least Version 9 and that ZFS datasets be at least Version 3.
  2. (Optional) Upgrade your ZFS pools and datashares.

    # zpool upgrade pool
    # zfs upgrade dataset


    For more information, see the zpool(1M) and zfs(1M) man pages.
  3. Map the shares in one of the following ways:
    • Run the zfs set sharesmb=on command on any of the lower-level datasets instead of the pool.
    • Map the shares directly.

Samba or CIFS Service Cannot Bind Various Ports

You will see errors if you attempt to run both the Samba service, svc:/network/samba:default, and the Solaris CIFS service, svc:/network/smb/server:default simultaneously.

The Samba and Solaris CIFS services are mutually exclusive because they both attempt to listen on the same ports. Only one service should be enabled at any time.

To disable either the Samba or Solaris CIFS service, do one of the following:

  • Disable the Samba service. Use the svcadm disable svc:/network/samba command.
  • Disable the Solaris CIFS service. Use the svcadm disable smb/server command.


CIFS Shares on a ZFS File System are Inaccessible After a Reboot

CIFS shares on a ZFS file system might be inaccessible to CIFS clients if you reboot the Solaris CIFS server.

Run the following command to reshare the ZFS shares:

# sharemgr start -P smb zfs

invalid password Errors Appear When Mapping a Drive or Browsing Computers in the Workgroup

When you map a drive or browse computers in your workgroup, you might see invalid password errors. If you see these errors, check to see that the /var/smb/smbpasswd file includes information for the appropriate users.

Also, ensure that the pam_smb_passwd.so.1 entry is in the /etc/pam.conf file and that you use the passwd command to set your password.

For more information, see "How to Configure the Solaris CIFS Service in Workgroup Mode" in the Solaris CIFS Administration Guide.

Access Control List Inheritance Issues

Access control list (ACL) behavior differs between Windows systems and ZFS file systems on Solaris systems. You might experience Windows ACL inheritance problems because of the access control entry (ACE) ordering used by the default ZFS ACL.

The default ZFS ACL is designed to comply with POSIX, which results in the interleaving of allow and deny ACEs. Windows expects all deny ACEs to precede all allow ACEs.

You can override the default ZFS behavior by changing the ACL on the root directory to provide the equivalent of Everyone:FullControl as follows:

# chmod 777 /pool-name
# chmod A=everyone@:rwxpdDaARWcCos:fd:allow /pool/fs-name

For information about the chmod options, see the chmod(1) man page.

You can verify the ACL by viewing it on Windows or by running the following command on a Solaris system:

# ls -V -d /pool-name/fs-name

You can apply this ACL recursively to all subdirectories and files for existing file systems from Windows or from the Solaris OS.

If you apply the ACL when the file system is first created, the ACL will be propagated according to the normal inheritance rules.

If a directory has a default ZFS ACL, when a file or folder is created under this directory from Windows, it has two ACEs: one for the owner and one for SYSTEM. To change this behavior, update the root directory's ACL by running the chmod commands shown previously.

Missing Security Tab on XP Clients

You might not see the security tab for a file or folder when using an XP client for the following reasons:

  • You do not have enough permissions to see the security settings of the file or folder
  • Simplified file sharing is enabled on your client

To disable simplified file sharing, go to Control Panel->Folder Options->View, and unselect Use Simple File Sharing (Recommended), and click Apply.

For more information about disabling simplified file sharing and setting permissions on a shared folder, see Microsoft knowledge base article 307874.

Cannot Access the Solaris CIFS Server in Workgroup Mode

This problem was introduced in Solaris Express Community Edition (SXCE) Build 90.

After configuring a CIFS server in workgroup mode, a CIFS client is unable to access shares on the Solaris CIFS server. For example, the following command uses the Solaris CIFS client to list shares on a CIFS server:

# smbutil view //cuser@saturn
Password:
smbutil: session setup phase failed: syserr = authentication failed
smbutil: could not login to server SATURN: syserr = authentication failed

To work around this problem, specify any value for the default_domain property, and refresh the idmapd service.

# svccfg -s idmap setprop config/default_domain = astring: any-value
# svcadm refresh idmap

Joining a Windows 2008 Domain

To join a Windows 2008 domain, your Solaris system must be running at least SXCE Build 94.

Before joining the domain, set the LAN Manager authentication level as follows:

# sharectl set -p lmauth_level=2 smb

Note - The domain join will fail if the LMCompatibilityLevel setting on the Windows 2008 domain controller is 5 (mandatory NTLMv2 authentication) rather than the default value of 3.

Solaris CIFS Client Troubleshooting

Viewing Solaris CIFS Client Property Settings

The Solaris CIFS client configuration uses the sharectl command to set properties. Before you change property values, view the current property settings by running the sharectl get smbfs command.

Access Denied Message When Accessing a Server

You get an Access Denied error when attempting to access or view CIFS shares from a server. This problem might occur because the password you supplied is wrong or the CIFS server is part of a domain.

If the CIFS server is part of a domain, you must provide the domain name for the smbutil view or mount command. Otherwise, the server assumes that you are attempting to authenticate a local user, and the authentication process fails.

For example, if the server solarsystem is in the MYDOMAIN domain, the following commands would be appropriate to view and access CIFS shares as user cal:

# smbutil view "//MYDOMAIN;cal@solarsystem"
# mount -F smbfs "//MYDOMAIN;cal@solarsystem/tmp" /mnt

To obtain the domain name, use the smbutil status server command, which sends a NetBIOS query to the specified server:

# smbutil status solarsystem
Workgroup: MYDOMAIN
Server: SOLARSYSTEM

Cannot View or Mount CIFS Shares

If you are unable to view or mount CIFS shares, use the smbutil view -A //server command. The -A option gives anonymous access to the server if the server permits such access.

Cannot Mount CIFS Shares as a Regular User

You might see the following error message when you attempt to mount a CIFS share as a regular user on a mount point that you own:


$ mount -F smbfs //username@server-name/share-name mount-point
mount: mount_smbfs: mount-point: Not owner

Verify that you have the following entries in your /etc/security/exec_attr file:

Basic Solaris User:solaris:cmd:::/usr/lib/fs/smbfs/mount:privs=sys_mount
Basic Solaris User:solaris:cmd:::/usr/lib/fs/smbfs/umount:privs=sys_mount

These entries in the /etc/security/exec_attr file enable you to mount and unmount CIFS shares on mount points that you own as a regular user.

tar and gtar Issues file changed as we read it Warnings

You might see the file changed as we read it warning in the following situations:

  • When you use the Solaris CIFS client to mount a CIFS share, and use the gtar utility to write the share to a tape
  • When you use the Solaris CIFS client to mount a CIFS share, and use the Solaris tar utility checks file attributes after setting them

Other than these warnings, the tar and gtar operations succeed as expected.

You can ignore these warnings.

Note - smbfs ignores calls to set any file or directory attributes, as those have no direct representation in CIFS. Also, smbfs does not support the “UNIX extensions” that would permit the storing of attributes with some servers.

Viewing XATTR Status for Mounted Shares

By default, shares that are mounted by the mount_smbfs command enable Solaris extended attributes by setting the xattr mount option. However, if the CIFS server does not support Windows named streams, shares mounted by mount_smbfs set the noxattr mount option.

To verify whether the xattr or noxattr mount option is used, do the following:

$ mount -v | grep 'type smbfs'

The following example shows that the share mounted on /mnt has xattr set, while the share mounted on /tmp has noxattr set:

$ mount -v | grep 'type smbfs'
//root@solarsystem/tmp on /mnt type smbfs remote/read/write/setuid/devices/intr/xattr/dev=5080000 on Tue Jul 8 18:20:48 2008
//root@pluto/files on /files type smbfs remote/read/write/setuid/devices/intr/noxattr/dev=4800000 on Mon Jul 7 11:37:26 2008

Identity Mapping Troubleshooting

Viewing Identity Mapping Service Property Settings

The identity mapping service uses the svccfg(1M) command to set properties. Before you change property values, you should view the current property settings.

To view configuration properties related to the idmap service, run one of the following commands:

  • # svccfg -s idmap listprop "config/*"
  • # svcprop -p config svc:/system/idmap

To view all properties related to the idmap service, run one of the following commands:

  • # svccfg -s idmap listprop
  • # svcprop svc:/system/idmap

Saving and Restoring Name-Based Mapping Rules

You might need to back up and restore your name-based mapping rules.

For more information about the idmap export, idmap import, and idmap list commands, see the idmap(1M) man page.

To back up the rules, perform the following steps:

  1. Save your name-based mapping rules in one of the following ways:
    • Export the rules.

      # idmap export -f output-file format
    • List the rules.

      # idmap list >output-file
  2. Disable the idmap service.

    # svcadm disable idmap
  3. Remove the idmap.db databases.

    # rm /var/idmap/idmap.db /var/run/idmap/idmap.db
  4. Reboot the system.

To restore the rules, use the mapping rule output you saved during the backup procedure. Do one of the following to restore based on your backup method:

  • Use the idmap import command.

    # idmap import -f input-file format
  • Use the idmap list command.

    Run output-file as a shell script.

    # sh ./output-file

Viewing Details About Mappings

If you encounter unexpected mapping results, use the idmap dump and idmap show commands to gather data. Each command has a -v option that produces detailed information about mappings.

For more information, see “How to Show All Established Mappings” and “How to Show a Mapping for a Particular Identity” in the Solaris CIFS Administration Guide.

idmap Commands Issue Domain not found Error

This problem was introduced in Solaris Express Community Edition (SXCE) Build 90.

The idmap show command issues a Domain not found error.

For example, the following commands issue the Domain not found error:

# idmap show -c uid:20000
Mappings not obtained because of RPC problem (Domain not found)
# idmap show -c unixuser:cuser
unixuser:cuser -> winname:
Error: Domain not found

To work around this problem, specify any value for the default_domain property, and refresh the idmapd service.

# svccfg -s idmap setprop config/default_domain = astring: any-value
# svcadm refresh idmap

Cannot Add Local Users and Groups to ACLs

You might encounter problems on Windows XP or Vista systems when attempting to add local users and groups to ACLs.

The problem is caused by a mismatch between the number of subauthorities in a system SID generated by a Solaris system and a Windows system. A Windows system SID has four subauthorities and a Solaris system SID has five.

To workaround the problem, update the system running the Solaris CIFS service to use at least Solaris Express Community Edition Build 94. Also, remove the config/machine_sid property so that the idmap service can recreate a system SID with four subauthorities:

# svccfg -s idmap delprop config/machine_sid
# svcadm restart idmap