Professional Documents
Culture Documents
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
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.
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
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.
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
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.
Version 5.5
5 of 86
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
6 of 86 Version 5.5
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
The Installing Celerra Management Applications technical module includes instructions on launching Celerra Manager, and on installing the MMC snap-ins and the ADUC extensions.
Version 5.5
7 of 86
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
8 of 86 Version 5.5
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.
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 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.
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.
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
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).
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.
Version 5.5
11 of 86
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.
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
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
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.
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
14 of 86 Version 5.5
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
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
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.
Version 5.5
15 of 86
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
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
16 of 86 Version 5.5
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.
Version 5.5
17 of 86
Group
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
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.
Version 5.5
19 of 86
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
Table 5
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
Version 5.5
21 of 86
Table 5
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
No
Yes
Yes
No
Yes
NT
MIXED Or MIXED_COMPAT
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.
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
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
Builds Owner mode bits from the Owner entry, the ACE of the file/directory, and the Everyone Group ACE.
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
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
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 +
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
Version 5.5
27 of 86
R
Take Ownership*
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
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.
Version 5.5
29 of 86
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
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
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
Version 5.5
31 of 86
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
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.
Output
server_2: done
Version 5.5
33 of 86
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
Yes
No
No Yes
Create NT credential
Yes
No
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.
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.
36 of 86 Version 5.5
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).
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.
Version 5.5
37 of 86
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
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
Version 5.5
39 of 86
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
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.
Version 5.5
41 of 86
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
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.
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
Output
server_2: done
Note
A <mount_point> must begin with a forward slash (/).
Version 5.5
45 of 86
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
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.
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.
Version 5.5
47 of 86
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
Output
server_2 : done
Version 5.5
49 of 86
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
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
Share type
Local Share Global Share You can view a DFS root on a global share from any CIFS server on the Data Mover.
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.
Version 5.5
51 of 86
Action
Start the New Root Wizard tool from MMC DFS.
52 of 86 Version 5.5
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.
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
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.
Version 5.5
55 of 86
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
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.
link to fs_wslink-1\user1 on the local Data Mover link to fs_wlink-29\user1 on a remote Data Mover
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 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
[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@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)
58 of 86 Version 5.5
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.
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
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.
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
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
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
64 of 86 Version 5.5
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
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
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.
Version 5.5
67 of 86
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
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.
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.
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
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 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:
Version 5.5
71 of 86
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
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
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.
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.
Version 5.5
73 of 86
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.
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.
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
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.
Correct the parameter value (between 10 and 100). The Celerra Network Server Parameters Guide provides information for values and format.
Version 5.5
75 of 86
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.
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.
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.
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.
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.
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.
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.
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
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
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.
Version 5.5
77 of 86
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
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
Version 5.5
79 of 86
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.
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
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.
Version 5.5
81 of 86
82 of 86 Version 5.5
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
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
Notes
Version 5.5
85 of 86
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