You are on page 1of 86

Managing Celerra for a Multiprotocol Environment

P/N 300-002-676 Rev A02

Version 5.5
July 2008

Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Windows and multiprotocol documentation . . . . . . . . . . . . . . . . . . . .3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 CIFS and NFS system requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 EMC NAS Interoperability Matrix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 User interface choices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Celerra multiprotocol environment roadmap . . . . . . . . . . . . . . . . . . . . . . .8 Configuring CIFS user ID resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Interoperability considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 NFS and CIFS file naming conventions . . . . . . . . . . . . . . . . . . . . . . .10 Resolving file naming conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 Symbolic links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 File system linking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Setting security on file system objects . . . . . . . . . . . . . . . . . . . . . . . . . . .18 UNIX security model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Windows security model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 User credentials and access checking . . . . . . . . . . . . . . . . . . . . . . . .20 Selecting an access-checking policy . . . . . . . . . . . . . . . . . . . . . . . . .23 Using MIXED and MIXED_COMPAT . . . . . . . . . . . . . . . . . . . . . . . . . .25 Inheritance rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 Backing up and restoring file system objects . . . . . . . . . . . . . . . . . .29 Setting the access-checking policy . . . . . . . . . . . . . . . . . . . . . . . . . .30 Migrating to MIXED and MIXED_COMPAT . . . . . . . . . . . . . . . . . . . . .31 Resetting MIXED and MIXED_COMPAT . . . . . . . . . . . . . . . . . . . . . . .33 Creating a Windows-style credential for UNIX users . . . . . . . . . . . . . . . .34 Processing a Windows NT credential . . . . . . . . . . . . . . . . . . . . . . . . .35 Accessing a trusted domain using Windows 2000 . . . . . . . . . . . . . .36 Setting the Windows default domain . . . . . . . . . . . . . . . . . . . . . . . . .37 Defining the Windows NT credential cache . . . . . . . . . . . . . . . . . . . .37 Adding groups to a Windows NT credential . . . . . . . . . . . . . . . . . . .38 Generating Windows NT credentials . . . . . . . . . . . . . . . . . . . . . . . . .40 Using only UNIX permissions for access checking . . . . . . . . . . . . . . . . .41 Setting the file locking policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 Mounting the file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45 Viewing/setting UNIX permissions from a Windows client . . . . . . . . . . .46 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Configuring the cifs acl.extacl parameter . . . . . . . . . . . . . . . . . . . . .47
1 of 86

Using the Data Mover as a stand-alone DFS server . . . . . . . . . . . . . . . . .50 DFS root servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Wide links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Enabling and disabling DFS support . . . . . . . . . . . . . . . . . . . . . . . . .51 Configuring and administering DFS support . . . . . . . . . . . . . . . . . . .51 Using wide links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 Processing steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 Establishing wide links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 Viewing/setting Windows ACLs from a UNIX client . . . . . . . . . . . . . . . . .64 Retrieving emcgetsd and emcsetsd . . . . . . . . . . . . . . . . . . . . . . . . . .64 Viewing ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64 Modifying ACLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70 server_log error message construct. . . . . . . . . . . . . . . . . . . . . . . . . .70 Kerberos error codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 NT status codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 Error messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72 Problem situations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 Related information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 Customer training programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83

2 of 86

Version 5.5

Managing Celerra for a Multiprotocol Environment

Introduction
In a UNIX environment, users use the Network File System (NFS) protocol to access file systems. In a Windows environment, users use the Common Internet File System (CIFS) protocol to access file systems. The Celerra Network Server supports a mixed NFS and CIFS environment by providing multiprotocol access capabilities such as access-checking policies and locking mechanisms enabling both UNIX and Windows users to share the same file systems. This technical module is part of the Celerra Network Server information set and is intended for system administrators responsible for implementing the Celerra Network Server in their mixed Windows and UNIX environment.

Windows and multiprotocol documentation


The following technical modules in the Celerra Network Server information set explain how to configure and manage Celerra in a Windows environment and a multiprotocol environment:

Configuring CIFS on Celerra: explains how to configure a basic CIFS configuration on the Celerra Network Server using the command line interface (CLI). You can also configure this initial environment using the Celerra Manager. Managing Celerra for the Windows Environment: contains advanced procedures you may need to perform after the initial configuration of CIFS on the Celerra Network Server and instructions for modifying and managing Celerra in a Windows environment. Managing Celerra for a Multiprotocol Environment: contains procedures for configuring and managing Celerra in a mixed environment of UNIX and Windows clients.

Terminology
These terms are important to understanding the Celerra Network Server in the Windows environment. The Celerra Network Server User Information Glossary technical module provides a complete list of Celerra terminology.
ACL (Access Control List): In Windows, a list of access control entries (ACEs) that provide information about the users and groups that are allowed access to an object. Active Directory (AD): An advanced directory service included with Windows 2000 Servers. It stores information about objects on a network and makes this information available to users and network administrators through a protocol such as LDAP (Lightweight Directory Access Protocol). authentication: The process for verifying the identity of a user who is trying to

access a resource or object, such as a file or a directory.


CIFS (Common Internet File Service): A file-sharing protocol based on the Microsoft

Server Message Block (SMB). It allows users to share file systems over the Internet and intranets. The CIFS protocol is primarily used for file sharing by Windows platforms.

Managing Celerra for a Multiprotocol Environment

Version 5.5

3 of 86

CIFS Server: A logical server that uses the CIFS protocol to transfer files. A Data

Mover can host many instances of a CIFS Server. Each instance is referred to as a CIFS server.
CIFS Service: A CIFS server process that runs on the Data Mover and presents shares on a network as well as on Windows-based computers. Data Mover: Celerra Network Server cabinet component running its own operating system that retrieves files from storage devices and makes them available to a network client. Default CIFS Server: The CIFS server that is created when you add a CIFS server

and do not specify any interfaces (with the interfaces= option of the server_cifs -add command). The default CIFS server uses all interfaces not assigned to other CIFS servers on the Data Mover.
DNS (Domain Name System): A name resolution software that allows users to locate

computers and services by name on a UNIX network or TCP/IP network. The DNS server maintains a database of domain names, hostnames and their corresponding IP addresses, and services provided by these hosts.
domain: A logical grouping of Microsoft Windows servers and other computers that

share common security and user account information. All resources such as computers and users are members of the domain and have an account in the domain that uniquely identifies them. The domain administrator creates one user account for each user in the domain, and the users log in to the domain once. Users do not log in to each individual server.
file system: A method of cataloging and managing the files and directories on a

storage system.
GPO: In Windows 2000 or Windows Server 2003, administrators can use Group

Policy Objects to define configuration options for groups of users and computers. Windows Group Policy Objects can control elements such as local, domain, and network security settings.
NetBIOS: Network basic input/output system. A network programming interface and protocol developed for IBM personal computers. NetBIOS name: A name that is recognized by WINS, which maps the name to an IP

address.
share name: The name given to the resource on a file system or the file system

itself that was made available from a particular CIFS server to CIFS users. There may be multiple shares with the same name, shared from different CIFS servers.
SMB Server Message Block: The underlying protocol used by the Common Internet

File System (CIFS) protocol that was enhanced for use on the Internet to request file, print, and communication services from a server over the network. The CIFS protocol uses SMB to provide file access and transfer to many types of network hosts. The SMB protocol is an open, cross-platform protocol for distributed file sharing, and it is supported by all Windows platforms.
Virtual Data Mover (VDM): A Celerra software feature that enables users to administratively separate CIFS servers, replicate their CIFS environments, and move CIFS server from Data Mover to Data Mover with ease.

4 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Windows 2000/Windows Server 2003 domain: A Microsoft Windows domain

controlled and managed by a Microsoft Windows server/Windows 2003 server using the Active Directory to manage all system resources and using the DNS for name resolution.
Windows NT domain: A Microsoft Windows domain controlled and managed by a

Microsoft Windows NT server using a SAM (Storage Area Management) database to manage user and group accounts and a NetBIOS namespace. In a Windows NT domain, there is one primary domain controller (PDC) that has a read/write copy of the SAM, and possibly several backup domain controllers (BDCs) with read-only copies of the SAM.

Managing Celerra for a Multiprotocol Environment

Version 5.5

5 of 86

CIFS and NFS system requirements


For system requirements, see the following:

Configuring CIFS on Celerra technical module for CIFS access requirements Configuring NFS on Celerra technical module for NFS access requirements EMC NAS Interoperability Matrix for a listing of supported NFS and CIFS clients

EMC NAS Interoperability Matrix


The EMC NAS Interoperability Matrix is available on Powerlink. It contains definitive information on supported software and hardware, such as backup software, Fibre Channel switches, and application support for Celerra networkattached storage (NAS) products.

6 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

User interface choices


The Celerra Network Server offers flexibility in managing networked storage based on your support environment and interface preferences. This technical module describes how to configure and manage the Celerra Network Server in a multiprotocol environment using the command line interface (CLI). You can also perform some of these tasks using one of the Celerra management applications:

Celerra Manager - Basic Edition Celerra Manager - Advanced Edition Celerra Monitor Microsoft Management Console (MMC) snap-ins Active Directory (AD) Users and Computers (ADUC) extensions Learning about Celerra Celerra Manager Online Help Monitoring Celerra Applications online help system on the Celerra Network Server Documentation CD

For additional information about managing your Celerra, refer to:


The Installing Celerra Management Applications technical module includes instructions on launching Celerra Manager, and on installing the MMC snap-ins and the ADUC extensions.

Managing Celerra for a Multiprotocol Environment

Version 5.5

7 of 86

Celerra multiprotocol environment roadmap


Table 1 lists the tasks to manage a Celerra Network Server for a multiprotocol environment as described in this technical module.
Table 1 Managing Celerra for a multiprotocol environment roadmap

Task
Set up user ID resolution Understand interoperability issues within a mixed NFS and CIFS environment, such as the differences in file system names and resolving symbolic links for Windows users Set user authorization for file system objects through the Celerra access-checking policies Create a Windows-style credential for UNIX users Set the file system locking policy in a mixed NFS and CIFS environment Use a Data Mover to provide DFS (Distributed File System) support Using DFS functionality, enable Windows clients to access files from the same directory as UNIX clients do when following absolute symbolic links View and set Windows ACLs from UNIX clients

Procedure
"Configuring CIFS user ID resolution" on page 9 "Interoperability considerations" on page 10

"Setting security on file system objects" on page 18 "Creating a Windows-style credential for UNIX users" on page 34 "Setting the file locking policy" on page 43

"Using the Data Mover as a stand-alone DFS server" on page 50 "Using wide links" on page 56

"Viewing/setting Windows ACLs from a UNIX client" on page 64

8 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Configuring CIFS user ID resolution


Every user of the Celerra Network Server, either a Windows user or a UNIX user, must be identified by a unique numeric user identifier (UID) and group identifier (GID). Windows, however, does not use numeric IDs to identify users. Instead, it uses strings called security identifiers (SIDs). Therefore, before you configure the Windows file-sharing service (referred to as CIFS) on your Celerra Network Server, you must select a method of mapping Windows SIDs to UIDs and GIDs.The method you use depends on whether you have a Windows-only or UNIX and Windows (multiprotocol) environment. These methods include:

Usermapper (Internal or External) Active Directory Local files Network Information Service (NIS)

The Configuring Celerra User Mapping technical module provides a list of the tools and methods you can use to map Windows users to UNIX-style UID and GIDs and the tools you can use to migrate users from a single-protocol environment to a multiprotocol environment.

Managing Celerra for a Multiprotocol Environment

Version 5.5

9 of 86

Interoperability considerations
Although multiprotocol file sharing appears mostly seamless to end users, there are some special considerations to be aware of when supporting a multiprotocol environment. This section describes the following interoperability issues:

NFS and CIFS file naming conventions Symbolic links File system linking

NFS and CIFS file naming conventions


Table 2 explains the differences in tile naming conventions between the NFS and CIFS protocols.
Table 2 NFS and CIFS file naming conventions

NFS names
Case-sensitive.

CIFS names
Not case-sensitive, but they are casepreserving. Does not allow a directory to have two files whose names differ only in case, because to CIFS these are duplicate names.

Allows a directory to hold files whose names differ only in case.

Note
When creating UID and GID names for Windows clients, remember that Windows names (usernames, domain names, and global group names) must be written in lowercase in the NIS, the password files, and the group UNIX files. Be particularly careful to ensure this when doing explicit user and group mapping; if you spontaneously write the names like Windows, the Celerra Network Server does not recognize them.

Resolving file naming conflicts


Because file naming conventions differ, files created by an NFS user may occasionally present a conflict for a CIFS user. This occurs when an NFS user creates files in a single directory with names that differ only in case. To resolve naming conflicts, the Celerra Network Server distinguishes the CIFS filename by appending a numerical identifier. For example:

An NFS file, Aaa, in an NFS/CIFS directory is identical to CIFS users, Aaa. A second NFS file, aAA in the same directory is unique to NFS users, but is renamed for CIFS users to aAA~1. A third NFS file, aAa, is unique to NFS users, but is renamed for CIFS users to aAa~2.

10 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Symbolic links
Symbolic links are special nodes created by UNIX clients that point to another node (a file or directory called the target node). The target node is defined in a symbolic link node as a pathname. Normally, NFS symbolic links have no meaning to Windows clients because the client must resolve (follow) the symbolic link to its target. However, under certain circumstances, the Celerra Network Server resolves symbolic links for Windows clients so that these clients can access the same files and directories as UNIX clients can through a symbolic link.
Note: To ensure that symbolic links are backed up when using regular Windows-based backup tools (like NTbackup), set bit 3 of the cifs acl.extacl parameter. The section called Viewing/setting Windows ACLs from a UNIX client on page 64 explains the cifs acl.extacl parameter.

If the target is accessible, the user views the target node as a file or directory and does not know that they have followed a symbolic link. If the target is not accessible, the user sees the symbolic link as a file but cannot access that file. By default, the Celerra Network Server resolves symbolic links for Windows clients only if the target:

Does not contain an absolute path (full pathname). In other words, the target path cannot start with a slash (/). Does not refer to the parent directory of the directory containing the symbolic link (does not have a pathname that refers upwards using the .. component).

Examples of valid and invalid symbolic links

A symbolic link pointing to dir2/dir3 can be followed by Windows clients because the target is relative to the directory in which the link itself resides. Unless the shadow followabsolute parameter is set, a symbolic link that points to /dir1/dir2/dir3 cannot be followed by Windows clients. This is because the target is relative to the root of the file system and therefore cannot be resolved. A symbolic link pointing to ../file cannot be followed by Windows clients unless the shadow followdotdot parameter is set. Even then, the link is only translated if the target is within the same share as the link itself.

CAUTION

Microsoft clients do not distinguish between the symbolic link itself and the target of the symbolic link. Therefore, if a symbolic link refers to a directory, and a Windows user attempts to delete the symbolic link, both the link and the contents of the directory that the link references are deleted. Do not use Microsoft Office applications on files represented by symbolic links. When you update a file, Microsoft Office creates the updated file in the directory containing the symbolic link instead of in the symbolic links target directory. When the target is unreachable, you cannot remove a symbolic link through a Windows client. During the removal process, Microsoft Explorer tries to open the file (which is unreachable) and fails.

Managing Celerra for a Multiprotocol Environment

Version 5.5

11 of 86

Changing the default symbolic link behavior


The following system parameters modify the default behavior of symbolic links: shadow followdotdot If you want to support symbolic links with target paths that refer to parent directories, change the shadow followdotdot parameter. Even if you change this parameter, the target node must still be located in the same share space (you are not able to point outside of the share) unless you also enable the shadow followabsolutpath parameter. "Changing the shadow followdotdot parameter" on page 12 provides more information. shadow followabsolutpath If you want to support symbolic links that use absolute paths as their targets, change the shadow followabsolutpath parameter. "Enabling symbolic links with absolute paths" on page 13 provides more information.
Important: When you enable the shadow followabsolutpath parameter so you can follow absolute paths, the target is interpreted by the Data Mover. The Data Mover can only resolve paths that are relative to the root file system on the Data Mover. If this is a Virtual Data Mover, this path must be the root of the VDM (for example, /mountpoint/ directory); otherwise, a Windows client is unable to access the target. With NFS, clients read a symbolic links target path and try to access the target by doing a local lookup on the client. NIFS clients are only able to access targets with absolute paths if the clients have the same mount point as the Data Mover.

Changing the shadow followdotdot parameter


By default, Windows clients cannot follow symbolic links that contain pathnames that refer upwards to parent directories. If you alter the shadow followdotdot parameter, you can enable the following of symbolic links that contain the .. component.

CAUTION

Enabling the shadow followdotdot parameter so Windows clients can follow symbolic links upwards may create infinite loops in the namespace presented to Windows clients. Applications that perform a search of the namespace risk getting stuck in an infinite loop.

Table 3 shows the shadow followdotdot parameter and its values.


Table 3 shadow followdotdot parameter

Facility
shadow

Parameter
followdotdot

Value
0 (default) or 1

Comment/Description
Enables or disables symbolic link following within the current share when target path includes the .. component. 0 disables symbolic link following. 1 enables symbolic link following.

12 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Use this procedure to let Windows clients traverse symbolic links with the .. component in the target pathnames. Table 3 provides a description of the parameter.
Action
To enable Windows clients to traverse symbolic links with the .. component in the target pathnames, using the server_param command. $ server_param <movername> -facility <facility> -modify <param_name> -value <new_value> Where: <movername> = name of the specified Data Mover <facility_name> = name of the facility to which the parameter belongs <param_name> = name of the parameter <new_value> = value you want to set for the specified parameter Example: $ server_param server_2 -facility shadow -modify followdotdot value 1

Output
server_2 : done

Enabling symbolic links with absolute paths


By default, Windows clients cannot follow symbolic links that contain absolute paths (full pathnames). If you alter the shadow followabsolutpath parameter, you can enable the following of symbolic links that contain full pathnames. Table 4 shows the shadow followabsolutpath parameter and its values.
Table 4 shadow followabsolutpath parameter

Module
shadow

Parameter
followabsolutpath

Value
0 (default) or 1

Comment/Description
Enables or disables symbolic link following when the target is an absolute path. 0 disables the following of absolute paths. 1 enables the following of absolute paths.

Managing Celerra for a Multiprotocol Environment

Version 5.5

13 of 86

Use this procedure to let Windows clients follow symbolic links when the target is an absolute path.
Action
Use the server_param command to enable Windows clients to follow symbolic links when the target is an absolute path. $ server_param <movername> -facility <facility> -modify <param_name> -value <new_value> Where: <movername> = name of the specified Data Mover <facility_name> = name of the facility to which the parameter belongs <param_name> = name of the parameter <new_value> = value you want to set for the specified parameter Example: $ server_param server_2 -facility shadow -modify followabsolutpath -value 1

Output
server_2 : done

File system linking


By using symbolic links, CIFS clients can access multiple file systems on a Data Mover from a single share. This gives the appearance of one large namespace when it actually consists of individual file systems linked together with a symbolic link. After enabling the shadow followabsolutpath parameter, you can create a single CIFS share that provides access to multiple file systems on a Data Mover. "Enabling symbolic links with absolute paths" on page 13 provides more information. To link file systems together using a symbolic link, follow these steps: 1. Enable the shadow followabsolutpath. By default, this parameter is not enabled on the Data Mover. "Changing the default symbolic link behavior" on page 12 provides more information. 2. Mount the file systems. 3. Create a share to the top-level file system (the one with the symbolic links). 4. Mount the top-level file system on an NFS client. 5. At the directory where the link will be accessed, create a symbolic link to the file system.
Note: You can perform the following steps only using the Control Station and an NFS client.

14 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Example

This example shows the steps required to mount two file systems, create a share to the top-level file system, and then link the second file system to the share using a symbolic link. 1. Set the shadow followabsolutpath parameter to 1 (enable). 2. Mount the two file systems, ufs1 and ufs2:
$ server_mount server_2 server_2 : root_fs_2 on / uxfs,perm,rw root_fs_common on /.etc_common uxfs,perm,ro ufs1 on /ufs1 uxfs,perm,rw ufs2 on /ufs2 uxfs,perm,rw

3. Create a share to ufs1 (top-level file system):


$ server_export server_2 server_2 : export "/ufs1" anon=0 export "/" anon=0 access=192.168.1.100:192.168.2.100:192.168.1.101:192.168.2.101 share "ufs1" "/ufs1" netbios=NS700-JB1 maxusr=4294967295 umask=22

4. Mount the top-level file system, ufs1, on an NFS client:


# mount 192.168.101.238:/ufs1 /ufs1 # mount 192.168.101.238:/ufs1 on /ufs1 type nfs (rw,addr=192.168.101.238)

5. The symbolic link follows the absolute path in regards to the Data Mover. This path is an absolute path relative to the root file system on the Data Mover.
Note: You must have root privileges to create a symbolic link.

At the directory where the link will be accessed (in this example, /ufs1), create a symbolic link to the second file system, ufs2:
# ln -s /ufs2 fslink2 # ls -l total 8 lrwxrwxrwx 1 root drwxr-xr-x 2 root

root root

5 Jun 10 8192 Jun

2004 fslink2 -> /ufs2 9 12:14 lost+found

Note: Checkpoints of a linked file system do not appear under the top-level file system (in this example, usf1). You must be in the linked file systems own directory to view these checkpoints.

In the previous step, the command ln -s /ufs2 fslink2 links fslink2 to the path /ufs2 as it applies to the Data Mover. The CIFS clients accessing the ufs1 share can view fslink2 as one of its directories, as shown Figure 1 on page 16.

Managing Celerra for a Multiprotocol Environment

Version 5.5

15 of 86

Figure 1 Symbolic Link Example

Accessing symbolic links through NFS clients


NFS clients cannot access the fslink2 link because they have no knowledge of its path on the Data Mover, as the following shows:
# ls -l total 8 LRWXRWXRWX 1 root root 5 Jun 10 13:20 fslink2 -> /ufs2 drwxr-xr-x 2 root root 8192 Jun 9 12:14 lost+found # cd fslink2 bash: cd: fslink2: No such file or directory

For NFS clients to access symbolic links, you must perform the additional steps of exporting the file system, creating and mounting the directory, and then mounting the file system to that directory. Example The following example shows the steps required to export /ufs2 on the Data Mover, create and mount the /ufs2 directory on the NFS client, and then mount ufs2 to that directory. 1. Export the file system on the Data Mover:
# server_export server_2 -o anon=0 /ufs2 server_2 : done

2. Create the directory and mount the file system on the NFS client:
# mkdir /ufs2 # mount 192.168.101.238:/ufs2 /ufs2 # cd /ufs1 # ls -l total 8 lrwxrwxrwx 1 root root drwxr-xr-x 2 root root

5 Jun 10 13:20 fslink2 -> /ufs2 8192 Jun 9 12:14 lost+found

3. After the directory /ufs2 is created on the NFS client and the file system is mounted to it, the client can follow the symbolic link:
# cd fslink2 # ls -l total 32 drwxr-xr-x -rw-r--r--

2 root 1 32769

root 32771

8192 Jun 9 12:15 lost+found 24064 Jun 10 09:52 test1.doc

16 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

File Linking Limitations

When a user follows a link from the top-level file system to a subordinate file system, the access-checking policy on the top-level file system is applied to the subordinate file system. The file system size of the top-level file system (from where the user is connecting) does not reflect the size of the subordinate file systems. Quotas are always reported per file system. If there are users/groups/trees on subordinate file systems, each file system is reported individually. If notification requests are set on the top-level file system with the WatchTree bit, changes to subordinate file systems will not trigger notification. Some requests return the full pathname of open files. If an open file is on a file system accessed through a symbolic link, the path returned may not be the path expected. When traversing file systems through symbolic links, the command cd .. may not return the directory containing the symbolic link (from Microsoft Explorer, this is not an issue). Always restore symbolic links first; otherwise, the entire restore is done to the top-level file system. If a subordinate file system is not mounted on a Data Mover, the symbolic link appears as a directory to CIFS clients. This directory is the root file system of the Data Mover.

Managing Celerra for a Multiprotocol Environment

Version 5.5

17 of 86

Setting security on file system objects


This section explains the UNIX and Windows security models and how the Celerra Network Server uses its security policies to manage access control in a multiprotocol environment.

UNIX security model


UNIX access rights are referred to as the mode bits of a file system object. They are represented by a bit string in which each bit represents an access mode or privilege granted to the user owning the file, group associated with the file system object, and all other users. UNIX mode bits are represented as three sets of concatenated rwx (read, write, execute) triplets for each category of users (user/group/other), as shown in the following file system directory:
lrwxrwxrwx 1 kcb -rw-r--r-- 1 kcb drwxr-xr-x 2 kcb
User Other
CNS-000537

eng eng eng

10 Dec 9 1862 Jan 2 5096 Mar 9

13:42 14:32 11:30

xyz.doc -> xyz.html abc.html schedule

Group

In the previous example:

The first character of each line indicates the file type, which can be a d for a directory, l for a symbolic link, or a dash (-) for a regular file. The next nine characters of each line are the read/write/execute permission sets for user/group/other. kcb is the user and eng is the group. xyz.doc is a symbolic link that anyone can traverse to retrieve the xyz.html file. abc.html is a regular file that anyone can read but only the user kcb can write to it. schedule is a directory that anyone can search and read but only user kcb can insert files into it and delete files from it.

18 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Windows security model


By providing a variety of access permissions and an Allow or Deny option, the Windows security model has a richer and more flexible security structure than the UNIX model, as shown in Figure 2.

Figure 2 Example of Windows access permissions

Access to a file system object is allowed or denied through the use of a security descriptor (SD). An SD contains the following information:

Objects owner: creator of the file system object who has privileges to change permissions on that object. This is the Owner SID and the Primary Group SID. Access control list (ACL): includes the object owner information, DACL (discretionary ACL) describing the access permissions, and SACL (system ACL) describing the audit information criteria. For the DACL, each access right is defined in the access control entry (ACE), which explicitly allows or denies specific actions against a file system object. Each specified user and group account has an ACE in the ACL representing the privileges granted or denied. The Celerra Network Server supports ACLs at the share, directory, and file level.

Managing Celerra for a Multiprotocol Environment

Version 5.5

19 of 86

User credentials and access checking


A Windows user credential is built and cached when a user first connects to a Celerra Network Server. The credential contains the user security ID (SID) and all the SIDs of the groups in which the user is a member. When using regular UNIX authentication (AUTH_SYS), a UNIX user credential is sent along the Remote Procedure Calling (RPC) protocol request and consists of a user ID (UID) and up to 16 group IDs (GIDs) to which the user belongs. In a Secure NFS environment the UNIX user credential is built during the Kerberos authentication, and consists of the user's UID and GIDs of all the groups in which the user is a member. When a user requests access to a file system object, the Celerra Network Server compares the users credentials with the permissions on that file system object.
Note: For an FTP user providing a domain/username, the Celerra Network Server contacts the domain controller for verification, and then builds a Windows credential. For an FTP user providing an unqualified username, the Celerra Network Server builds a UNIX-style credential based on the information in the local passwd and group files, NIS, or iPlanet.

Celerra access-checking policies


In a multiprotocol environment, the Celerra Network Server must decide which set of permission attributes on a file or directory to use when determining whether to grant a user access to a file system object. This process is called user authorization and is controlled through the file system access-checking policy. When mounting a file system with the server_mount command, you can specify one of the Celerra access-checking policies explained in Table 5 on page 21.
Note: By default, when a file system is first created using the Control Station, there is no ACL on the root of that file system. The UNIX owner is root and is the only one with write access to this file system. The Celerra system automatically sets the ACL permissions as FULL CONTROL for EVERYONE on the root directory of the file systems CIFS share only after the first connection is made to this share.

Access-checking policies only apply when the Data Movers user authentication is set to the recommended default, NT. This is set using the -add security option in the server_cifs command.

20 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Table 5

Celerra access-checking policies

Access-checking policy
NATIVE (default)

Description
Access to a file or directory through NFS/FTP is granted only if the UNIX permissions on the file or directory allow it. Access through CIFS is granted only if the Windows permissions on the file or directory allow it. Both ACL and UNIX permissions are maintained for every file and directory. A change in permissions on a file system object in NFS has no impact on permissions in CIFS and a change in permissions on a file system object in CIFS has no impact on permissions in NFS. Access to a file or directory through NFS/FTP is granted only if both the UNIX and Windows permissions allow it. Access through CIFS is granted only if the Windows permissions allow it (the UNIX permissions do not have any effect). Both ACL and UNIX permissions are maintained for every file and directory. A change in permissions on a file system object in NFS has no impact on permissions in CIFS and a change in permissions on a file system object in CIFS has no impact on permissions in NFS. Access to a file or directory through NFS/FTP is granted only if the UNIX permissions allow it (the Windows permissions do not have any effect). Access through CIFS is granted only if both the UNIX and Windows permissions on the file or directory allow it. Both ACL and UNIX permissions are maintained for every file and directory. A change in permissions on a file system object in NFS has no impact on permissions in CIFS and a change in permissions on a file system object in CIFS has no impact on permissions in NFS. Offers the most control, which provides the greatest security across both CIFS and NFS. Access to a file or directory through either NFS/FTP or CIFS is granted only if both the UNIX and Windows permissions on the file or directory allow it. Both ACL and UNIX permissions are maintained for every file and directory. A change in permissions on a file system object in NFS has no impact on permissions in CIFS and a change in permissions on a file system object in CIFS has no impact on permissions in NFS.

NT

UNIX

SECURE

Managing Celerra for a Multiprotocol Environment

Version 5.5

21 of 86

Table 5

Celerra access-checking policies (continued)

Access-checking policy
MIXED

Description
Access to a file or directory through either NFS/FTP or CIFS is always determined by the ACL. Both ACL and UNIX permissions are maintained for every file and directory. ACLs for files and directories are created from the protocol that last set or changed the permissions. For example, if an NFS client sets or changes permissions on a file/directory, the ACL is rebuilt based on the UNIX mode bits. If a CIFS client sets or changes permissions on a file/directory, the ACL is built based on the standard Windows permissions. In all cases, the ACL determines file and directory access regardless of whether the client is using the NFS or CIFS protocol. ACL permissions are more granular than UNIX mode bits, consequently not all permissions set in an ACL can be translated to UNIX mode bits. In some cases, the mode bits may show more permissions than a user actually has. See "Using MIXED and MIXED_COMPAT" on page 25 for a detailed description. Access to a file or directory through NFS/FTP or CIFS is determined by which protocol (NFS or CIFS) last set or modified the permissions. Both ACL and UNIX permissions are maintained for every file and directory. If the permissions of a file or directory are set or changed from a CIFS client, then access is determined by the ACL (EXPLICIT ACL). UNIX mode bits are generated based on the ACL but are not used for access checking. If the permissions of a file or directory are set or changed from a UNIX client, then UNIX mode bits dictate access. An ACL is still created but is not used for access checking. ACL permissions are more granular than UNIX mode bits, consequently not all permissions set in an ACL can be translated to UNIX mode bits. In some cases, the mode bits may show more permissions than a user actually has. See "Using MIXED and MIXED_COMPAT" on page 25 for more information.

MIXED_COMPAT

Note: Do not establish a DFS root on a file system object with an access-checking policy of UNIX or SECURE since none of the DFS link components are created with UNIX rights.

22 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Selecting an access-checking policy


Figure 3 helps you decide which access-checking policy is best for your environment.
Start

No

Multiprotocol file system?

Yes

Automatic synchronization of Windows and UNIX permissions required or NFSv4?


No

Yes

No

Is cross protocol security required?

Yes

UNIX NATIVE UNIX

Windows Predominant operating system?

NT

MIXED Or MIXED_COMPAT

Equally Windows and UNIX SECURE


CNS-000542

Figure 3 Decision tree for access-checking policies

Note: Automatic synchronization refers to the translation of UNIX mode bits into ACLs when setting permissions from an NFS client, and conversely means the translation of ACLs into UNIX mode bits on file system objects when setting permissions from a CIFS client. "Automatic synchronization" on page 25 explains how this occurs in the Celerra Network Server.

Managing Celerra for a Multiprotocol Environment

Version 5.5

23 of 86

Table 6 shows how the Celerra access policies interact with the CIFS and NFS clients to check for permissions on a file system object in a multiprotocol environment.
Table 6 Checking permissions in a multiprotocol environment

Accesschecking policy
NATIVE (default) UNIX

Permission attributes

CIFS clients
ACL is checked.

NFS clients

UNIX rights are checked. Two permission attributes: ACL and UNIX mode bits. ACL and UNIX rights are checked. ACL is checked. ACL and UNIX rights are checked. Because of automatic synchronization, one set of permission attributes is used regardless of the protocol. ACL and UNIX rights are checked.

NT SECURE

MIXED

ACL is checked. If there is not an ACL, one is created based on the UNIX mode bits. Access is also determined by the ACL. NFSv4 clients can manage the ACL. An ACL modification rebuilds the UNIX mode bits but the UNIX rights are not checked. A modification to the UNIX mode bits rebuilds the ACL permissions but the UNIX rights are not checked. If the permissions of a file or directory were last set or changed by an NFS client, the UNIX rights are checked and the ACL is rebuilt but is not checked. If the permissions of a file or directory were last set or changed by a CIFS client, the ACL is checked and the UNIX rights are rebuilt but are not checked. NFSv4 clients can manage the ACL.

MIXED_COMPAT

Because of automatic synchronization, one set of permission attributes is used regardless of the protocol.

If the permissions of a file or directory were last set or changed by a CIFS client, the ACL is checked and the UNIX rights are rebuilt but are not checked. If the permissions of a file or directory were last set or changed by an NFS client, the UNIX rights are checked and the ACL is rebuilt but is not checked. NFSv4 clients can manage the ACL.

Note: When accessed from a Windows client, ACLs are only checked if the CIFS user authentication method is set to the recommended default, NT. This is set using the -add security option in the server_cifs command.

You can force all access requests to be checked against only UNIX permissions by modifying the cifs acl.checkacl parameter. Refer to "Using only UNIX permissions for access checking" on page 41 for more information.

24 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Using MIXED and MIXED_COMPAT


UNIX and Windows handle access control in very different ways, making it difficult to set the same security on a file system object in a multiprotocol environment. Celerras MIXED and MIXED_COMPAT policy synchronizes UNIX and Windows permissions as closely as possible by using an algorithm that translates UNIX rights into ACL entries and ACL entries into UNIX rights. The MIXED and MIXED_COMPAT polices differ in the way they translate a UNIX Group into an ACE and how they perform access checking. The MIXED policy always performs access checking against an ACL independent of the protocol accessing a file system object, as explained in the following example. The MIXED_COMPAT policy uses the permissions from the protocol that last set or changed the permissions on a file system object. MIXED example FileX is assigned the mode bits of rwxrw-r-. If the ACL of FileX is modified in such a way that user1, who is not the owner of the file, is granted read, write, and execute access to the file, the ACL shows the file owner has read, write, and execute access to the FileX. Members of the owner-group have read and write access, others have read access, and user1 has read, write, and execute access. However, the UNIX mode bits show rwxr-xrwx, meaning that at least one user who is not the file owner has read, write, and execute access. Although it seems that all others have full access to FileX, only user1 has full access since the ACL is the one controlling access, not the UNIX mode bits.

Automatic synchronization
When the MIXED and MIXED_COMPAT policies are enabled for a file system object, the ACL and UNIX mode bits are automatically synchronized. Changes to an ACL result in modifications to the mode bits and changes to the mode bits reconstruct the ACL. Table 7 explains how the MIXED access-checking policy translates ACLs and UNIX mode bits during synchronization.
Table 7 MIXED access-checking policy

Translating UNIX mode bits into ACLs


Creates ACL entries for File Owner, Group, and Everyone based on the mode bits of Owner, Group, and Other. Sets Delete/Change permissions and Take Ownership for the Owner but not for Everyone and other Groups.

Translating ACLs into UNIX mode bits


Translates the ACL Allow option but not the ACL Deny option.

Builds Owner mode bits from the Owner entry, the ACE of the file/directory, and the Everyone Group ACE.

Managing Celerra for a Multiprotocol Environment

Version 5.5

25 of 86

Table 8 explains how the MIXED_COMPAT access-checking policy translates Windows ACLs and UNIX mode bits during automatic synchronization.
Table 8 MIXED_COMPAT access-checking policy

Translating UNIX mode bits into ACLs


Creates only two entries in the ACL: Owner and Everyone. Creates a Group ACE from the Group mode bits since other groups are not translated with this policy. Ignores Other mode bits and does not use them to build the ACL. Sets Delete/Change permissions and Take Ownership for the File Owner but not for the Everyone Group.

Translating ACLs into UNIX mode bits


Translates the ACL Allow option but not the ACL Deny option. Builds None, Owner, and Granted ACEs into Group and Other mode bits.

Mapping ACL permissions to UNIX mode bits


Table 9 shows how the MIXED and MIXED_COMPAT access policies map the ACL file and directory permissions into UNIX file and directory rights.
Note: For MIXED and MIXED_COMPAT, make sure the Windows user default group is set because the Celerra Network Server uses this group to decide which UNIX primary group to assign to a file system object created through CIFS.
Table 9 Translating ACL file and directory permissions into UNIX rights

File permissions R
Traverse Folder/Execute File Read Data Read Attributes Read Extended Attributes Write Data Append Data Write Attributes Write Extended Attributes Delete X X X X X X X X

Directory permissions R W X
X

X
X

X X

X X X

26 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Table 9

Translating ACL file and directory permissions into UNIX rights (continued)

File permissions R
Read Permissions List Folders Create Files Create Folders Delete Subfolders and Files X

Directory permissions R W X

X X X X

Note: When Celerra is used as an NFSv4 server, some NFSv4 clients may place a plus sign in the ls -l output when the file system object has an ACL. Example: rwxrw-r +

Mapping UNIX mode bits to ACL permissions


Table 10 shows how the MIXED and MIXED_COMPAT access-checking policies map UNIX mode bits into ACL permissions.
Table 10 Translating UNIX rights into an ACL

R
Traverse Folder/Execute File List Folder Read Data Read Attributes Read Extended Attributes Create Files/Write Data Create Folders/Append Data Write Attributes Write Extended Attributes Delete Subfolders and Files Delete* Read Permissions Change Permissions* X X X X X

X
X X

X X X X X

Managing Celerra for a Multiprotocol Environment

Version 5.5

27 of 86

Table 10 Translating UNIX rights into an ACL (continued)

R
Take Ownership*

*Always set for Owner; never set for Everyone.

Inheritance rules
Table 11 explains the inheritance rules for the NATIVE, UNIX, NT, and SECURE access-checking policies.
Table 11 NATIVE, UNIX, NT, and SECURE inheritance rules

Protocol
CIFS

Rules
When a CIFS client creates a file system object: The ACL is inherited from the parent directory (if there is one). The UNIX permissions are determined by the umask set on the share. The shares umask is set through the umask option of the server_export command. When an NFS client creates a file system object: The ACL is inherited from the parent directory (if there is one). The UNIX permissions are determined by the users umask. Note: NFS clients may set the mode bits and/or ACL at file/directory creation time, overriding inheritance and umask.

NFS

Note: The umask value is specified in octal and is XORed with the permissions of 644 for files and 755 for directories. Common values include 002, which gives complete access to the user/owner and group and read (and directory search) access to others, or 022 (default), which gives full access to the user/owner, and read (and directory search), but not write permissions to the group and others. To change the default umask value, use the parameter share.default.umask.

28 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Table 12 explains the inheritance rules for the MIXED and MIXED_COMPAT access-checking policies.
Table 12 MIXED and MIXED_COMPAT inheritance rules

Protocol
CIFS

Rules
When a CIFS client creates a file system object, if the inheritance flag is set and the objects parent has an ACL, the file system object will inherit the ACL, and the UNIX mode bit permissions are created based on the ACL translation. If the parent does not have an ACL, the UNIX permissions are set according to the umask value* and an ACL is generated based on these values. UNIX mode bits are based on the umask value.* An ACL is created from the UNIX mode bits. Note: NFS clients may set the mode bits and/or ACL at file/directory creation time, overriding inheritance and umask.

NFS

*The umask value is specified in octal and is XORed with the default permissions of 644 for files and 755 for directories.

Backing up and restoring file system objects


File system backup tools save and restore the ACL and UNIX rights and their attributes. For NDMP (Network Data Management Protocol) and CIFS network backups, only the ACL permissions are backed up and restored and determine the UNIX rights. For an NFS backup, only the UNIX rights are backed up and restored and determine the ACL permissions. As a result, the most complex ACEs in the ACLs may be lost during an NFS backup. Recommendation Use NDMP to back up and restore multiprotocol file systems since network backups through NFS or CIFS capture only one set of metadata on a multiprotocol file system.

Managing Celerra for a Multiprotocol Environment

Version 5.5

29 of 86

Setting the access-checking policy


Use this command to set the access-checking policy for a file system object.
Note: Always verify the file systems current access-checking policy before executing this command.

If remounting a file system with MIXED or MIXED_COMPAT that currently has an access-checking policy of NATIVE, NT, UNIX or SECURE, proceed to the procedure, "Migrating to MIXED and MIXED_COMPAT" on page 31, upon completing this command.
Action
To set the access-checking policy for a file system, use this command syntax: $ server_mount <movername> -o accesspolicy=NT|UNIX|SECURE|NATIVE|MIXED|MIXED_COMPAT <fs_name> <mount_point> Where: <movername> = name of the specified Data Mover or VDM <fs_name> = name of the file system being mounted <mount_point> = name of the mount point A <mount_point> must begin with a forward slash (/). Example: To set the access-checking policy to NT for file system ufs1 on server_2, type: $ server_mount server_2 -o accesspolicy=NT ufs1 /ufs1

Output
server_2: done

30 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Migrating to MIXED and MIXED_COMPAT


With the NATIVE, NT, UNIX and SECURE access policies, the Celerra Network Server can store both UNIX and Windows permissions for each file and directory in a file system. Under these policies, a change in one set of permissions has no impact on the other set. As a result, it is unlikely that the Windows and UNIX permissions are consistent with one another. When you remount a file system with MIXED or MIXED_COMPAT with an original access-checking policy of NATIVE, NT, UNIX or SECURE, its existing files and directories may still have permissions that are not synchronized. The nas_fs -translate command enables you to synchronize the UNIX and Windows permissions on each file and directory in the file system, as explained in "Mapping ACL permissions to UNIX mode bits" on page 26 and "Mapping UNIX mode bits to ACL permissions" on page 27.

CAUTION

Migrating to MIXED or MIXED_COMPAT may change the existing rights on some file system objects. Only perform the translation function if your multiprotocol environment requires the automatic synchronization of UNIX mode bits and ACL entries, or if you are using NFSv4 for data access.

Table 13 explains how Windows and UNIX permissions are translated to MIXED or MIXED_COMPAT using either NT, UNIX, NATIVE, or SECURE as the originating policy. The originating policy instructs Celerra from which set of permission attributes (ACL or mode bits) to derive the permissions when migrating to MIXED or MIXED_COMPAT. It does not necessarily relate to the policy previously used by the file system object. You specify the originating policy in the -from option of the nas_fs -translate command. For example, if you enter UNIX in the -from option, all ACLs are regenerated from the mode bits.
Table 13 Migrating to MIXED or MIXED_COMPAT

Originating policy NATIVE and NT

Synchronization action
If a file system object has an ACL, UNIX rights are derived from the ACL as shown in Table 9 on page 26. If an object does not have an ACL, the ACL is generated from the mode bits, which remain the same. All the ACLs are rebuilt based on the mode bits. Access control is unchanged for UNIX users. Because the UNIX security model is not as flexible as the Windows security model, some ACL information may be lost during migration. Both ACL and mode bits are checked and stored. Mode bits are merged into the ACL by adding the three ACEs: OWNER, GROUP and OTHER, if they do not exist. If any of these ACEs exist, they are merged with the corresponding UNIX rights.

UNIX

SECURE

Managing Celerra for a Multiprotocol Environment

Version 5.5

31 of 86

Performing the synchronization

CAUTION

Since you cannot undo this procedure, first perform a backup of the file system. Always verify the access-checking policy set on the file system before and after executing the translate command.

After remounting a file system object to MIXED or MIXED_COMPAT, use this command to synchronize the UNIX and Windows permissions on a file system. You can migrate:

from NT, NATIVE, UNIX, or SECURE to MIXED or MIXED_COMPAT from MIXED to MIXED_COMPAT from MIXED_COMPAT to MIXED
Action
To synchronize the UNIX and Windows permissions on a file system, use this command syntax: $ nas_fs -translate <fs_name> -access_policy start -to {MIXED} -from {NT|NATIVE|UNIX|SECURE} Where: <fs_name> = name of the file system Note: The access-checking policy entered in the -from option tells Celerra which permissions (UNIX or Windows) to use as the master policy during the translation, as explained in Table 13 on page 31. Example: To synchronize the UNIX and Windows permissions for ufs1 on server_2 and regenerate ACLs based on UNIX mode bits, type: $ nas_fs -translate ufs1 /ufs1 access_policy start -to MIXED -from UNIX

Output
server_2: done

Notes
You must mount the file system as MIXED or MIXED_COMPAT before executing this command. If not, the command is refused. The file system to be translated must be a UXFS file system object mounted as read/ write.

32 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Checking the translation status


Use this command to verify if the file system was translated successfully.
Action
To check the translation status of a file system, use this command syntax: $ nas_fs -translate <fs_name> -access_policy status Where: <movername> = name of the specified Data Mover or VDM <fs_name> = name of the file system being translated Example: To check the translation status for ufs1, type, type: $ nas_fs -translate ufs1 -a status

Output
status=In progress percent_inode_scanned=68 1097154093: ADMIN: 4: Command succeeded: acl database=/ufs1 convertAccessPolicy status

Notes
If the translation failed, check if the file system is mounted as MIXED or MIXED_COMPAT. If the translation does not complete due to system failure, reissue the command.

Resetting MIXED and MIXED_COMPAT


You can reset the MIXED or MIXED_COMPAT access-checking policy of a file system object to NT, NATIVE, UNIX or SECURE by remounting it with the desired access-checking policy. Nothing changes in the ACL permissions or the UNIX mode bits except that the new access right policy is applied and the ACLs and mode bits become independent when first modified. Use this command to reset the MIXED or MIXED_COMPAT access-checking policy.
Action
To reset the access-checking policy for a file system, use this command syntax: $ server_mount <movername> -o accesspolicy=NT|UNIX|SECURE|NATIVE|MIXED|MIXED_COMPAT <fs_name> <mount_point> Where: <movername> = name of the specified Data Mover or VDM <fs_name> = name of the file system being mounted <mount_point> = name of the mount point, which begins with a forward slash (/) Example: To reset the access-checking policy to UNIX for file system ufs1 on server_2, type: $ server_mount server_2 -o accesspolicy=UNIX ufs1 /ufs1

Output
server_2: done

Managing Celerra for a Multiprotocol Environment

Version 5.5

33 of 86

Creating a Windows-style credential for UNIX users


In a multiprotocol environment, Celerra users should have the same identity in both UNIX and Windows. The Windows NT credential feature enables the Celerra Network Server to take full account of a users Windows group memberships when checking an ACL for access through NFS. When a UNIX user initiates a request for a file system object, the Celerra Network Server maps the UNIX UID to the Windows SID, and then merges the users UNIX and Windows groups together to generate a Windows NT credential. The Windows NT credential closely resembles a Windows credential except that it does not contain local groups since a UNIX user cannot retrieve these groups from the local computer. After the Windows NT credential is generated, it replaces the UNIX credential for NFS access checking. The Windows NT credential provides the following:

Consistent permissions on a file system object independent of the protocol accessing it. Cache to store Windows NT credentials, decreasing the access-checking processing time. Management of UNIX access rights through an ACL. Elimination of the UNIX credentials 16-group limit per user imposed by NFS versions 2 and 3.

Recommendation

Use the Windows NT credential feature in a multiprotocol environment because it takes full account of a users Windows group memberships when checking an ACL through NFS.

34 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Processing a Windows NT credential


Figure 4 illustrates how the Celerra Network Server generates a Windows NT credential after a UNIX client requests access to a file system object.

Is UID/GID in NT credential cache?

Yes

Has TTL time stamp expired?

No

Perform access checking

No Yes

Is there a UID/GID to SID match? Yes No

Create NT credential

Insert new NT credential into cache

Search for name associated with UID

Able to retrieve SID from DC?

Yes

No

Insert mapping failed entry into cache


CNS-000536

Figure 4 Creating a Windows NT credential

The Celerra Network Server performs the following steps to process a Windows NT credential. 1. Checks if the UNIX user ID is in the Windows NT credential cache: If the user ID is not in the cache, goes to step 2. If the user ID is in the cache, checks the Windows NT credentials time-tolive (TTL) expiration stamp. If this has expired, goes to step 2; if not, goes to step 7. 2. Tries to map the user ID to a Windows SID.

Managing Celerra for a Multiprotocol Environment

Version 5.5

35 of 86

3. If a match is not found: Searches for a name associated with the UID. Using this name, retrieves the SID from its domain controller using the default Windows domain in the nfs NTcred.winDomain parameter or the domain extension retrieved from NIS or the local passwrd file on the Data Mover. If no SID is found, inserts a mapping failed entry into the cache. In this case, the UNIX credential sent in the NFS request is used for access checking. This prevents the system from continually accessing the domain controller for a matching SID. 4. When a match is found, retrieves the users group list from the Domain Controller. This can be the Data Movers domain or a trusted domain. 5. Replaces UNIX credential with a new Windows NT credential. 6. Inserts Windows NT credential into cache for access-checking by UNIX clients. 7. Performs access checking.

Accessing a trusted domain using Windows 2000


For Windows 2000, access to a trusted domain requires that you set additional rights for the CIFS server retrieving the list of groups in which a user belongs. You must grant this server the List contents and Read all properties rights. To do this: 1. Use the Microsoft AD User and Computer MMC in expert mode. 2. From the menu, select View > Advanced features. 3. Right-click the domain name, and select Security > Advanced. 4. Grant the rights to: For a Data Mover NetBIOS name: Everyone or Anonymous For a Data Mover computer name: serverDomain\Domain Computers

36 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Setting the Windows default domain


The Celerra Network Server uses the nfs NTcred.winDomain parameter, shown in Table 14, for its default Windows domain.
Table 14 NTcred.winDomain parameter

Facility
nfs

Parameter
NTcred.winDomain

Value
valid NetBIOS domain name

Comment/Description
Using the name associated with the UNIX UID, the system retrieves the Windows SID from the domain controller using this default domain. This is only used when several different SIDs match the UNIX UID or when the UID to SID mapping returns an ambiguous username (no domain).

Defining the Windows NT credential cache


The NTcred cache is a size-limited cache containing Windows NT credentials and any UID entries that could not be mapped to SIDs. Each entry has a time-to-live expiration stamp. You set the size of the NTcred cache using the nfs NTcred.size parameter shown in Table 15.
Note: If you stop the CIFS service, connected users can continue to use the cache for a period of 20 minutes. When you restart CIFS, all the failed mapping entries are removed from the cache.
Table 15 NTcred.size parameter

Facility
nfs

Parameter
NTcred.size

Value
Default: 1009 entries

Comment/Description
Specifies the maximum number of entries allowed in the NTcred cache.This cache is unique per Data Mover. The oldest, unused entry is removed first.

You set the time-to-live expiration stamp of the Windows NT credentials using the nfs NTcred.TTL parameter shown in Table 16.
Table 16 NTcred.TTL parameter

Facility
nfs

Parameter
NTcred.TTL

Value
Default: 20 minutes

Comment/Description
Specifies the life, in minutes, of a Windows NT credential in the NTcred cache. When failed mapping entries expire, the system retries to match the UID to the SID.

Managing Celerra for a Multiprotocol Environment

Version 5.5

37 of 86

Adding groups to a Windows NT credential


The UNIX credential supplied by the NFS v2 and v3 clients during the access of a file system object can contain at most 16 groups per user, which can result in the loss of access rights for a user belonging to more than 16 groups. The cifs acl.extendExtraGid parameter, shown in Table 17, allows you to merge the UNIX and Windows groups in which the user belongs into a Windows NT credential. There is no limit to the number of groups a Windows NT credential can contain.
Table 17 cifs acl.extendExtraGid parameter

Facility
cifs

Parameter
acl.extendExtraGid

Value
0 or 1 Default: 0

Comment/Description
Controls whether CIFS user credentials and NFS NT credentials include information about the UNIX groups to which the user belongs. This applies in a multiprotocol environment only. 0 = Base the user credential only on the Windows Security IDs (SIDs) for the user and the Windows groups to which the user belongs. 1 = Include in the user credential the SIDs that correspond to the UNIX groups to which the user belongs.

38 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Use the server_param command to do the following:


Set the Windows default domain. Define the Windows NT credential cache size. Set the time-to-live expiration stamp of the Windows NT credentials. Add groups to a Windows NT credential.
Action
To set the Windows default domain, define the Windows NT credential cache size, set the time-tolive expiration stamp of the Windows NT credentials, and add groups to a Windows NT credential, use this command syntax: $ server_param <movername> -facility <facility_name> -modify <param_name> -value <new_value> Where: <movername> = name of the specified Data Mover <facility_name> = name of the facility to which the parameter belongs <param_name> = name of the parameter <new_value> = value you want to set for the specified parameter Examples: To set the Windows default domain to nasdocs.emc.com, type: $ server_param server_2 -facility nfs -modify NTcred.winDomain -value nasdocs.emc.com To define the Windows NT credential cache size to 1000, type: $ server_param server_2 -facility nfs -modify NTcred.size -value 1009 To set the time-to-live expiration stamp of the Windows NT credentials to 30 minutes, type: $ server_param server_2 -facility nfs -modify NTcred.TTL -value 30 To merge the users UNIX and Windows groups together to build a Windows NT credential, type: $ server_param server_2 -facility cifs -modify acl.extendExtraGid -value 1 Note: Parameter and facility names are case-sensitive.

Output
server_2 : done

Managing Celerra for a Multiprotocol Environment

Version 5.5

39 of 86

Generating Windows NT credentials


Use this command to start creating Windows NT credentials for a file system object on a Data Mover.
Action
To start creating Windows NT credentials for a file system object, use this command syntax: $ server_mount <movername> -o accesspolicy=NT|UNIX|SECURE|NATIVE|MIXED|MIXED_COMPAT,ntcredential <fs_name> <mount_point> Where: <movername> = name of the specified Data Mover or VDM <fs_name> = name of the file system being mounted <mount_point> = name of the mount point Example: To set the access-checking policy to NT and the Windows NT credential for file system ufs1 on server_2, type: $ server_mount server_2 -o accesspolicy=NT,ntcredential ufs1 /ufs1

Output
server_2: done

Note
The Windows NT credential function is for multiprotocol file systems. Only use this feature with NT, SECURE and MIXED and MIXED_COMPAT access-checking policies.

40 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Using only UNIX permissions for access checking


You can configure the cifs acl.checkacl parameter if you want access checking to be done against UNIX permissions only. When this parameter is set to zero for a Data Mover, Windows ACLs are never used for access checking regardless of the access-checking policy set on the Data Movers file system objects.
Important: The cifs acl.checkacl parameter affects all file systems on a Data Mover.

Table 18 shows the cifs acl.checkacl parameter and its values.


Table 18 cifs acl.checkacl parameter

Facility
cifs

Parameter
acl.checkacl

Value
0 or 1 (default) Note: The default value depends on the state of the CIFS service and the user authentication method on the Data Mover.

Comment/Description
Determines if Windows ACLs are checked during file system object access checking. 0 indicates to never check Windows ACLs. 1 indicates to check Windows ACLs if required by the access-checking policy The parameter is always 0 if the CIFS service is not started (except if the parameter is manually set). When CIFS is started, this parameter is set to 1 and when CIFS is stopped, it is set to 0. The parameter is always 0 if the user authentication method on the Data Mover is set to UNIX or SHARE. However, this does not mean that UNIX files and directory permissions are checked when using SHARE user authentication. With SHARE user authentication, the read/write passwords on the share used to access the file system determine the type of user access allowed to files and directories.

Managing Celerra for a Multiprotocol Environment

Version 5.5

41 of 86

Use this command to ensure one of the following:


Windows ACLs are never checked. Windows ACLs are only checked if required by the access-checking policy set on the file system object.
Action
Use this command to ensure Windows ACLs are never checked or are checked if required by the access-checking policy: $ server_param <movername> -facility <facility_name> -modify <param_name> -value <new_value> Where: <movername> = name of the specified Data Mover <facility_name> = name of the facility to which the parameter belongs <param_name> = name of the parameter <new_value> = value you want to set for the specified parameter Example: To ensure only UNIX permissions are checked, type: $ server_param server_2 -facility cifs -modify acl.checkacl -value 0 Note: Parameter and facility names are case-sensitive.

Output
server_2 : done

42 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Setting the file locking policy


File locking provides a mechanism for ensuring file integrity when more than one user tries to access the same file. File locks manage attempts to read, write, or lock a file in use by another user. Both the NFS and CIFS protocols implement file locking features in different ways. Table 19 lists some of the differences between NFS and CIFS file locking.
Table 19 Differences between NFS and CIFS locks

Locks in an NFS environment


Uses read locks and exclusive (write) locks.

Locks in a CIFS environment


Uses opportunistic locks (oplocks) and deny modes. The CIFS protocol enforces strict file locking, as well as unlocked access to files. CIFS locks are mandatory. When a CIFS process locks a file, other users are denied certain types of access to the file, depending on the type of lock imposed. A CIFS client can lock a file using: A deny read/write access on the whole file. A lock range on a portion of the file.

NFS locks are advisory but not mandatory. An advisory lock is not an enforced lock (and therefore, does not affect read and write access to the file) but it advises other clients that the file is already in use. In addition, NFS locks are cooperative. A client can access a file locked by another client if it ignores or does not check for locks granted to another client.

In a multiprotocol environment, a file may have locks set by both CIFS and NFS users. Because NFS locks and CIFS deny modes and oplocks are not directly equivalent, the Celerra Network Server must translate CIFS deny modes and oplocks to NFS locks and translate NFS locks into CIFS deny modes and oplocks. For example:

A CIFS deny read/write mode request is translated into an NFS exclusive read/write lock. An NFS shared read lock is translated into a CIFS deny write mode.

Managing Celerra for a Multiprotocol Environment

Version 5.5

43 of 86

To provide some control over the interaction of CIFS and NFS file locking, the Celerra Network Server provides three different locking policies that you can specify when mounting a file system. These policies nolock, wlock, and rwlock are defined in Table 20. These policies are used for a multiprotocol environment and indicate the impact of locking behavior on NFS clients in the case of concurrent NFS and CIFS file locking.
Table 20 Celerra Network Server file locking policies

nolock1
No locks: permits all access (default setting, least secure). Lock requests: If a CIFS or NFS client locks a file, no other client can lock that file. Access requests: CIFS clients ignore locks set by NFS. NFS clients can read and write to files locked by CIFS.

wlock2
Write lock: denies write access. Lock requests: If a CIFS or NFS client locks a file, no other client can lock that file. Access requests: CIFS clients denying concurrent access for write cannot open files locked by NFS for exclusive access. NFS clients can read, but cannot write to or delete, files locked by CIFS.

rwlock2
Read/write lock: denies read/ write/execute access (most secure). Lock requests: If a CIFS or NFS client locks a file, no other client can lock that file. Access requests: CIFS clients denying concurrent access for read or write cannot open files locked by NFS for exclusive or shared access. NFS clients cannot read, write, or delete files locked by CIFS.

1. Nolock is the only lock policy supported on HighRoad file systems. 2. On NFS, applications that do not expect lock conflicts (permission denied) on read/write operations may have problems.

Important: The Celerra Network Server only enforces file locks (when configured to do so) if the client application uses locks. Some simple applications, such as Windows Notepad/ Wordpad, UNIX more, and vi do not use file locking. Files created with these applications are not locked and can be opened and edited by another application even when a file system is mounted with wlock or rwlock.

44 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Mounting the file system


When mounting a file system, you can specify the policy to control the interaction of CIFS and NFS locking. The file locking option you select depends on your business requirements and whether your network environment is CIFS only or a multiprotocol (combined CIFS and NFS) environment.
Note: The Managing Celerra Volumes and File Systems Manually technical module provides information on creating a file system and a mount point.

Use this command to set the file system locking.


Action
To specify file system locking, use this command syntax: $ server_mount <movername> -o nolock|wlock|rwlock <fs_name> <mount_point> Where: <movername> = name of the specified Data Mover or VDM <fs_name> = name of the file system being mounted <mount_point> = name of the mount point Example: To mount the file system ufs1 with a read/write lock, type: $ server_mount server_2 -o rwlock ufs1 /ufs1

Output
server_2: done

Note
A <mount_point> must begin with a forward slash (/).

Managing Celerra for a Multiprotocol Environment

Version 5.5

45 of 86

Viewing/setting UNIX permissions from a Windows client


The ability for Windows users to view and modify UNIX permissions is disabled by default. By using the cifs acl.extacl parameter, you can allow Windows users to view and set UNIX permissions on files and directories and enable special capabilities around ACL management as explained in Table 21 on page 47. Setting the cifs acl.extacl parameter causes UNIX permissions to appear in the file or directorys Windows Properties dialog box as shown in Figure 5.

Figure 5 Properties dialog box with UNIX permissions

Considerations

Because the UNIX directory permissions are not inheritable (set for This folder only), they only appear in the Advanced area. For this reason, it is best to view and edit the folder permissions using the Advanced area. When changing UNIX permissions from Windows, clearing the Allow checkbox does not clear all entries (when viewed from Advanced Settings). To clear all entries, you must select the Deny checkbox. Selecting the Allow Inheritable permissions... checkbox may cause unexpected results when changing UNIX permissions from Windows. If this checkbox is selected, UNIX permissions may take default values from parental objects.
Managing Celerra for a Multiprotocol Environment

46 of 86 Version 5.5

Configuring the cifs acl.extacl parameter


Table 21 on page 47 explains the cifs acl.extacl parameter and its values. UNIX rights do not have a Deny option and access is handled in the following ways:

If the ACE is a Allow access, the corresponding UNX rights are added. If the ACE is a Deny access, the UNIX rights that are not denied, are granted access. If both Deny and Allow are selected, two ACEs are created because an ACE does not contain both options.

Table 21 cifs acl.extacl parameter

Facility
cifs

Parameter
extacl

Value
Bit 0 (default): Celerra presents the UNIX meta-data associated with files and directories to CIFS backup clients using a special ACE entry in the file or directory's ACL. This ACE can take either of two forms. If bit 0 in the bit string is set to 0, Celerra uses an EMC ACE type (CIFS allows vendors to define their own ACE types). If bit 0 is set to 1, Celerra uses a standard ACE and encodes the information in the SID associated with that ACE. Bit 1: If this bit is set to 1, the UNIX permissions on files and directories on the Celerra can be viewed and modified by Windows clients. The UNIX permissions are presented as three additional ACEs in the ACL of each file and directory. These ACEs can be viewed and modified by any CIFS ACL management application such as Windows Explorer. Bit 2: If this bit is set to 1, Celerra presents the UNIX permissions associated with files and directories in the ACL of the files so that CIFS network backup applications can backup and restore them from and to a Celerra file system. Bit 3: If this bit is set to 1, Celerra presents UNIX symbolic links as zero byte files with a special ACL which captures the information associated with the symbolic link (e.g. its target). When this bit is not set, Celerra may follow symbolic links on behalf of CIFS clients and hence a CIFS backup application does not backup the symbolic links, but instead, the files they point to. When this bit is set, Celerra follows symbolic links on behalf of CIFS network backup clients. This means the CIFS backup application backs up the symbolic links rather than the files and directories they point to.

Comment/Description
This parameter is a bit list which enables special capabilities around ACL management. There are two kinds of capabilities: Backup/restore specific UNIX attributes like access right, UNIX mode, UNIX name and symbolic link, using a regular CIFS based backup tool (like NTbackup); View/change UNIX access rights from ACL management tool, such as Windows Explorer. The value is a bit list, and any combination of bits is allowed. The bits not described must be set to '0' Examples: To allow CIFS clients to view and modify the UNIX permissions on files and directories using Windows Explorer and leave everything else at the default settings, set bit 1. The result is a binary string of the form 0000010 which is 2 in decimal notation. param cifs acl.extacl=2. To change the way that the ACL is translated into UNIX permissions on files and directories so that the UNIX permissions applied to files and directories are the rights granted by any grant ACE for the UNIX user/ group/other less any rights explicitly denied in any deny ACE for the UNIX user/group/other, set bit 6 as well. The result is a binary string of the form 1000010 which is 66 in decimal notation. param cifs acl.extacl=66. To enable NFS v2 and v3 clients to view and modify the ACLs on files and directories using the emcsetsd tool, set bit 5 as well. The result is a binary bit string of the form 1100010 which is 98 in decimal notation. param cifs acl.extacl=98. The second and third examples build on the previous ones.

Managing Celerra for a Multiprotocol Environment

Version 5.5

47 of 86

Table 21 cifs acl.extacl parameter (continued)

Facility

Parameter

Value
Bit 4: Any file or directory on a Celerra can have up to three different names in the file system. That is, a file or directory may have a UNIX style name, a long Windows or M256 name and a DOS 8.3 style name. When a CIFS network backup client backs a file up it can obtain the long Windows and DOS 8.3 name using standard CIFS calls. If the file has a UNIX name that is different than the long Windows name it will, by default, not be backed up or restored by CIFS network backup applications. When this bit is set to 1, Celerra encodes the UNIX name of files and directories in a special ACE in the ACL of the file so that CIFS network backup applications can backup and restore all three names of files and directories. Bit 5: By default, there is no way for NFS v2 and v3 clients to view or modify the ACLs associated with files and directories on the Celerra. EMC provides a tool called "emcsetsd" on the Celerra Applications and Tools CD that comes with the Celerra software kit. This tool allows NFS v2 and v3 clients to view and, if the user has permission to do so, modify the ACLs associated with files and directories on the Celerra. This bit must be set to 1 on the Celerra before the emcsetsd client tool will work. Bit 6: This bit, when set, modifies the functionality enabled with bit 1. When this bit is not set, UNIX rights applied to the file are "granted rights + rights not denied by the DACL". If this bit is set, UNIX rights applied are "granted rights - denied rights by the DACL". Additionally if bit 6 is set, the request is rejected if one of the 3 special ACE is inheritable. This is because when changing rights on a directory, the client propagates rights down the tree to all nodes (files + directories) which is most of the time not a desired behavior. Setting this bit prevents it. In practice, this means that ACLs for directories must be set using the Advanced panel in the security properties within Windows Explorer.

Comment/Description
Continued from previous page.

48 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Use this procedure to enable special capabilities around ACL management.


Action
To allow Windows users to view and set UNIX permissions on files and directories, and enable special capabilities around ACL management, use this command syntax. $ server_param <movername> -facility <facility> -modify <param_name> -value <new_value> Where: <movername> = name of the specified Data Mover <facility_name> = name of the facility to which the parameter belongs <param_name> = name of the parameter <new_value> = value you want to set for the specified parameter Example: To enable Windows users to view and modify UNIX permissions, type: $ server_param server_2 -facility cifs -modify acl.extacl -value 1

Output
server_2 : done

Managing Celerra for a Multiprotocol Environment

Version 5.5

49 of 86

Using the Data Mover as a stand-alone DFS server


Microsofts DFS (Distributed File System) allows administrators to group shared folders located on different servers into a logical DFS namespace. A DFS namespace is a virtual view of these shared folders shown in a directory tree structure. By using DFS, administrators can select which shared folders to view in the namespace, assign names to these folders, and design the tree hierarchy in which the folders appear. Users can navigate through the namespace without needing to know the server names or the actual shared folders hosting the data. Each DFS tree structure has a root target that is the host server running the DFS service and hosting the namespace. A DFS root contains DFS links pointing to the shared folders (a share itself and any directory below it) on the network. These folders are called DFS targets.

DFS root servers


Microsoft offers two types of DFS root servers: the domain DFS root server and the stand-alone DFS root server. The domain DFS server stores the DFS hierarchy in the Active Directory. The stand-alone DFS root server stores the DFS hierarchy locally. The Celerra Network Server provides the same functionality as a Windows 2000 or Windows Server 2003 stand-alone DFS root server. For a detailed description of DFS, visit the Microsoft website at http:// www.microsoft.com.

Wide links
The Celerra Network Server wide links feature uses Microsoft DFS functionality to resolve UNIX absolute symbolic links for Windows clients. This is done by creating a DFS root on a CIFS share and then establishing a link on the DFS root that maps the UNIX mount point to the Windows server:\share\path. This mapping is done through the MMC Distributed File System (DFS) tool. "Using wide links" on page 56 provides more information.

Prerequisites
Complete the following tasks before configuring a DFS root on a CIFS share. The Configuring CIFS on Celerra technical module provides instructions on these tasks. 1. Configure the CIFS server on the Data Mover. 2. Start the CIFS service on the Data Mover, which automatically enables DFS support.

50 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

3. On the CIFS server, configure a file system share on which to create the DFS root, using Table 22 as a guideline.
Table 22 DFS environments

DFS provided with


Windows 2000: Windows Server 2003 and Windows XP machine:

Share type
Local Share Global Share You can view a DFS root on a global share from any CIFS server on the Data Mover.

Number of DFS roots


Single Multiple This is the recommended option since it can manage multiple DFS roots on the same CIFS server.

Enabling and disabling DFS support


After starting the CIFS service, DFS support is enabled by default. To disable DFS functionality, perform the following: 1. Set the following Windows Registry key to zero on the Data Mover using a tool, such as RegEdit: HKEY_LOCAL_MACHINE\SOFTWARE\EMC\DFS\Enable 2. Stop and restart the CIFS service.

Configuring and administering DFS support


To configure a DFS root on a CIFS share, you can use the Microsoft dfsutil.exe command-line tool or the MMC DFS tool. For dfsutil.exe, use the optional flag to work with the API instead of the Windows Registry.
Note: If you are planning on using a CIFS server as a stand-alone DFS server only (no domain infrastructure), you must create it with dfsutil.exe.

The Microsoft dfscmd.exe tool enables you to administer the DFS root content (for example, creating and deleting links).You cannot delete a DFS tree structure using this command.
Note: Do not establish a DFS root on a file system object with an access-checking policy of UNIX or SECURE since none of the DFS link components are created with UNIX rights.

The dfsutil.exe and dfscmd.exe tools are included with the Windows 2000 or Windows Server 2003 Support Tools.
Note: When you query DFS on the network by executing the dfsutil /siteinfo:<cifs_server_name> command that comes with Microsoft Windows 2000 support tools, the client connects to the srvsvc pipe and issues a NetrDfsManager ReportSiteInfo command. Celerra returns a DCE RPC Fault of 0x1c010002 or Range Error. To avoid this error, use the Microsoft Windows Server 2003 dfsutil /sitename:<cifs_server_name> command.

Managing Celerra for a Multiprotocol Environment

Version 5.5

51 of 86

Creating a DFS root using dfsutil.exe


The following example shows how to create a DFS root on a global share using dfsutil.exe in a Windows Server 2003 environment:
C:\>dfsutil /AddStdRoot /Server:DM2-ANA0-1-SA /Share:wl_root-1 Microsoft(R) Windows(TM) Dfs Utility Version 4.0 Copyright (C) Microsoft Corporation 1991-2001. All Rights Reserved. DfsUtil command completed successfully.

Creating a DFS root using MMC DFS


The following example procedure shows how to create a DFS root using the MMC DFS tool:
Step
1.

Action
Start the New Root Wizard tool from MMC DFS.

52 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Step
2.

Action
On the Host Server dialog box, type the CIFS server on the Data Mover to be used as the DFS root.

3.

On the Root Type dialog box, select Stand-alone root.

Managing Celerra for a Multiprotocol Environment

Version 5.5

53 of 86

Step
4.

Action
The Root Name dialog box displays the UNC path to the root and the share. Type a unique name for the DFS root and any comments you may have.

54 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Step
5.

Action
If you previously specified a root name that does not correspond to an existing share, you are asked to type the path to the share.

Upon successful completion, the New Root Wizard displays the following information.

Managing Celerra for a Multiprotocol Environment

Version 5.5

55 of 86

Using wide links


It is difficult for a Windows client to open a path to a file system object when its path contains an absolute symbolic link. A Windows client asks a server to perform a function on a file system object based on a given path. Unlike Windows, a UNIX client uses a target path relative to its mount point. This can lead to a file system object on a remote server. Example A UNIX client has the following two file systems mounted: server1:/ufs1 mounted on /first server2:/ufs2 mounted on /second On ufs1, there is an absolute symbolic directory link to /second/home. A UNIX client can easily access this link from ufs1. However, since this path exists only on the UNIX client and not on the local server, a Windows client is unable to follow this path. With the wide links feature, Windows clients are able to access files from the same directory as UNIX clients do when following an absolute symbolic link. The Celerra system does this by using the DFS root functionality of the Data Mover. Wide link translation makes it easier to build and maintain a single, multiprotocol file system namespace that spans multiple file servers as it reduces the burden associated with maintaining consistency between the NFS and CIFS namespace structure definitions (for example, NFS automount table and DFS).

Considerations
Review the following before creating wide links:

The wide links feature is based on Microsoft DFS functionality. The DFS requirements must be met, as explained in "Using the Data Mover as a standalone DFS server" on page 50, before establishing wide links. A wide links target must be on a DFS root, which is a CIFS share or a Windows share. This share can be local or on a remote server. On the root share, you can create as many wide links as required. Since DFS redirects only directories, you must set a directory pathname in the DFS link used for wide links. During the redirection of wide links, the system does the following: Finds a DFS link matching the beginning of the target path in the symbolic link. Appends the rest of this path to the DFS target for final redirection. You can configure a wide link on a per virtual Data Mover (VDM) basis. This enables you to direct a Windows client to as many different directory locations as needed. After the wide links feature is configured, a symbolic link with an absolute path appears as a directory instead of a file in Windows Explorer.

56 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

The path in the DFS link must be the same in Windows and UNIX (in other words, the UNIX name of each component must be the M256 name in Windows). Limitations of Windows NT4 clients on shares that support wide symbolic links On an NT4 client, if you right-click a file that is located in a share that supports wide links and select Properties, the Security tab is not displayed. You can set security using a security tool such as cacls. Alternatively, you can either access files from a Windows 2000 client or access files using shares that don't support wide symbolic links. You can have two different shares on the same directory, one that supports wide links and one that does not, and use the share that does not support wide links when setting security. If a Windows client is connected to CIFS share on a DFS root and this share is removed from DFS, the client may not be able to access it. Since the wide links feature is based on Microsoft DFS, this can also happen with wide links. This behavior occurs because the clients use a DFS cache to track all DFS links. Until the shares cache entry times out, the Windows clients attempt to access the deleted share even though it no longer exists in DFS. To resolve this, do one of the following: Wait for the DFS cache entry to time out. Disconnect the client from the share, clear the clients DFS cache using the Microsoft command line tool dfsutil/pktflush, and reconnect to the share.

Processing steps
The following steps outline how a Windows client processes the wide links feature using DFS: 1. Client asks to open a path that has an absolute symbolic link. 2. Server detects an absolute link path and sends an error stating this path is not covered. This is typical DFS behavior. 3. Client requests DFS referrals of this path to determine where to connect to next. 4. From the Windows Registry, the CIFS server determines which CIFS share to use for wide-links resolution by finding a link matching the beginning of the target path in the symbolic link. 5. CIFS server sends DFS referrals pointing the client to the new path to use.

Establishing wide links


In the following example, the w1_root-1 file system contains the user1 directory that has the following symbolic links:

link to fs_wslink-1\user1 on the local Data Mover link to fs_wlink-29\user1 on a remote Data Mover

Managing Celerra for a Multiprotocol Environment

Version 5.5

57 of 86

Example
w1_root-1 file system exists on server_2:
$ server_export server_2 | grep -w "wl_root-1" export "/wl_root-1" share "wl_root-1" "/wl_root-1" maxusr=4294967295 umask=22

user1 directory is located in w1_root-1:


[user1@LINUX1PAG01 user1]$ pwd /wl_root-1/user1

user1 has two UNIX symbolic links to other directories on separate Data Movers:
[user1@LINUX1PAG01 user1]$ ls -lhat total 8.0K drwxr-xr-x 3 root root 0 Feb 2 drwxr-xr-x 3 user1 group-1001 1.0K Feb -rw-r--r-1 user1 group-1001 0 Feb lrwxrwxrwx 1 user1 group-1001 15 Feb user1_on_fs_wlink-29 -> /wlink-29/user1 lrwxrwxrwx 1 user1 group-1001 14 Feb user1_on_fs_wlink-1 -> /wlink-1/user1 drwxr-xr-x 2 user1 group-1001 80 Feb

13:19 .. 2 12:43 . 2 12:43 NFS_user_file 2 12:25 2 12:25 1 17:49 user1

These symbolic links point to the following:

user1 on fs_wlink-1 on the local Data Mover (server_2):

[user1@LINUX1PAG01 user1]$ mount | grep wlink-1 automount(pid26562) on /wlink-1 type autofs (rw,fd=5,pgrp=26562,minproto=2,maxproto=3) dm2-ana0-1-sa:/wlink-1/user1 on /wlink-1/user1 type nfs (rw,addr=172.24.100.50)

user1 on fs_wlink-29 on a remote Data Mover (server_3):

[user1@LINUX1PAG01 user1_on_fs_wlink-29]$ mount | grep wlink-29 automount(pid26592) on /wlink-29 type autofs (rw,fd=5,pgrp=26592,minproto=2,maxproto=3) vdm3-ana0-6-sa:/root_vdm_3/wlink-29/user1 on /wlink-29/user1 type nfs (rw,addr=172.24.100.58)

From Windows, the symbolic links in user1 display as files:


C:\>dir \\dm2-ana0-1-sa\wl_root-1\user1 Volume in drive \\dm2-ana0-1-sa\wl_root-1 is 102 Volume Serial Number is 0000-0014 Directory of \\dm2-ana0-1-sa\wl_root-1\user1 02/02/2005 02/02/2005 02/01/2005 02/02/2005 02/02/2005 02/02/2005 12:43 PM <DIR> . 12:23 PM <DIR> .. 05:49 PM <DIR> user1 12:25 PM 14 user1_on_fs_wlink-1 12:25 PM 15 user1_on_fs_wlink-29 12:43 PM 0 NFS_user_file 3 File(s) 29 bytes 3 Dir(s) 52,867,235,840 bytes free

58 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Example procedure

The following procedure illustrates how to create two wide links that direct a Windows client to the fs_wslink-1\user1 directory on the local Data Mover and the fs_wlink-29\user1 directory on the remote Data Mover. After the two wide links are created, the user1 directory displays these symbolic links as directories in Windows instead of files, as previously shown.
Note: This procedure assumes that DFS support is enabled (default) and that you have created the DFS roots, as explained in "Using the Data Mover as a stand-alone DFS server" on page 50.

Step
1.

Action
Start the MMC Distributed File System tool.

Managing Celerra for a Multiprotocol Environment

Version 5.5

59 of 86

Step
2.

Action
From the Action dialog box, select Show Root. Type the NetBIOS name of the CIFS server used as the DFS root (in this example, DM2-ANA0-1-SA) on which you want to create a wide lInk.

3.

The system displays the DFS roots for DM2-ANA0-1-SA. Select the DFS root (in this example, \\DM2-ANA0-1-SA\w1_root-1) on which you want to create a wide link.

60 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Step
4.

Action
Right-click the \\DM2-ANA0-1-SA\w1_root-1 DFS root and select New Link.

The New Link dialog box appears, showing the UNC path to the DFS root. Each link that you create must correspond to a CIFS share or a Windows share. 5. Type the Link name and the Path to target, which must be the same in Windows and UNIX (in other words, the UNIX name of each component must be the M256 name in Windows), as shown in this example. This example shows how to create the first wide link, wlink-1\user1, to user1 on wlink-1 on the local Data Mover.

Managing Celerra for a Multiprotocol Environment

Version 5.5

61 of 86

Step
6.

Action
Create the second link to user1 on the remote Data Mover by repeating step 5 and typing the Link name and Path to target. This example shows how to create the second wide link, wlink-29\user1, to user1 on wlink-29.

62 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Step
7.

Action
Set the CIFS server and the DFS root in the Windows Registry: a. Set the CIFS server and CIFS share using the following Registry:

HKEY_LOCAL_MACHINE\SOFTWARE\EMC\WideLink\Share
The Registry must contain: \\server_name\share_name Where: server_name is the NetBIOS name of the CIFS server. If you are using a global share, only enter the CIFS share name. share_name is the name of the CIFS share or the Windows share. The following shows the Registry key for wl_root-1, which is a global share: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\Software\EMC\WideLink] "Share"="wl_root-1" b. Stop the CIFS service. c. Restart the CIFS service. If you try to update the Registry with a share name that is not in DFS, errors similar to the following appear in server_log: SMB: 3: Widelink:\\Global\w1_root-1 is not in DFS SMB: 3: Widelink: error while updating from Registry 7 If the Registry is set but the wide links feature is not configured, messages similar to the following appear on the screen: C:\>dir \\dm2-ana0-1-sa\wl_root-1\user1\user1_on_fs_wlink-1\ The network name cannot be found. C:\>dir \\dm2-ana0-1-sa\wl_root-1\user1\user1_on_fs_wlink-29\ The network name cannot be found. After setting the Registry key, symbolic links appear as directories in Windows, enabling users to read the contents of the following two directories: Local Data Mover: C:\>dir \\dm2-ana0-1-sa\wl_root-1\user1\user1_on_fs_wlink-1\ Volume in drive \\dm2-ana0-1-sa\wl_root-1 is 102 Volume Serial Number is 0000-0014 Directory of \\dm2-ana0-1-sa\wl_root1\user1\user1_on_fs_wlink-1 11:07 AM <DIR> . 11:56 AM <DIR> .. 07:08 PM 0 user1_NFS_file 10:27 AM <DIR> CIFS-user 1 File(s) 0 bytes 3 Dir(s) 52,867,260,416 bytes free Remote Data Mover: C:\>dir \\dm2-ana0-1-sa\wl_root-1\user1\user1_on_fs_wlink-29\ Volume in drive \\dm2-ana0-1-sa\wl_root-1 is 102 Volume Serial Number is 0000-0014 Directory of \\dm2-ana0-1-sa\wl_root1\user1\user1_on_fs_wlink-29 02/02/2005 02/01/2005 02/02/2005 05:11 PM <DIR> . 05:17 PM <DIR> .. 05:11 PM 0 NFS_user1_wlink-29 1 File(s) 0 bytes 2 Dir(s) 52,867,268,608 bytes free Version 5.5 63 of 86 02/02/2005 02/02/2005 02/01/2005 02/02/2005

Managing Celerra for a Multiprotocol Environment

Viewing/setting Windows ACLs from a UNIX client


You can view and modify the Windows ACL set on a file or directory from a UNIX client using EMC command-line tools called emcgetsd and emcsetsd. These tools are specifically helpful to a UNIX user who has read/write access on a file system but cannot access a file or directory because of insufficient ACL rights.
Note: You must mount the file system from a Celerra Network Server for these tools to work.

Retrieving emcgetsd and emcsetsd


The emcgetsd and emcsetsd tools are in the CifsTools/unixacltools directory on the Applications & Tools CD sent with the product. You can use the emcgetsd and emcsetsd tools with three different types of UNIX operating systems: Linux, Solaris, and HP-UX. Make sure you retrieve the appropriate tool executable for your operating system. You can copy these tools onto a UNIX client without performing an installation procedure on the client.

Viewing ACLs
The emcgetsd tool, described in Table 23, lets you view ACLs on a file or directory from a UNIX client or a Control Station.
Table 23 Using the emcgetsd command-line tool

Command
emcgetsd [-D <domain>] [-v] [-x] <local_node_path> emcgetsd a <local_node_path>

Description
Displays the security descriptor of a file system. A security descriptor lists the owner, ACL, and auditing information of the file system.

Option
-D <domain>

Description
Directs the command to a specified domain. This domain can be different from the user domain if there exists a trust relationship between the user domain and another domain. In this case, the command displays the SIDs for both domains. If the domain is not specified, CNS uses the default domain of the CIFS server.

-v

Displays full ACL details.

64 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Option
-x

Description
If CIFS is not started or if the Windows name of a user or group cannot be found, the SID of this user is returned in decimal format unless you specify the x option. Displays the access rights of a user currently logged in from a UNIX client or a Control Station. Path of the file or directory on the UNIX client.

-a

<local_node_path>

The following action shows you how to display the security descriptor of a file system using the verbose option.
Action
To display the security descriptor of a file system using the verbose option, use this command syntax: $ emcgetsd -v <local_node_path> Where: <local_node_path>= path of the file or directory on the UNIX client

Note: If a file or directory has SIDs in an ACL belonging to more than one domain, the output lists the users in the format of domain/user or domain/group without the -D option being specified in the emcgetsd command.
Example: To display the security descriptor of file system /fs2000A/apache/logs using the verbose option, type: $ emcgetsd v /fs2000A/apache/logs

Output
Dump of /fs2000A/apache/logs Security Descriptor -----------------------------------------------Owner uid=677 fro Group gid=2765 media DACL DENY

Gid=10 soft64 Access R-X--- 0x1200a9 READ_DATA READ_EA EXECUTE READ_ATTRIBUTES READ_CONTROL Flags 0x3 OBJECT_INHERIT CONTAINER_INHERIT GRANT Uid=698 acl1 Access RWXPDO 0x1f01ff

Managing Celerra for a Multiprotocol Environment

Version 5.5

65 of 86

Output
READ_DATA WRITE_DATA APPEND_DATA READ_EA WRITE_EA EXECUTE DELETE_CHILD READ_ATTRIBUTES WRITE_ATTRIBUTES DELETE READ_CONTROL WRITE_DAC WRITE_OWNER Flags 0x1f OBJECT_INHERIT CONTAINER_INHERIT NO_PROPAGATE_INHERIT INHERIT_ONLY INHERITED_ACE GRANT Everyone Access R-X--- 0x1200a9 READ_DATA READ_EA EXECUTE READ_ATTRIBUTES READ_CONTROL Flags 0x3 OBJECT_INHERIT CONTAINER_INHERIT SACL None

The following shows how to display the access rights of a user currently logged in from a UNIX client.
Action
To display the access rights of a user currently logged in from a UNIX client, use this command syntax: $ emcgetsd -a <local_node_path> Where: <local_node_path>= path of the file or directory on the UNIX client. Example: $ emcgetsd a /fred/test1/TestDir

Output
Server=dffr1, Path in the server=//test1/TestDir Access of user uid=602 with groups gids={107-2765} on //test1/TestDir NT Rights: R-XPDO 0x1f00e9 ReadExecute Read ListFolderContents

66 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Modifying ACLs
The emcsetsd tool lets you modify and view the ACL on a file or directory from a UNIX client or a Control Station.
Note: You must have the appropriate rights to use this tool.

When you change the Windows permissions using the emcsetsd tool, the Windows owner is replaced by the UNIX SID and the UNIX UID/GID, as shown in the following examples: Examples:
Owner uid=898 Unix='luc' Sid=S-1-5-18-1-898 Group gid=109 Unix='emc2' Sid=S-1-5-18-2-109

Before you can use the emcsetsd tool, you must enable it using the cifs acl.extacl parameter. "Configuring the cifs acl.extacl parameter" on page 47 provides a full description of the cifs acl.extacl parameter. Table 24 describes the command options of the emcsetsd tool.
Table 24 Using the emcsetsd command-line tool

Command
emcsetsd [-D <domain>] [-r] -g <user_or_group>,<rights>[,<flags>] -d <user_or_group>,<rights>[,<flags>] -s <user_or_group>,<rights>[,<flags>] -f <user_or_group>,<rights>[,<flags>] -a <user_or_group>,<rights>[,<flags>] <local_node_path>

Description
Sets, resets, and audits user or group access control rights on a file or directory. Note: If CIFS is not started or if the Windows name of a user or group is not found, the command is rejected. User A user can be one of the following: UID=number User=NIS name domain\user Group A group can be one of the following: GID=number Group=NIS name Everyone CreatorOwner CreatorGroup domain\user Note: You can also change the user and group owner using the chown/chgrp UNIX command.

Managing Celerra for a Multiprotocol Environment

Version 5.5

67 of 86

Table 24 Using the emcsetsd command-line tool (continued)

Command

Description
Rights The rights can be one of the following separated by a pipe (|): READ_DATA WRITE_DATA APPEND_DATA READ_EA WRITE_EA EXECUTE DELETE_CHILD READ_ATTRIBUTES WRITE_ATTRIBUTES DELETE READ_CONTROL WRITE_DAC WRITE_OWNER A combination of RWXPDO: R: Read W: Write X: Execute P: ChangePermission D: Delete O: TakeOwnership One or more of the following separated by a pipe (|): FullControl Modify ReadExecute ListFolderContents Read Write Flags One or more of the following values separated by a pipe (|): OBJECT_INHERIT: subfiles inherit this ACE. CONTAINER_INHERIT: subfolders inherit this ACE. NO_PROPAGATE_INHERIT: block inheritance from its parent. INHERIT_ONLY: ACE is not part of access rights on the current directory, only for inheritance. INHERITED_ACE: ACE was inherited.

68 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Option
-D <domain>

Description
Directs the command to a specified domain. This domain can be different from the user domain if there exists a trust relationship between the user domain and another domain. In this case, the command displays the SIDs for both domains. If the domain is not specified, CNS uses the default domain of the CIFS server.

-r

Removes current ACLs. Note: When you use the -r option, the SID of the owner and group are replaced by UNIX SIDs; therefore, after using the -r option, the identity of the owner and group reflects the new SIDs. Grants access to a user or group. Denies access to a user or group. Audits success access of a user or group. Audits fail access of a user or group. Audits all access of a user or group. Specifies the path of the file or directory on the UNIX client.

-g <user_or_group>,<rights>[,<flags>] -d <user_or_group>,<rights>[,<flags>] -s <user_or_group>,<rights>[,<flags>] -f <user_or_group>,<rights>[,<flags>] -a <user_or_group>,<rights>[,<flags>] <local_node_path>

Managing Celerra for a Multiprotocol Environment

Version 5.5

69 of 86

Troubleshooting
You can query the EMC WebSupport database for problem information, obtain release notes, or report a Celerra technical problem to EMC on Powerlink, the EMC secure extranet site. The Celerra Problem Resolution Roadmap technical module contains additional information about using Powerlink and resolving problems.

server_log error message construct


The format of the event code can help you narrow the scope of where to look for a message. There are several components in the beginning of each line that are fairly consistent across the entire scope of event logging. For example, the typical event message looks like:
2005-09-16 18:27:21: NFS: 3: 2005-09-16 18:27:23: CFS: 3: 2005-09-16 18:27:23: LIB: 6: commit failed, status = NoPermission Failed to open file, status NoPermission last message repeated 1 times

The Celerra Network Server Command Reference Manual provides detailed information on server_log. This logging mechanism uses the logging facilities typical with many systems.

The first part is the date and time of the logged event. The second part is the subsystem of the Celerra code that reported the event (for example, NFS, CFS, and LIB). The third part is a classification code, which is typical of event logging facilities. You can find information on classification codes on most UNIX systems under the header file syslog.h in the directory /usr/include/sys. The definition of the possible classification codes that the Celerra Network Server supports are:
#define #define #define #define #define #define #define #define LOG_EMERG LOG_ALERT LOG_CRIT LOG_ERR LOG_WARNING LOG_NOTICE LOG_INFO LOG_DEBUG 0 1 2 3 4 5 6 7 /* /* /* /* /* /* /* /* system is unusable */ action must be taken immediately */ critical conditions */ error conditions */ warning conditions */ normal but signification condition */ informational */ debug-level messages */

The fourth part describes the error condition. The error condition on the first two lines of the example are self-explanatory. The operations being performed are commit and open with the error condition, NoPermission. Other events are not as descriptive.

70 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Kerberos error codes


Kerberos error codes are statuses generally displayed by the SMB subsystem. You can recognize these in the logged events by the appearance of a large negative number. Example
2003-07-24 16:29:35: SMB: 3: -1765328160 SSXAK=c0020030 origin=401 stat=e0000,

Since Kerberos is standardized, there are public resources for looking up the meanings of a majority of these status codes. One resource on the Web is http:/ /www.net.berkeley.edu/kerberos/k5msgs.html, which provides a good listing of the Kerberos error codes and their definitions.

NT status codes
The NT status codes are reported for CIFS or Microsoft Windows emulation functions on the Celerra product. The NT status codes are 32-bit unsigned integers that are broken up into subgroups of binary data that identify the particulars of a event status. The 32-bit values are laid out as follows:
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +---+-+-+-----------------------+-------------------------------+ |Sev|C|R| Facility | Code | +---+-+-+-----------------------+-------------------------------+

Where:

Sev - is the severity code: 00 - Success 01 - Informational 10 - Warning 11 - Error C - is the customer code flag R - is a reserved bit Facility - is the facility code Code - is the facility's status code Typically, the NT status codes appear in the server_log with a subsystem specification of SMB. The NT status code is presented in several ways in logged system events. Some popular ones are:

A hexadecimal number prefixed by a Em=0x: SMB: 4: authLogon=SamLogonInvalidReply Es=0x0 Em=0xc0000064

A simple hexadecimal number with no prefix nor any indication of its format: SMB: 4: SSXAuth_SERVER_EXT13 aT=3 mT=1 c0000016 A simple hexadecimal number with a prefix of reply= with no indication of the format:

Managing Celerra for a Multiprotocol Environment

Version 5.5

71 of 86

SMB: 4: lookupNames:bad reply=c0000073

A simple hexadecimal number with a prefix of failed= with no indication of the format: SMB: 4: SessSetupX failed=c0000016 A hexadecimal number clearly marked as NTStatus= but no indication of the format: SMB: 4: MsError sendLookupNames=21 NTStatus=c0000073

Error messages
While using the system, various messages appear indicating successful command execution, or in some cases, a failure. Error messages appear when there is a fault in the command syntax or the system, while system messages are continually reported to the log file. Both types of messages reflect the performance of your system and can be used to monitor system efficiency and to troubleshoot problems. Table 25 lists the CIFS error messages written to the server log when problems occur in the Celerra CIFS facility and the corrective actions to take. The Celerra Network Server Error Messages Guide provides additional information on all Celerra errors.
Table 25 CIFS server log error messages

Message text
\\domain\share Security Descriptor error: Unable to set SD: Error 1337: The security ID structure is invalid. An ERROR occurred on \\domain\share. Abort /umount received unable open file

Full description
The local groups have not migrated properly.

Corrective action
Contact EMC Customer Service.

A file cannot be opened in CIFS; the client gets permission denied. CIFS activity and umount file system or freeze FS for checkpoint update.

This message contains information on why a client is getting an unexpected Permission Denied.

Access denied

Attempt to access files or directories with ACLs denying access.

Set the Back up files and directories or Restore files and directories privileges on the system where the pathname is located.

72 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Table 25 CIFS server log error messages (continued)

Message text
Bad parameter value, the min value allowed is 0

Full description
The error message when attempting to incorrectly set the cifs.maxLockXPending parameter. Occurs when attempting to change the param value of cifs.maxLockXPending parameter.

Corrective action
Set a value > 0. The range of allowed values is between 0 and #(CIFS threads/2). The Celerra Network Server Parameters Guide provides format and values.

could not get SIDS for user %d status %d to report file , id, lookup_stat Error 4020 : server_x : failed to complete command server_log error message: DomainJoin::doDo mjoin: Computer account compname already exists.

The translation user ID to SID failed for the specified UID. Quota report

The computer object already exists in the Active Directory and may be in use by either a Data Mover or another server. Also, the servicePrincipalName attribute is set not to accept existing accounts. The join procedure automatically creates a computer object in the Active Directory. The Windows NT user account may be missing from the PDC domain, or there is no corresponding UNIX account for the Windows NT user. C0000064 means STATUS_NO_SUCH_USER. The parameter value specified for cifs.maxLockXPending is not a numerical value.

Verify the existing computer object is not used by another system. To join the CIFS server to an existing account, use the reuse option of the server_cifs -Join command.

Incorrect password or unknown username

Add the Windows NT user to the PDC of the domain and map the user to a UNIX username and UID.

logon of user dvt_b\cdmsadmin failed: c0000064 LOG_LOCK,LOG_ERR , Bad parameter for cifs maxLockXPending

Check for a CDMS admin user in the specified domain. Set a numerical value. The Celerra Network Server Parameters Guide provides more information.

Managing Celerra for a Multiprotocol Environment

Version 5.5

73 of 86

Table 25 CIFS server log error messages (continued)

Message text
migrate sd of \Perl\lib\perllo cal.pod has unresolved ACLs, status: c000005b

Full description
C000005B means STATUS_INVALID_PRIMARY _GROUP.

Corrective action
This error occurs when the primary groups SID is replaced by the primary group SID of the user that is used for migration: Generally, this occurs when the SID belongs to a group not supported on the Celerra Network Server. The user should ignore the error. If the SID belongs to a nonexistent local group on the Celerra Network Server, the user may not have run the lgdup.exe utility before migration began.

No domain controller found for the domain.

In NT security mode, clients are unable to connect to the server, and the window to prompt for username and password does not appear on the client side. MMC requires Internet Explorer 6.0 in order to use its DOM (Document Object Model) XML parser. User tried to set an incorrect value for the parameter cifs.prealloc.

Check if PDC or BDC is up. Check if Data Mover can access a WINS server that knows about the PDC domain, or have the PDC/BDC in the same local subnet as the Data Mover. Upgrade the version of your Internet Explorer to 6.0.

OLE Object: PBrush

Prealloc value must be integer and not greater than 6 RO Error from readdir key=256: 201065600466: UFS: 3: create: this->i_nlink == 0 for ino 11

Correct the parameter value (between 0 and 6). The Celerra Network Server Parameters Guide provides values and format.

An FS event occurred when trying to perform a lookup on the file system to retrieve the node for theses names. The lookupComponent fails with error 7 - "not found."

74 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Table 25 CIFS server log error messages (continued)

Message text
The Account is not authorized to login from this station

Full description
In a Windows NT environment, Windows clients cannot connect to a server using clear text passwords. (For example, this might occur when the Celerra Network Server is in UNIX mode.) The SMB redirector handles unencrypted passwords differently than previous version of Windows NT. The SMB redirector does not send an unencrypted password unless you add a Registry entry to enable unencrypted passwords.

Corrective action
Modify the Registry to enable unencrypted passwords. CAUTION: Incorrectly modifying the Registry may cause serious systemwide problems that may cause you to reinstall your system. Run Registry Editor (Regedt32.exe). From the HKEY_LOCAL_MACHINE subtree, go to the following key: System\CurrentControlSet\Se rvices\rdr\parameters Under this key, create a new DWORD registry key named EnablePlainTextPassword, set its value to 1, and then restart your computer. Select Add Value on the Edit menu. Add the following: Value Name: EnablePlainTextPassword Data Type: REG_DWORD Data: 1 Click OK and quit Registry Editor. Shut down and restart Windows NT. This Procedure was adapted from Article ID: Q166730 of the Microsoft Knowledge Base.

The SAM database on the Windows NT server does not have a complete account for this workstation trust relationship. Unable to create files or directories in a share that is mapped to a client.

The servers NetBIOS name is not registered as a computer account on the PDC domain or a trust relationship is not established between the client and server domains.

If the computer account does exist, remove it and add it again before retrying the command. To set up a trust relationship between domains, refer to Microsoft NT server 4.0 documentation.

UNIX permission bits are not set to grant permission for the user to write to the shared directory. This situation could only occur if the access-checking policy is set incorrectly. User tried to set an incorrect value in the parameter cifs.vnodepercent.

Change the access-checking policy or mount the directory over NFS on the Control Station or any other UNIX client, and use chmod to set the appropriate UNIX permission to allow the user to write to it.

Vnodepercent must be integer and between 10 and 100

Correct the parameter value (between 10 and 100). The Celerra Network Server Parameters Guide provides information for values and format.

Managing Celerra for a Multiprotocol Environment

Version 5.5

75 of 86

Table 25 CIFS server log error messages (continued)

Message text
write to SID file failed

Full description
The creation of the SID mapping file failed. Quota report.

Corrective action
Ensure the root file system is not full and can be correctly read/written.

xml_lookupid : groupQuery creation error

Memory saturation: The object groupQuery cannot be created. Quota report or quota creation.

Reboot the Data Mover and report the problem to EMC Customer Service.

xml_lookupid : groupQueryElt creation error

Memory saturation: The object groupQueryElt cant be created. Quota report or quota creation.

Reboot the Data Mover and report the problem to EMC Customer Service.

xml_lookupid : nameQuery creation error

Memory saturation: The object nameQuery cannot be created. Quota report or quota creation.

Reboot the Data Mover and report the problem to EMC Customer Service.

xml_lookupid : nameQueryElt creation error

Memory saturation: The object nameQueryElt cannot be created. Quota report or quota creation.

Reboot the Data Mover and report the problem to EMC Customer Service.

xml_lookupid : userQuery creation error

Memory saturation: The object userQuery cannot be created. Quota report or quota creation.

Reboot the Data Mover and report the problem to EMC Customer Service.

xml_lookupid : userQueryElt creation error

Memory saturation: The object userQueryElt cannot be created. Quota report or quota creation.

Reboot the Data Mover and report the problem to EMC Customer Service.

xml_lookupname: Cannot create SIDQuery %s , ident xml_lookupname: gidQuery creation error

Memory saturation: The object sidQuery cannot be created Quota report or quota creation. Memory saturation: The object gidQuery cannot be created. Quota report or quota creation.

Reboot the Data Mover and report the problem to EMC Customer Service.

Reboot the Data Mover and report the problem to EMC Customer Service.

76 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Table 25 CIFS server log error messages (continued)

Message text
xml_lookupname: gidQueryElt creation error

Full description
Memory saturation: The object gidQueryElt cannot be created. Quota report or quota creation.

Corrective action
Reboot the Data Mover and report the problem to EMC Customer Service.

xml_lookupname: UID or gid must be numeric , ident xml_lookupname: UIDQuery creation error, insufficient memory available xml_lookupname: UIDQueryElt creation error, insufficient memory available

Syntax error in a XML request NAME_LOOKUP.

Memory saturation: The object UIDQuery cannot be created. Quota report or quota creation. Memory saturation: The object UIDQueryElt cannot be created. Quota report or quota creation.

Reboot the Data Mover and report the problem to EMC Customer Service.

Reboot the Data Mover and report the problem to EMC Customer Service.

Problem situations
Table 26 lists problem situations you may encounter in a multiprotocol environment as well asa description and the corrective actions to take.
Table 26 Problem situations

Problem
With NT user authentication, certain Windows 95 clients may not be able to map drives from the Data Mover.

Description
The domain name sent to the Data Mover by the client was incorrectly specified, or the username.domain is not mapped in the passwd file on the Data Mover.

Corrective action
Verify that the client is sending the correct domain name to the passwd file. To verify that the client is sending the correct domain, perform the following: 1. In the Network option in the Control Panel, double-click the network client (Client for Microsoft Networks). 2. Under General properties, verify that the correct domain name is shown. Add the Windows NT user to the PDC of the domain and map the user to a UNIX username and UID.

With NT user authentication, Incorrect password or unknown username error message appears after attempts to connect to the server, and the username and password window appears.

The Windows NT user account may be missing from the PDC domain, or the Data Mover was unable to determine a UID to use for this user.

Managing Celerra for a Multiprotocol Environment

Version 5.5

77 of 86

Table 26 Problem situations (continued)

Problem
Unable to create files or directories in a share that is mapped to a client.

Description
UNIX permission bits are not set to grant permission for the user to write to the shared directory. Note: This situation only occurs when the access-checking policy is set incorrectly. "Setting security on file system objects" on page 18 for more information.

Corrective action
Change the access-checking policy or mount the directory over NFS on the Control Station or any other UNIX client, and use chmod to set the appropriate UNIX permission to allow the user to be able to write to it.

Windows NT environment: Windows clients cannot connect to a server using clear text passwords. (For example, this might occur when the Celerra Network Server is in UNIX mode.) The following error message might appear: The Account is not authorized to login from this station

The SMB redirector handles unencrypted passwords differently than previous version of Windows NT. The SMB redirector does not send an unencrypted password unless you add a Registry entry to enable unencrypted passwords.

You must modify the Registry to enable unencrypted passwords. WARNING Incorrectly modifying the Registry may cause serious system-wide problems that may require you to reinstall your system. Use this tool at your own risk. 1. Run Registry Editor (Regedt32.exe). 2. From the HKEY_LOCAL_MACHINE subtree, go to the following key: System\CurrentControlSet\Serv ices\rdr\parameters 3. Under this key, create a new DWORD Registry key named EnablePlainTextPassword, set its value to 1, and then restart your computer. 4. Select Add Value on the Edit menu. 5. Add the following: Value Name: EnablePlainTextPassword Data Type: REG_DWORD Data: 1 6. Click OK and quit Registry Editor. 7. Shut down and restart Windows NT. Note: Use GPOs for Windows 2000 and Windows Server 2003 clients. The procedure was adapted from Article ID: Q166730 of the Microsoft Knowledge Base.

78 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Table 26 Problem situations (continued)

Problem
With NT user authentication, clients are unable to connect to the server, and the window to prompt for username and password does not appear on the client side.

Description
No domain controller found for the domain.

Corrective action
Check if PDC or BDC is up. Check if the Data Mover can access a WINS server that knows about the PDC domain, or have the PDC/BDC in the same local subnet as the Data Mover.

or The servers NetBIOS name is not registered as a computer account on the PDC domain or a trust relationship has not been established between the client and server domains. The following message may appear in the server_log: The SAM database on the Windows NT server does not have a complete account for this workstation trust relationship.

Verify that the computer account exists and add the computer account, if needed. If the computer account does exist, remove it and add it again before retrying the command. To set up a trust relationship between domains, refer to Microsoft NT server 4.0 documentation.

After joining a CIFS server to a domain, the following error appears in the server_cifs output, indicating the system cannot update the DNS record: FQDN=dm4-a140ana0.c1t1.pt1.c3lab.nsgprod.em c.com (Update of "A" record failed during update: Operation refused for policy or security reasons) 0xC0000022 2004-04-26 10:49:40: SMB: 3: Srv=<Celerra_netbios_name> buildSecureChanel=Authenticate 2InvalidReply E=0xc0000022

The DNS servers zone may include the same FQDN (fully-qualified domain name) for another computer account.

Verify the DNS servers zone does not have the same FQDN with a different IP address for another computer account.

Access is denied because the computer was created on the domain controller without enabling the Allow preWindows 2000 computers to use this account option on the Windows New Object - Computer dialog box. MMC requires Internet Explorer 6.0 in order to use its DOM (Document Object Model) XML parser.

Delete the computer and then re-create it with the Allow pre-Windows 2000 computers to use this account option enabled.

When attempting to start MMC, the following error message appears: OLE Object: PBrush

Upgrade the version of your Internet Explorer to 6.0.

Managing Celerra for a Multiprotocol Environment

Version 5.5

79 of 86

Table 26 Problem situations (continued)

Problem
Solaris client receives the following warning message during the creation of a user account: UX:useradd: WARNING: more than NGROUPS_MAX(16) groups specified The user account is still created but data availability may occur. When attempting access, Solaris client receives an error message similar to the following: nfs: [ID XXXXXX kern.notice] NFS access failed for server dm3-121-ana0-2: error 1 (RPC: Can not encode arguments) After upgrading from a Windows NT domain to Windows 2000, unable to change the original domain suffix during Windows 2000 setup. Access is denied to Internet Information Services (IIS) 6.0 when attempting to connect to the web directory on a Celerra share. In the IIS web log, the error bad user name or password displays even though the user name and password are in the local user database.

Description
This is likely caused by the Solaris NGROUPS_MAX kernel parameter being set to more than 16 groups, which is the default limit on Solaris systems. NFS only has support for a maximum of 16 groups. Depending on the UNIX implementation, the limit on the number of groups per user is different: Solaris has a limit of 16 groups Linux has a limit of 32 groups

Corrective action
In a multiprotocol environment, to extend this group number to more than 16, use the Celerra File Server NT credential feature.

Unable to change domain suffix because it was hardcoded in DDNS.

Before upgrading, change the domain suffix.

For a stand-alone CIFS server with local user support enabled, the user
name and password must be the same on IIS 6.0, the Data Mover, and the client.

Specify the same user name and password on IIS 6.0, the Data Mover, and the client.

80 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Related information
For specific information related to the features and functionality described in this technical module, refer to:

Configuring CIFS on Celerra Managing Celerra for the Windows Environment Configuring NFS on Celerra Celerra Network Server Parameters Guide Celerra Network Server Command Reference Manual Celerra Network Server Error Messages Guide Using EMC Utilities for the CIFS Environment Celerra Network Server User Information Glossary Using Windows Administrative Tools with Celerra Managing Celerra Volumes and File Systems Manually Replicating Celerra CIFS Environments Installing Celerra Management Applications Configuring Celerra Time Services Configuring Virtual Data Movers for Celerra Using International Character Sets with Celerra Configuring Celerra Naming Services Configuring External Usermapper for Celerra Configuring Celerra User Mapping

The Celerra Network Server Documentation CD, supplied with your Celerra Network Server and also available on Powerlink, provides general information on other EMC Celerra publications.

Customer training programs


EMC customer training programs are designed to help you learn how EMC storage products work together and integrate within your environment to maximize your entire infrastructure investment. EMC customer training programs feature online and hands-on training in state-of-the-art labs conveniently located throughout the world. EMC customer training programs are developed and delivered by EMC experts. For program information and registration, refer to Powerlink, our customer and partner website.

Managing Celerra for a Multiprotocol Environment

Version 5.5

81 of 86

82 of 86 Version 5.5

Managing Celerra for a Multiprotocol Environment

Index
A
access checking, file system objects 20 access rights configuring policies 33, 40 multiprotocol environment 24 UNIX 18 Windows 19 access-checking policies decision tree 23 MIXED 21 MIXED_COMPAT 22 multiprotocol environment 24 NATIVE 20 NT 21 overview 20 SECURE 21 setting 30 translation process 31 UNIX 21 access-checking, using only UNIX permissions 41 ACE 19 ACL and mode bits, synchronizing 25 acl.extendExtraGid parameter 38 ACLs definition 19 modifying from a UNIX client 67 viewing from a UNIX client 64

emcgetsd tool 64, 67 expanding group memberships, user credential 38

F
file access setting ACLs from UNIX 64 viewing UNIX permissions 46 file locking CIFS deny modes 43 in CIFS environment 43 in NFS environment 43 limitations 44 policies 43 file naming conventions 10 file system objects access checking 20 backing up 29 security 20 UNIX 18 setting permissions 30 Windows security 19

G
GIDs, resolution 9

I
inheritance rules, access-checking policies 28 Interoperability considerations 10

C
cache, Windows NT credential 37 CIFS definition 3 file access, deny modes 43 server, definition 4 service, definition 4 symbolic links 11 troubeshooting 7079 cifs acl.checkacl parameter 41 cifs acl.extacl parameter 46

L
link, symbolic 11

M
mapping, user IDs 9 master policy, translation 31 MIXED access-checking policy 21 MIXED/MIXED_COMPAT automatic synchronization 25 inheritance rules 29 migrating to 31 overview 25 resetting of 33 MIXED_COMPAT access-checking policy 22 mode bits 18 multiprotocol environment access-checking policies 21, 22, 23, 24 backing up FSOs 29 creating a Windows-style credential 34 file naming conventions 10 permissions 24 security on FSOs 20

D
DACL 19 Data Mover standalone DFS server 50 deriving permissions, during translation 31 DFS configuring 51 disabling 51 enabling 51 root servers 50 wide links 50, 56 DFS root, creating stand-alone Data Mover 52 using dfsutil.exe 52 using MMC 52 Managing Celerra for a Multiprotocol Environment

Version 5.5

83 of 86

N
NATIVE access-checking policy 20 NDMP 29 NFS access 34 NFS/CIFS file naming conventions 10 resolving name conflicts 10 NT access-checking policy 21 NTcred.size parameter 37 NTcred.TTL parameter 37

P
parameters acl.extendExtraGid 38 cifs acl.checkacl 41 cifs acl.extacl 46 NTcred.size 37 NTcred.TTL 37 shadow followabsolutpath 13 shadow followdotdot 11 permissions multiprotocol environment 24 security 20 synchronization of 32 processing, Windows NT credential 35

umask 28, 29 UNIX client, displaying access rights 66 credential 20 mode bits 18 permissions, setting from Windows 46 security model 18 UNIX access-checking policy 21 user credentials 20 user ID resolution, configuring 9 user interfaces, choices 7

W
wide links 50 creating 59 overview 56 processing steps 57 setting Windows Registry 63 Windows ACLs, setting from UNIX 64 credential 20 default domain, setting 37 security model 19 setting file permissions 19 Windows NT credential adding groups to 38 cache 37 definition of 34 generating 40 group memberships 34 processing of 35 setting default domain 37 time-to-live stamp 37 Windows Registry, wide links 63

R
restoring, file system objects 29

S
SACL 19 SECURE access-checking policy 21 security multiprotocol environment 20 Windows 19 security descriptor 19, 65 security, permissions 20 setting access-checking policy 30 shadow followabsolutpath parameter 13 shadow followdotdot parameter 11 stand-alone DFS server 50 symbolic links 11 enabling upward paths 11 synchronization of, ACL and mode bits 25, 32 system requirements 6

T
time-to-live stamp, Windows NT credential 37 translating permissions command 32 master policy 31 UNIX to Windows 27 Windows to UNIX 26 translation process, access-checking policies 31 translation status 33 troubleshooting 7079 trusted domain, accessing 36

84 of 86

Version 5.5

Managing Celerra for a Multiprotocol Environment

Notes

Managing Celerra for a Multiprotocol Environment

Version 5.5

85 of 86

About this technical module


As part of its effort to continuously improve and enhance the performance and capabilities of the Celerra Network Server product line, EMC from time to time releases new revisions of Celerra hardware and software. Therefore, some functions described in this document may not be supported by all revisions of Celerra software or hardware presently in use. For the most up-to-date information on product features, see your product release notes. If your Celerra system does not offer a function described in this document, contact your EMC Customer Support Representative for a hardware upgrade or software update.

Comments and suggestions about documentation


Your suggestions will help us improve the accuracy, organization, and overall quality of the user documentation. Send a message to celerradoc_comments@EMC.com with your opinions of this document.

Copyright 1998-2006 EMC Corporation. All rights reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. All other trademarks used herein are the property of their respective owners.

86 of 86 Version 5.5

You might also like