Connecting using a CIFS client

You can connect to a CIFS share using a CIFS client, such as Microsoft Windows™.

To access the share or export, a user must have appropriate POSIX permissions for accessing the path, and ACL authorization to read (r) and execute (x) each directory in the full path of the directory on which the share or export is mounted. If an Storwize V7000 Unified system administrator has disabled the --bypassTraversalCheck option of the chcfg Storwize V7000 Unified CLI command, which is enabled by default, retain the traversal rights ACE entry to ensure that users are able to access the share or export and its subdirectories. For example, to access a share or export mounted at /ibm/mydir/mysubdir/myexport, the above ACLs, at a minimum, must be applied to /ibm, /ibm/mydir, /ibm/mydir/mysubdir and /ibm/mydir/mysubdir/myexport. See Creating shares or exports, Managing authorization and access control lists, and Authorization limitations.

Note: The CIFS protocol does not include a built-in failover capability to transparently reestablish a lost CIFS connection. If a CIFS connection to the system is lost due to a failover event, the CIFS client must establish a new CIFS connection and reopen all of the file handles that were open when the connection was lost. This is a limitation of the CIFS protocol. The system only synchronizes file data to disk when it receives a close request for a file. If an file module failover occurs during a write request, the most recent changes might not be written to disk. Therefore, only file changes that were both written and closed are always saved. The CIFS clients might potentially experience corrupted files for any files that were open for write at the time of failover. For more information, see CIFS and NFS data integrity options.

The used space and free space reported to CIFS clients also depends on the quotas applicable to the current user. For details, see the description in Managing quotas.

Consider the following restrictions, while using Storwize V7000 Unified for Kerberized CIFS access:

The time must be synchronized across the KDC server, Storwize V7000 Unified cluster, and the CIFS clients, or access to a CIFS share is denied.
In MIT KDC configurations for the CIFS services, the service principal name must use the NetBIOS name (the cluster name used in cfgcluster command). For example, if the cluster name is FOO and the realm is KDC.COM, the service principal name should be cifs/foo@KDC.COM.
The clients should use only the NetBIOS name, while accessing a CIFS share. Using any other name or IP address might either cause a failure or fallback to the NTLM authentication.
With Active Directory KDC, you can use DNS alias (CNAME) for Kerberized CIFS access. To use the alias, you must register the DNS alias (CNAME) record for the NetBIOS name (system account name) using the SetSPN tool available on Active Directory server. For example, if the NetBIOS name is FOO and the DNS alias is BAR, use the SetSPN tool from the command prompt of the Active Directory server to register the following record:
setspn -A cifs/BAR FOO

Not registering the DNS alias record for the NetBIOS name might cause access to the CIFS shares to be denied with the following error code: KDC_ERR_S_SPRINCIPAL_UNKNOWN.
On Linux clients, to use Kerberized CIFS access for Storwize V7000 Unified configured with MIT KDC, you must at least have the 3.5.9 version of Samba client installed. The Linux clients having an older Samba client might encounter the following error, while trying to access CIFS shares:
```
ads_krb5_mk_req: krb5_get_credentials failed for 
foo$@KDC.COM (Server not found in Kerberos database)
cli_session_setup_kerberos: spnego_gen_negTokenTarg 
failed: Server not found in Kerberos database
```

The following examples are not meant to be in-depth. For more information contact your network administrator for assistance. The examples use the following definitions:

Netbios/DNS name: unified03
Share name: gpfs0all

Several methods are available for connecting to the Storwize V7000 Unified system with a Windows client:

Using the Universal Naming Convention (UNC) syntax.
Mapping a network drive using Windows Explorer.
Mapping a network drive using NET.EXE from the Windows command line.

Example 1: UNC mapping

Using Windows Explorer, enter the path to the network share in the address bar using UNC syntax:

\\unified03\gpfs0all

If you are not currently authenticated to the domain on which the share resides, you are prompted for your credentials.

Figure 1. Windows Authentication Prompt

After authentication, a new window opens showing the contents of your share. See Figure 2.

Figure 2. Explorer view using UNC paths to connect to the Storwize V7000 Unified system

Example 2: Mapping a network drive using Windows Explorer

To map a network drive to a drive letter from Windows Explorer, click Tools > Map Network Drive or use the icon .

You are prompted for the drive letter for assigning the share and the network path of the share. See Figure 3.

Figure 3. Explorer screen using drive letters to connect to the Storwize V7000 Unified system

Optionally, you can specify a user name and password to access the share using the Connect using a different user name option. See Figure 4.

Figure 4. Window prompting for authentication information

Note: The domain separator on Windows clients is a backslash \. That means you must enter w2k3dom01\test1 for the user test1 from the domain w2k3dom01.

Example 3: Mapping a network drive using NET.EXE

The following example maps the share gpfs0all from unified03 to the drive letter X and prompts for the password without echoing the password to the screen:

C:> net use x: \\unified03\gpfs0all * /user:DOMAIN\\username

The command waits for your password input. If your authentication information is successful, you are notified that the command completed successfully.