Managing Celerra for a Multiprotocol Environment 5.6.47 A03

EMC Celerra Network ServerRelease 5.6.47

Managing Celerra for a Multiprotocol EnvironmentP/N 300-004-135

REV A03

EMC CorporationCorporate Headquarters:

Hopkinton, MA 01748-91031-508-435-1000

www.EMC.com

Copyright 2006 - 2009 EMC Corporation. All rights reserved.

Published December 2009

EMC believes the information in this publication is accurate as of its publication date. Theinformation is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." EMC CORPORATIONMAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TOTHE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires anapplicable software license.

For the most up-to-date regulatory document for your product line, go to the TechnicalDocumentation and Advisories section on EMC Powerlink.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks onEMC.com.

All other trademarks used herein are the property of their respective owners.

Corporate Headquarters: Hopkinton, MA 01748-9103

2 Managing Celerra for a Multiprotocol Environment 5.6.47

Contents

Preface....................................................................................................................7

Chapter 1: Introduction...........................................................................9System requirements.............................................................................................10

User interface choices...........................................................................................10

Related information..............................................................................................10

Chapter 2: Concepts.............................................................................13Planning considerations.......................................................................................14

CIFS user ID resolution........................................................................................14

Security on file system objects.............................................................................15

User access control of file system objects...........................................................16

Inheritance rules..........................................................................................25

Windows-style credential for UNIX users.........................................................26

Determining the GID for file system objects.....................................................27

Backing up and restoring file system objects....................................................28

File naming.............................................................................................................28

File locking.............................................................................................................29

Wide links...............................................................................................................30

Distributed File System server.............................................................................31

Symbolic links........................................................................................................31

Chapter 3: Managing............................................................................33Change the default symbolic link behavior.......................................................34

Enable symbolic links with target paths to parent directories.............34

Enable symbolic links with absolute paths..............................................35

Link file systems....................................................................................................36

Managing Celerra for a Multiprotocol Environment 5.6.47 3

Access symbolic links through CIFS clients............................................36

Access symbolic links through NFS clients.............................................38

Set the access-checking policy.............................................................................39

Migrate access_checking policy to MIXED and MIXED_COMPAT..............39

Synchronize Windows and UNIX permissions......................................40

Reset the access policy................................................................................40

Check the translation status.......................................................................41

Manage a Windows NT credential.....................................................................41

Generate Windows NT credentials ..........................................................42

Include UNIX groups in a Windows NT credential...............................42

Modify Windows NT credential settings.................................................43

Set the Windows default domain..............................................................44

Define the Windows NT credential cache...............................................44

Set the time-to-live expiration stamp........................................................45

Use only UNIX permissions for access checking..............................................46

Manage UNIX permissions from a Windows client.........................................47

Manage Windows ACL from a UNIX client......................................................48

Display security descriptor........................................................................49

View access rights........................................................................................51

Use UNIX GIDs for file system objects...............................................................51

Determine the GIDs on copied file system objects...........................................51

Set the file locking policy.....................................................................................52

Configure and administer DFS support.............................................................53

Create a DFS root using dfsutil.exe..........................................................53

Create a stand-alone DFS root using DFS MMC....................................54

Disable DFS support...................................................................................54

Create wide links...................................................................................................55

Chapter 4: Troubleshooting..................................................................60Troubleshooting.....................................................................................................60

EMC E-Lab Interoperability Navigator..............................................................60

server_log error message construct....................................................................60

Kerberos error codes.............................................................................................61

NT status codes......................................................................................................61

Known problems and limitations.......................................................................62

Symbolic link limitations......................................................................................65

Error messages.......................................................................................................66

EMC Training and Professional Services...........................................................66


Contents

Appendix A: emcgetsd and emcsetsd...............................................67Using emcgetsd and emcsetsd.............................................................................68

Terminology............................................................................................75

Index.......................................................................................................79


Contents


Contents

Preface

As part of an effort to improve and enhance the performance and capabilities of its product lines,EMC periodically releases revisions of its hardware and software. Therefore, some functions describedin this document may not be supported by all versions of the software or hardware currently in use.For the most up-to-date information on product features, refer to your product release notes.

If a product does not function properly or does not function as described in this document, pleasecontact your EMC representative.


Special notice conventions

EMC uses the following conventions for special notices:

A caution contains information essential to avoid data loss or damage to the system orequipment.

Important: An important note contains information essential to operation of the software.

Note: A note presents information that is important, but not hazard-related.

Hint: A note that provides suggested advice to users, often involving follow-on activity for aparticular action.

Where to get help

EMC support, product, and licensing information can be obtained as follows:

Product information For documentation, release notes, software updates, or forinformation about EMC products, licensing, and service, go to the EMC Powerlinkwebsite (registration required) at http://Powerlink.EMC.com.

Troubleshooting Go to Powerlink, search for Celerra Tools, and select CelerraTroubleshooting from the navigation panel on the left.

Technical support For technical support, go to EMC Customer Service on Powerlink.After logging in to the Powerlink website, go to Support Request Support. To opena service request through Powerlink, you must have a valid support agreement.Contact your EMC Customer Support Representative for details about obtaining avalid support agreement or to answer any questions about your account.

Note: Do not request a specific support representative unless one has already been assigned toyour particular system problem.

Your comments

Your suggestions will help us continue to improve the accuracy, organization, and overallquality of the user publications.

Please send your opinion of this document to:

[email protected]


Preface

1Introduction

In a UNIX environment, the network file system (NFS) protocol is usedto access file systems. In a Windows environment, the Common InternetFile System (CIFS) protocol is used to access file systems. The EMC CelerraNetwork Server supports a mixed NFS and CIFS environment by providingmultiprotocol access capabilities such as access-checking policies andlocking mechanisms enabling UNIX and Windows users to share the samefile systems.

This document is part of the Celerra Network Server documentation setand is intended for system administrators responsible for implementingthe Celerra Network Server in their mixed Windows and UNIXenvironment. Topics include:

System requirements on page 10 User interface choices on page 10 Related information on page 10


System requirements

For system requirements, see:

Configuring and Managing CIFS on EMC Celerra for CIFS access requirements

Configuring NFS on EMC Celerra for NFS access requirements

User interface choices

The EMC Celerra Network Server offers flexibility in managing networked storage basedon your support environment and interface preferences. This document describes how toconfigure the Celerra Network Server in a multiprotocol environment by using the commandline interface (CLI). You can also perform some of these tasks by using one of the Celerramanagement applications:

Celerra Manager Basic Edition

Celerra Manager Advanced Edition

Microsoft Management Console (MMC) snap-ins

Active Directory Users and Computers (ADUC) extensions

The following documents provide additional information:

Learning about EMC Celerra on the EMC Celerra Network Server Documentation CD

Celerra Manager online help

Applications online help system on the EMC Celerra Network Server DocumentationCD

The Installing EMC Celerra Management Applications document includes instructions onlaunching Celerra Manager, and on installing the MMC snap-ins and the ADUC extensions.

Related information

Specific information related to the features and functionality described in this document areincluded in:

Configuring and Managing CIFS on EMC Celerra

Configuring NFS on EMC Celerra

Configuring EMC Celerra User Mapping

Using ntxmap for EMC Celerra CIFS User Mapping


Introduction

Configuring EMC Celerra Naming Services

Configuring EMC Celerra Time Services

Configuring Virtual Data Movers for EMC Celerra

Installing EMC Celerra Management Applications

Using Windows Administrative Tools with EMC Celerra

Using EMC Utilities for the CIFS Environment

Managing EMC Celerra Volumes and File Systems with Automatic Volume Management

Managing EMC Celerra Volumes and File Systems Manually

Replicating EMC Celerra CIFS Environments (V1)

Using International Character Sets with EMC Celerra

EMC Celerra Glossary

EMC Celerra Network Server Command Reference Manual

EMC Celerra Network Server Error Messages Guide

EMC Celerra Network Server Parameters Guide

EMC Celerra Network Server Documentation CD

The EMC Celerra Network Server Documentation CD, supplied with Celerra and alsoavailable on the EMC Powerlink website, provides the complete set of EMC Celerracustomer publications. After logging in to Powerlink, go to Support TechnicalDocumentation and Advisories Hardware/Platforms Documentation Celerra NetworkServer. On this page, click Add to Favorites. The Favorites section on your Powerlinkhome page provides a link that takes you directly to this page.

To request an EMC Celerra Network Server Documentation CD, send an email request to:

[email protected]

Celerra Support Demos

Celerra Support Demos are available on Powerlink. Use these instructional videos tolearn how to perform a variety of Celerra configuration and management tasks. Afterlogging in to Powerlink, go to Support Product and Diagnostic Tools Celerra Tools Celerra Support Demos.

Related information 11

Introduction

Celerra wizards

Celerra wizards can be used to perform Celerra Manager tasks.UsingWizards to ConfigureCelerra provides you with an overview of the steps required to configure a CelerraNetwork Server by using the Set Up Celerra wizard in Celerra Manager.


Introduction

2Concepts

Planning considerations on page 14 describes the tasks you need tocomplete prior to configuring features that enable UNIX and Windowsusers to share the same file systems.

In addition, you might need to understand some, if not all, of the followingconcepts when operating in a multiprotocol file sharing environment:

Planning considerations on page 14 CIFS user ID resolution on page 14 Security on file system objects on page 15 User access control of file system objects on page 16 Windows-style credential for UNIX users on page 26 Determining the GID for file system objects on page 27 Backing up and restoring file system objects on page 28 File naming on page 28 File locking on page 29 Wide links on page 30 Distributed File System server on page 31 Symbolic links on page 31


Planning considerations

Prior to configuring features that enable UNIX and Windows users to share the same filesystems, you need to complete the following tasks:

Complete the initial configuation of your CIFS environment, including configuring aCIFS server. Configuring and Managing CIFS on EMC Celerra explains how to configure abasic CIFS configuration on the Celerra Network Server by using the command lineinterface (CLI). This initial environment can also be configured by using Celerra Manager.

Configuring and Managing CIFS on EMC Celerra also contains advanced procedures thatmight be required after the initial configuration of CIFS on the Celerra Network Serverand instructions for modifying and managing Celerra in a Windows environment.

Complete the initial configuration of your NFS environment. Configuring NFS on EMCCelerra and NFS Exports online help in Celerra Manager explains how to configure andmanage NFS (versions 2, 3, and 4) on the Celerra Network Server.

Configure a user mapping technique best suited to your mixed environment.ConfiguringEMC Celerra User Mapping provides a list of the tools and methods that can be used tomap Windows users to UNIX-style UID and GIDs and the tools that can be used tomigrate users from a single-protocol environment to a multiprotocol environment.

CIFS user ID resolution

Every user of the Celerra Network Server, either Windows or UNIX must be identified bya unique number user identifier (UID) and group identifier (GID). Windows, however, doesnot use numeric IDs to identify users. Instead, strings called security identifiers (SIDs) areused.

Before configuring the Windows file-sharing service (referred to as CIFS) on the CelerraNetwork Server, a method of mapping Windows SIDs to UIDs and GIDs must be selected.The method used depends on whether there is a Windows-only or Windows and UNIXenvironment. These methods include:

Active Directory

LDAP Directory

Local files

Network Information Service (NIS)

Usermapper (Internal or External)

EMC recommends use of Internal Usermapper in Windows-only environments. InternalUsermapper might also be used in multiprotocol environments with users having onlyWindows accounts.


Concepts

Security on file system objects

In a multiprotocol environment, the Celerra Network Server uses its security policies tomanage the access control of its file systems.

UNIX security model

UNIX access rights are referred to as the mode bits of a file system object. They arerepresented by a bit string in which each bit represents an access mode or privilegegranted to the user owning the file, the group associated with the file system object, andall other users.

UNIX mode bits are represented as three sets of concatenated rwx (read, write, execute)triplets for each category of users (user, or group, or other), as shown in Figure 1 on page15.

Figure 1. File system directory

The file system directory example illustrates the following:

The first character of each line indicates the file type: d for a directory, l for a symboliclink, or dash (-) for a regular file.

The next nine characters of each line are the read/write or execute permission sets foruser or group or 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 insertfiles into it and delete files from it.

Windows security model

The Windows security model is based primarily on per-object rights, which involve theuse of a security descriptor (SD) and an access control list (ACL).

Access to a file system object is based on whether permissions have been set to Allowor Deny through the use of an security descriptor. The SD describes the owner of theobject and group SIDs for the object along with its ACLs. An ACL is part of the securitydescriptor for each object. Each ACL contains access control entries (ACEs). Each ACE,in turn, contains a single SID that identifies a user, group, or computer and a list of rightsthat are denied or allowed for that SID.

Security on file system objects 15

Concepts

The Celerra Network Server supports ACLs at the share, directory, and file level.

User access control of file system objects

In a multiprotocol environment, the Celerra Network Server uses access policies to manageuser access control of its file systems.

The access policy is specified using the accesspolicy option on the server_mount command.Set the access-checking policy on page 39 describes this task.

User credentials and access checking

A Windows user credential is built and cached when a user first connects to a CelerraNetwork Server through the CIFS protocol. The credential contains the user SID and allthe SIDs of the groups in which the user is a member. When using regular UNIXauthentication (AUTH_SYS), a UNIX user credential is sent along with the RemoteProcedure Calling (RPC) protocol request and consists of an UID and up to 16 GIDs towhich the user belongs. In a Secure NFS environment the UNIX user credential is builtduring the Kerberos authentication, and consists of the user's UID and GIDs of all thegroups in which the user is a member. When a user requests access to a file system object,the Celerra Network Server compares the user credentials with the permissions on thatfile system object.

For an FTP user providing a domain and username, the Celerra Network Server contactsthe domain controller for verification, and then builds a Windows credential. For an FTPuser providing an unqualified username, the Celerra Network Server builds a UNIX-stylecredential based on the information in the local passwd and group files, NIS, or LDAPdirectory service.


Concepts

Celerra access-checking policies

In a multiprotocol environment, the Celerra Network Server must determine which setof permission attributes on a file or directory to use to grant a user access to a file systemobject. This process is called user authorization and is controlled through the file systemaccess-checking policy.

Note: By default, when a file system is first created by using the Control Station, there is no ACLon the root of that file system. The UNIX owner is root and is the only one with write access tothis file system. The Celerra system automatically sets the ACL permissions as FULL CONTROLfor EVERYONE on the root directory of the file systems CIFS share only after the first connectionis made to this share.

Access-checking policies only apply when the Data Movers user authentication is setto the recommended default, NT. The following table provides more information aboutaccess-checking policies.

Table 1. Celerra access-checking policies

DescriptionAccess-checkingpolicy

Access to a file or directory through NFS or UNIX authenticatedFTP is granted only if the UNIX permissions on the file or direc-tory allow it.

Access through CIFS or Windows authenticated FTP is grantedonly if the Windows permissions on the file or directory allow it.

ACL and UNIX permissions are maintained for every file anddirectory.

A change in permissions on a file system object in NFS has noimpact on permissions in CIFS and a change in permissions ona file system object in CIFS has no impact on permissions inNFS.

Native (default)

User access control of file system objects 17

Concepts

Table 1. Celerra access-checking policies (continued)


Access to a file or directory through NFS or UNIX authenticatedFTP is granted only if the UNIX and Windows permissions allowit.

Access through CIFS or Windows authenticated FTP is grantedonly if the Windows permissions allow it (the UNIX permissionsdo not have any effect).



NT

Access to a file or directory through NFS or UNIX authenticatedFTP is granted only if the UNIX permissions allow it (the Win-dows permissions do not have any effect).

Access through CIFS or Windows authenticated FTP is grantedonly if the UNIX and Windows permissions on the file or directoryallow it.



UNIX

Provides the greatest security across CIFS and NFS.

Access to a file or directory through either NFS or FTP or CIFSis granted only if the UNIX and Windows permissions on the fileor directory allow it.



SECURE


Concepts

Table 1. Celerra access-checking policies (continued)


MIXED Access to a file or directory through either NFS or FTP or CIFSis always determined by the ACL.


ACLs for files and directories are created from the protocol thatlast set or changed the permissions. For example, if an NFSclient sets or changes permissions on a file or directory, theACL is rebuilt based on the UNIX mode bits. If a CIFS clientsets or changes permissions on a file or directory, the ACL isbuilt based on the standard Windows permissions.

In all cases, the ACL determines file and directory access re-gardless of whether the client is using the NFS, CIFS or FTPprotocol.

ACL permissions are more granular than UNIX mode bits, con-sequently not all permissions set in an ACL can be translatedto UNIX mode bits. In some cases, the mode bits might showmore permissions than a user actually has. See Using MIXEDand MIXED_COMPAT on page 22 for a detailed description.

Access to a file or directory through NFS or FTP or CIFS is de-termined by which protocol (NFS or CIFS) last set or modifiedthe permissions.


If the permissions of a file or directory are set or changed froma CIFS client, then access is determined by the ACL (EXPLICITACL). UNIX mode bits are generated based on the ACL but arenot used for access checking.

If the permissions of a file or directory are set or changed froma UNIX client, then UNIX mode bits dictate access. An ACL isstill created but is not used for access checking.

ACL permissions are more granular than UNIX mode bits, con-sequently not all permissions set in an ACL can be translatedto UNIX mode bits. In some cases, the mode bits might showmore permissions than a user actually has.

MIXED_COMPAT


Concepts

Selecting an access-checking policy

Figure 2 on page 20 helps you determine which access-checking policy is best for yourenvironment.

Figure 2. Decision tree for access-checking policies

Note: Automatic synchronization refers to the translation of UNIX mode bits into ACLs whensetting permissions from an NFS client, and conversely means the translation of ACLs into UNIXmode bits on file system objects when setting permissions from a CIFS client.

The following table shows how the Celerra access policies interact with the CIFS andNFS clients to check for permissions on a file system object in a multiprotocolenvirionment.


Concepts

Table 2. Checking permissions in a multiprotocol environment

Change in one per-mission set reflect-ed in the other set?

NFS clientsCIFS clientsPermission at-tributes

Access-checkingpolicy

NoUNIX rights arechecked.

ACL is checked.Two permission at-tributes: ACL andUNIX mode bits.

Native (default)

ACL and UNIX rightsare checked.

UNIX


ACL is checked.NT


Secure

YesACL is checked. If there is no ACL, one iscreated based on the UNIX mode bits. Accessis also determined by the ACL.

NFSv4 clients can manage the ACL.

Because of automaticsynchronization, oneset of permission at-tributes is used regard-less of the protocol.

MIXED

A modification to theUNIX mode bits re-builds the ACL permis-sions but the UNIXrights are notchecked.

An ACL modificationrebuilds the UNIXmode bits but theUNIX rights are notchecked.

If the permissions ofa file or directory werelast set or changed byan NFS client, theUNIX rights arechecked and the ACLis rebuilt but is notchecked. If the permis-sions of a file or direc-tory were last set orchanged by a CIFSclient, the ACL ischecked and theUNIX rights are re-built, but are notchecked.

NFSv4 clients canmanage the ACL.

If the permissions ofa file or directory werelast set or changed bya CIFS client, the ACLis checked and theUNIX rights are re-built, but are notchecked. If the permis-sions of a file or direc-tory were last set orchanged by an NFSclient, the UNIX rightsare checked and theACL is rebuilt, but isnot checked.

NFSv4 clients canmanage the ACL.

Because of automaticsynchronization, oneset of permission at-tributes is used regard-less of the protocol.

MIXED_COMPAT


Concepts

Using MIXED and MIXED_COMPAT

UNIX and Windows handle access control in very different ways, making it difficult toset the same security on a file system object in a multiprotocol environment. CelerrasMIXED and MIXED_COMPAT policy synchronizes UNIX and Windows permissionsas closely as possible by using an algorithm that translates UNIX rights into ACL entriesand ACL entries into UNIX rights.

The MIXED and MIXED_COMPAT policies differ in the way they translate a UNIXGroup into an ACE and how they perform access checking. The MIXED policy alwaysperforms access checking against an ACL independent of the protocol accessing a filesystem object, as explained in the following example. The MIXED_COMPAT policy usesthe permissions from the protocol that last set or changed the permissions on a file systemobject.

MIXED example

FileX is assigned the mode bits of rwxrw-r-. If the ACL of FileX is modified in such a waythat user1, who is not the owner of the file, is granted read, write, and execute access to thefile, the ACL shows the file owner has read, write, and execute access to the FileX. Membersof the owner-group have read and write access, others have read access, and user1 has read,write, and execute access. However, the UNIX mode bits show rwxr-xrwx, meaning that atleast one user who is not the file owner has read, write, and execute access. Although itseems that all others have full access to FileX, only user1 has full access because ACL is theone controlling access, not the UNIX mode bits.

Automatic synchronization

When the MIXED and MIXED_COMPAT policies are enabled for a file system object,the ACL and UNIX mode bits are automatically synchronized. Changes to an ACL resultin modifications to the mode bits and changes to the mode bits reconstruct the ACL.

The following table explains how the MIXED access-checking policy translates ACLSand UNIX mode bits during synchronization.

Table 3. MIXED access-checking policy

Translating ACLS into UNIX modebits

Translating UNIX mode bits intoACLS

Translates the ACL Allow option butnot the ACL Deny option.

Creates ACL entries for File Owner,Group, and Everyone based on themode bits of Owner, Group, and Oth-er.

Builds Owner mode bits from theOwner entry, the ACE of the file or di-rectory, and the Everyone ACE.

Sets Delete or Change permissionsand Takes Ownership for the Ownerbut not for Everyone and otherGroups.


Concepts

The following table explains how the MIXED_COMPAT access-checking policy translatesWindows ACLs and UNIX mode bits during automatic synchronization

Table 4. MIXED_COMPAT access-checking policy

Translating ACLS into UNIX modebits

Translating UNIX mode bits intoACLS

Translates the ACL Allow option butnot the ACL Deny option.

Creates only two entries in the ACL:Owner and Everyone.

Builds None, Owner, and GrantedACEs into Group and Other mode bits.

Creates an Everyone ACE from theGroup mode bits because groups arenot translated with this policy.

Ignores Other mode bits and does notuse them to build the ACL.

Sets Delete or Change permissionsand takes Ownership for the FileOwner but not for the EveryoneGroup.

Mapping ACL permissions to UNIX mode bits

The following table shows how the MIXED and MIXED_COMPAT access policies mapthe ACL file and directory permissions into UNIX file and directory rights.

Note: For MIXED and MIXED_COMPAT, ensure that the Windows user default group is setbecause the Celerra Network Server uses this group to decide which UNIX primary group to assignto a file system object created through CIFS.

Table 5. Translating ACL file and directory permissions into UNIX rights

Directory permissionsFile permissionsPermissions

XWRXWR

Traverse Folder/Execute File

xxxRead Data

xxRead Attributes

xxRead Extended Attributes

xWrite Data

xAppend Data

xxWrite Attributes


Concepts

xxWrite Extended Attributes

xxDelete

xRead Permissions

xList Folders

xCreate Files

xCreate Folders

xDelete Subfolders and Files

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

Mapping UNIX mode bits to ACL permissions

The following table shows how the MIXED and MIXED_COMPAT access-checkingpolicies map UNIX mode bits into ACL permissions.

Table 6. Translating UNIX rights into an ACL

XWRPermissions

xTraverse Folder/Execute File

xxList Folder

xRead Data

xRead Attributes

xRead Extended Attributes

xCreate Files/Write Data

xCreate Folders/Append Data

xWrite Attributes

xWrite Extended Attributes

xDelete Subfolders and Files

Delete

xxxRead Permissions

Change Permissions

Take Ownership


Concepts

Inheritance rules

Table 7 on page 25 explains the inheritance rules for the NATIVE, UNIX, NT, and SECUREaccess-checking policies.

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

Table 7. NATIVE, UNIX, NT, and SECURE inheritance rules

RulesProtocol

When a CIFS client creates a file system object:

The ACL is inherited from the parent directory, if one exists.

The UNIX mode bits are determined by the umask set on the share. Use the server_ex-port command to set the umask value.

CIFS

When an NFS client creates a file system object:

The ACL is inherited from the parent directory, if one exists.

The UNIX mode bits are determined by the set for the user.

NFS v4 clients might set the mode bits or ACL or both at file or directory creation time,overriding inheritance and umask.

NFS

Table 8 on page 25 explains the inheritance rules for the MIXED and MIXED_COMPATaccess-checking policies.

Table 8. MIXED and MIXED_COMPAT inheritance rules

RulesProtocol

When a CIFS client creates a file system object, if the inheritance flag is set and theobject parent has an ACL, the file system object inherits the ACL, and the UNIX modebit permissions are created based on the ACL translation.

If the parent does not have an ACL, the UNIX permissions are set according to theumask value and an ACL is generated based on these values.

CIFS


Concepts

Table 8. MIXED and MIXED_COMPAT inheritance rules (continued)

RulesProtocol

UNIX mode bits are based on the umask value.

An ACL is created from the UNIX mode bits.

Note: NFS v4 clients might set the mode bits or ACL at file or directory creation time,overriding inheritance and umask.

NFS

Windows-style credential for UNIX users

In a multiprotocol environment, users often have both UNIX and Windows user identities;they can use either to access the data stored by the Celerra. The Windows NT credentialfeature enables the Celerra Network Server to take full account of a users Windows groupmemberships when checking an ACL for access through NFS. When a UNIX user initiatesa request for a file system object through NFS, the Celerra Network Server maps the UNIXUID to the Windows SID, and then merges the users UNIX and Windows groups togetherto generate a Windows NT credential.

After the Windows NT credential is generated, it augments the UNIX credential suppliedin the NFS RPC request for NFS access checking. The Windows NT credential provides:

Consistent permissions on a file system object independent of the protocol accessing it.

Cache to store Windows NT credentials, decreasing the access-checking process time.

Management of access to data by using ACLs regardless of the protocol clients use.

A new security.maxgroups parameter used to increase the number of UNIX groups forNFS clients from the default limit of 16 to 128.

The EMC Celerra Network Server Parameters Guide provides more detailed information.

Using the Windows NT credential feature in a multiprotocol environment can beadvantageous as it takes full account of the Windows group memberships of a user whenchecking an ACL through NFS.

Note: The Windows NT credential functionality closely resembles a Windows credential, but it doesnot support access to the Active Directory and cannot query the Active Directory database forinformation about Windows users and groups. UNIX users cannot access to nested, universal, anddomain local group information from the local computer when UNIX credentials are translated toWindows credentials.

Generating a Windows NT credential

Figure 4 on page 27 illustrates how the Celerra Network Server generates a WindowsNT credential after a UNIX client requests access to a file system object.


Concepts

Figure 4. Decision tree for generating a Windows NT credential

Determining the GID for file system objects

In a file system, every object (such as a file, directory, link, and shortcut) has an associatedowner and owner group that are identified by a UID and GID. NFS uses the UID and GIDto control access to the file system object. Since a user can be a member of many groups, theCelerra Network Server needs a way to determine the group that should be associated witha newly created file. The user primary group setting determines which GID gets assignedto the file system object.

NFS and CIFS have the concept of a primary group for a user. In NFS, the primary groupis required; however, the primary group is optional on Windows platforms and defaults tothe Domain Users group.

All file system objects (FSOs) on a Data Mover have an associated owner (identified by aUID) and group (identified by a GID). Table 9 on page 27 describes how the primary groupmapping is determined for file system objects.

Table 9. Determining the file system object GID

DescriptionProtocol

When an FSO is created from a UNIX client, the FSO GID is taken from the GID suppliedby the UNIX client (based on the primary group of the creator).

NFS

Determining the GID for file system objects 27

Concepts

Table 9. Determining the file system object GID (continued)

DescriptionProtocol

When an FSO is created from a Windows client, the GID can be determined in these ways:

(Default) The file system object GID is taken from the GID associated with the primarygroup of the creator.

The file system object GID is taken from the UNIX primary group of the user as definedin the passwd file, NIS, or Active Directory.

CIFS

Backing up and restoring file system objects

Use NDMP to back up and restore multiprotocol file systems, because network backupsthrough NFS or CIFS capture only one set of metadata on a multiprotocol file system.

Note: For an NFS backup, only the UNIX rights are backed up and restored and determine the ACLpermissions. As a result, the most complex ACEs in the ACLs might be lost during an NFS backup.

File naming

NFS and CIFS use different file naming conventions. Table 10 on page 28 explains thesedifferences.

Table 10. NFS and CIFS file naming conventions

CIFS file namesNFS file names

Not case-sensitive, but they are case-preserving.

Case-sensitive.

Does not allow a directory to have twofiles with the same name and differentcases, and identifies these names asduplicate names.

Allows a directory to hold files that havethe same names, but differ in case.

Note: When creating UID and GID names for Windows clients, Windows names (usernames, domainnames, and global group names) must be written in lowercase in the NIS, the password files, and thegroup UNIX files. You need to be careful when doing explicit user and group mapping; the CelerraNetwork Server does not recognize names like Windows.


Concepts

File locking

File locking ensures file integrity when multiple users attempt to access the same file at thesame time. File locks manage attempts to read, write, or lock a file that is in use by anotheruser.

Table 11 on page 29 describes the different ways the NFS and CIFS protocols implementfile locking features.

Table 11. File locking in multiprotocol environments

CIFS or NFSv4 environmentNFSv2 or NFSv3 environment

CIFS uses opportunistic locks (oplocks) and denymodes.The NFSv4 equivalent of oplocks are calleddelegations.

Uses read locks and exclusive (write) locks.

The CIFS and NFSv4 protocols enforces strict filelocking, as well as unlocked access to files. TheCIFS and NFSv4 locks are mandatory. When aCIFS or NFSv4 process locks a file, other users aredenied certain types of access to the file, dependingon the type of lock imposed.

A CIFS or NFSv4 client can lock a file by using:

A deny read/write access on the whole file.

A lock range on a portion of the file.

NFS locks are advisory but not mandatory. An advi-sory lock is not an enforced lock and therefore, doesnot affect read and write access to the file. However,it advises other clients that the file is already in use.

In a multiprotocol environment, a file might have locks set by CIFS and NFS users. BecauseNFSv2 and NFSv3 locks and CIFS or NFSv4 deny modes and oplocksor delegationsarenot directly equivalent, the Celerra Network Server must translate CIFS or NFSv4 denymodes and oplocks to NFSv2 and NFSv3 locks and translate NFSv2 or NFSv3 locks intoCIFS or NFSv4 deny modes and oplocks. For example:

A CIFS deny read/write mode request is translated into an NFSv2 or NFSv3 exclusiveread/write lock.

An NFSv2 or NFSv3 shared read lock is translated into a CIFS deny write mode.

To provide some control over the interaction of CIFS and NFS file locking, the CelerraNetwork Server provides three different locking policies that can be specified when mountinga file system. These file locking policies are used in a multiprotocol environment and indicatethe impact of locking behavior on NFS clients in the case of concurrent NFS and CIFS filelocking. The following table explains the differences between file locking policies.

File locking 29

Concepts

Table 12. Celerra Network Server file locking policies

rwlock3wlock2nolock1

Read/write lock: enforces CIFS orNFSv4 read and write locks for NFSv2or NFSv3 client access (most secure).

Write lock: enforces CIFS or NFSv4write locks for NFSv2 or NFSv3 clientaccess.

No locks: treats all locks as advisory forNFS (v2 or v3) clients (default setting,least secure).

Lock requests: If a CIFS or NFS clientlocks a file, no other client can lock thatfile.



Access requests: CIFS clients denying concurrent

access for read or write cannotopen files locked by NFS for exclu-sive or shared access.

NFSv2 or NFSv3 clients cannotread, write, or delete files lockedby CIFS.

Access requests: CIFS clients denying concurrent

access for write cannot open fileslocked by NFS for exclusive ac-cess.

NFSv2 or NFSv3 clients can read,but cannot write to or delete, fileslocked by CIFS or NFSv4.

Access requests: CIFS clients ignore locks set by

NFS.

NFSv2 or NFSv3 clients can readand write to files locked by CIFS orNFSv4.

Note: The Celerra Network Server enforces file locks only when it is configured to do so and whenthe client application is using locks. Some simple applications, such as Windows Notepad or Wordpad,UNIX more, and vi do not use file locking. Files created with these applications are not locked; theycan be opened and edited by another application even when a file system is mounted with wlock orrwlock.

Set the file locking policy on page 52 describes how to set locks on the file system.

Wide links

The Celerra Network Server wide links feature uses Microsoft DFS functionality to resolveUNIX absolute symbolic links for Windows clients. This is done by creating a DFS root ona CIFS share and then establishing a link on the DFS root that maps the UNIX mount pointto the Windows server:\share\path. This mapping is done through the MMC DFS tool. Itis difficult for a Windows client to open a path to a file system object when its path containsan absolute symbolic link. A Windows client requests the server to perform a function ona file system object based on a given path. Unlike Windows, a UNIX client uses a target pathrelative to its mount point. This can lead to a file system object on a remote server.

For purpose of example, assume that UNIX client has the following two file systems mounted:server1:/ufs1 mounted on /first and server2:/ufs2 mounted on /second. On ufs1, there is anabsolute symbolic directory link to /second/home. A UNIX client can easily access this link

3 NFSv2 or NFSv3 applications that do not expect lock conflicts (permission denied) on read/writeoperations might have problems.

2 NFSv2 or NFSv3 applications that do not expect lock conflicts (permission denied) on read/writeoperations might have problems.

1 Nolock is the only lock policy supported on MPFS file systems.


Concepts

from ufs1. However, as this path exists only on the UNIX client and not on the local server,a Windows client cannot follow this path.

By using wide links, Windows clients are able to access files from the same directory asUNIX clients when following an absolute symbolic link. The Celerra system does this byusing the DFS root functionality of the Data Mover. A wide link target must be on a DFSroot, which is a CIFS share or a Windows share. This share can be local or on a remote server.As many wide links as required can be created on the root share.

Wide link translation makes it easier to build and maintain a single, multiprotocol file systemnamespace that spans multiple file servers as it reduces the burden associated withmaintaining consistency between the NFS and CIFS namespace structure definitions (forexample, NFS auto mount table and DFS). Create wide links on page 55 provides proceduralinformation for creating wide links.

Distributed File System server

Microsoft Distributed File System (DFS) allows you to group shared folders located ondifferent servers into a logical DFS namespace. A DFS namespace is a virtual view of theseshared folders shown in a directory tree structure. By using DFS, you can group sharedfolders into a logical DFS namespace and make folders that are distributed across multipleservers appear to users as if they reside in one place on the network. Users can navigatethrough the namespace without needing to know server names or the actual shared foldershosting the data.

Each DFS tree structure has a root target, which is the host server running the DFS serviceand hosting the namespace. A DFS root contains DFS links that point to the shared foldersashare and any directory below iton the network. The shared folders are referred to as DFStargets.

Microsoft offers stand-alone and domain-based DFS root servers: the domain DFS root serverand the stand-alone DFS root server. The domain-based DFS server stores the DFS hierarchyin the Active Directory. The stand-alone DFS root server stores the DFS hierarchy locally.The Celerra Network Server provides the same functionality as a Windows 2000 or WindowsServer 2003 stand-alone DFS root server.

For detailed information about DFS, visit the Microsoft website at http://www.microsoft.com.Configure and administer DFS support on page 53 provides procedural information forcreating a DFS root.

Symbolic links

Symbolic links are special nodes created by UNIX clients that point to another node (a fileor directory called the target node). The target node is defined in a symbolic link node as apathname. Normally, NFS symbolic links have no meaning to Windows clients because theclient must resolve (follow) the symbolic link to its target. However, under certaincircumstances, the Celerra Network Server resolves symbolic links for Windows clients sothat these clients can access the same files and directories as UNIX clients through a symboliclink.

Distributed File System server 31

Concepts

By using symbolic links, CIFS clients can access multiple file systems on a Data Mover froma single share. This gives the appearance of one large namespace when it actually consistsof individual file systems linked together with symbolic links. After enabling the shadowfollowabsolutpath parameter, a single CIFS share that provides access to multiple file systemson a Data Mover can be created. Link file systems on page 36 provides proceduralinformation.

If the Celerra Data Mover is able to access the target on behalf of the CIFS user, the user seesthe target of the symbolic link rather than the link itself and does not know that they havefollowed a symbolic link. If the target is not accessible, the user sees the symbolic link as afile but cannot access that file.

By default, the Celerra Network Server resolves symbolic links for Windows clients when:

The target is relative to the directory in which the link itself resides. That is, the targetdoes not contain an absolute path (full pathname).

The target is within the same share as the link itself. The target does not have a pathnamethat refers upwards by using the .. component.

When a Data Mover resolves symbolic links on behalf of CIFS clients, users cannot distinguishbetween the symbolic link itself and the target of the symbolic link. Therefore, if a symboliclink refers to a directory, and a Windows user attempts to delete the symbolic link, the link andthe contents of the directory that the link references are deleted.

Do not use Microsoft Office applications on files represented by symbolic links. When a file isupdated, Microsoft Office creates the updated file in the directory containing the symbolic link,instead of the symbolic link target directory.

When the target is unreachable, a symbolic link cannot be removed through a Windows client.During the removal process, Microsoft Explorer tries to open the file, which is unreachable,and fails.

Symbolic link limitations on page 65 provides additional information.


Concepts

3Managing

The tasks to manage multiprotocol environments are:

Change the default symbolic link behavior on page 34 Link file systems on page 36 Set the access-checking policy on page 39 Migrate access_checking policy to MIXED and MIXED_COMPAT

on page 39 Manage a Windows NT credential on page 41 Use only UNIX permissions for access checking on page 46 Manage UNIX permissions from a Windows client on page 47 Manage Windows ACL from a UNIX client on page 48 Use UNIX GIDs for file system objects on page 51 Determine the GIDs on copied file system objects on page 51 Set the file locking policy on page 52 Configure and administer DFS support on page 53 Create wide links on page 55


Change the default symbolic link behavior

You can modify the default behavior of symbolic links:

Enable symbolic links with absolute paths on page 35

Enable symbolic links with target paths to parent directories on page 34

Enable symbolic links with target paths to parent directories

By default the Data Mover does not resolve symbolic links that have a pathname that refersupward using the ".." component.

Enabling the shadow followdotdot parameter so that the Data Mover follows symbolic linksupwards on behalf of Windows clients might create infinite loops in the namespace presentedto Windows clients. Applications that perform a search of the namespace have the risk of gettingstuck in an infinite loop.

Action

To enable the Data Mover to follow symbolic links with the .. component in the target pathnames, use this commandsyntax:

$ server_param -facility shadow -modify followdotdot -value 1

where:

= name of the Data Mover

Example:

To enable symbolic links with target paths to parent directories on server_2, type:

$ server_param server_2 -facility shadow -modify followdotdot -value 1

Output

server_2 : done


Managing

Enable symbolic links with absolute paths

By default, the Data Mover will not follow symbolic links that contain absolute paths (fullpathnames).

Note: When the shadow followabsolutpath parameter is enabled to follow absolute paths, the targetis interpreted by the Data Mover. The Data Mover can only resolve paths that are relative to the rootfile system on the Data Mover. If this is a Virtual Data Mover, this path must be the root of the VDM(for example, /mountpoint/directory); otherwise, a Windows client is unable to access the target.

Note: With NFS, clients read a symbolic link target path and tries to access the target by doing a locallookup on the client. NFS clients must have the same mount point as the Data Mover to access targetswith absolute paths.

Action

To enable the Data Mover to follow symbolic links when the target is an absolute path, use this command syntax:

$ server_param -facility shadow -modify followabsolutpath -value

where:

= name of the Data Mover or VDM

= Bit list

Bit 0:

0 = does not allow symbolic links that contain an absolute path

1= allows symbolic links that contain an absolute path to be followed

Bit 1:

0 = allows only absolute symbolic links owned by root (UID 0) to be followed

1= allows any absolute symbolic links to be followed

Note: Setting Bit 1 creates a potential security issue for NFS access because the NFS client can create an absolutesymbolic link to any location in the Data Mover. If Bit 1 is not set, only links owned by the root (uid 0) are followed.

Example:

To enable symbolic links when the target is an absolute path, type:

$ server_param server_2 -facility shadow -modify followabsolutpath -value 1

Output

server_2 : done

Change the default symbolic link behavior 35

Managing

Link file systems

You can link file systems together using a symbolic link:

Access symbolic links through CIFS clients on page 36

Access symbolic links through NFS clients on page 38

Access symbolic links through CIFS clients

You must have root privileges to create a symbolic link.

Perform the following steps using the Control Station and an NFS client.

ActionStep

Set the shadow followabsolutpath parameter to enable symbolic links with absolute paths.1.

Example:

To enable server_2 to follow symbolic links when the target is an absolute path, type:

$ server_param server_2 -facility shadow -modify followabsolutpath -value

1

Mount the file systems.2.

Example:

To mount ufs1 and ufs2, type:

$ server_mount server_2

server_2 :root_fs_2 on / uxfs,perm,rwroot_fs_common on /.etc_common uxfs,perm,roufs1 on /ufs1 uxfs,perm,rwufs2 on /ufs2 uxfs,perm,rw

Create a share to the top-level file system.3.

Example:

To create a share to ufs1, type:

$ server_export server_2

server_2 :export "/ufs1"share "ufs1" "/ufs1" netbios=NS700-JB1 maxusr=4294967295 umask=22


Managing

ActionStep

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

Example:

To mount ufs1 on an NFS client, type:

# mount 192.168.101.238:/ufs1 /ufs1 # mount 192.168.101.238:/ufs1 on /ufs1

type nfs (rw,addr=192.168.101.238)

Create a symbolic link to the second file system.5.

Example:

To create a symbolic link from ufs1 to ufs1, type:

# ln -s /ufs2 fslink2 # ls -l

total 8lrwxrwxrwx 1 root root 5 Jun 10 2004 fslink2 ->/ufs2drwxr-xr-x 2 root root 8192 Jun 9 12:14 lost+found

Note: Checkpoints of a linked file system do not appear under the top-level file system.You must be in thelinked file system directory to view these checkpoints.

The command ln -s /ufs2 fslink2 links fslink2 to the path /ufs2 as it applies to the Data Mover. CIFS clientsaccessing the ufs1 share can view fslink2 as one of its directories, as shown in the following illustration.

Note: NFS clients cannot access fslink2 because the client has no knowledge of its path on the Data Mover.

Link file systems 37

Managing

Access symbolic links through NFS clients

ActionStep

Export the file system on the Data Mover.1.

Example:

To export ufs2 on server_2 , type:

# server_export server_2 -o anon=0 /ufs2

Create the directory and mount the file system on the NFS client.2.

Example:

To create and mount the ufs2 directory on the NFS client, type:

# mkdir /ufs2 # mount 192.168.101.238:/ufs2 /ufs2 # cd /ufs1 # ls -l

total 8lrwxrwxrwx 1 root root 5 Jun 10 13:20 fslink2 ->/ufs2drwxr-xr-x 2 root root 8192 Jun 9 12:14 lost+found

Follow the symbolic link to the directory.3.

Example:

To create a share to ufs1, type:

# cd fslink2 # ls -l

total 32drwxr-xr-x 2 root root 8192 Jun 9 12:15 lost+found-rw-r--r-- 1 32769 32771 24064 Jun 10 09:52 test1.doc


Managing

Set the access-checking policy

User access control of file system objects on page 16 provides conceptual information aboutsecurity models and access-checking policies.

Action

To set the access-checking policy for a file system, use this command syntax:

$ server_mount -option

accesspolicy={NT|UNIX|SECURE|NATIVE|MIXED|MIXED_COMPAT}

where:


= name of the file system being mounted

= name of the mount point

Note: Always check the current access-checking policy on the file system before executing this command. The defaultpolicy is NATIVE.

Example:

To set the access-checking policy to NT for file system ufs1 on server_2, type:

$ server_mount server_2 -option accesspolicy=NT ufs1 /ufs1

Output

server_2 : done

Migrate access_checking policy to MIXED and MIXED_COMPAT

To migrate the access-checking policy to MIXED and MIXED_COMPAT, you must firstperform the following tasks:

Synchronize Windows and UNIX permissions on page 40

Check the translation status on page 41

Reset the access policy on page 40

Set the access-checking policy 39

Managing

Synchronize Windows and UNIX permissions

Note: Because the synchronization task cannot be undone, first perform a backup of the file system.Always check the access-checking policy set on the file system before and after executing the translatecommand. The file system must be mounted as MIXED or MIXED_COMPAT before executing thiscommand. If not, the command is refused. The file system to be translated must be a UXFS file systemobject mounted as read/write.

After remounting a file system object to MIXED or MIXED_COMPAT, perform the followingsteps to synchronize Windows and UNIX permissions.

explains how Windows and UNIX permissions are translated to MIXED or MIXED_COMPATfrom an NT, NATIVE, UNIX or SECURE originating policy.

Action

To synchronize Windows and UNIX permissions on the file system, use this command syntax:

$ nas_fs -translate -access_policy start -to {MIXED} -from{NT|NATIVE|UNIX|SECURE}

where:

fs_name = name of the file system

Example:

To synchronize Windows and UNIX permissions for ufs1 on server_2 and regenerate ACLs based on UNIX modes, type:

$ nas_fs -translate ufs1 access_policy start -to MIXED -from UNIX

Reset the access policy

You can remount a file system to reset the access-checking of the file system object to itsoriginating policy. This action applies the new access right policy and causes the ACLs andmode bits to become independent when first modified. ACL permissions and the UNIXmode bits remain unchanged.

Note: File systems might have permissions that are not synchronized.Synchronize Windows and UNIX permissions on page 40 provides more information.

Action

To reset the MIXED or MIXED_COMPAT access-checking policy for a file system, use this command syntax:

$ server_mount -option accesspolicy={NT|UNIX|SECURE

|NATIVE|MIXED|MIXED_COMPAT}

where:


Managing

Action



= name of the mount point, which begins with a forward slash (/)

Example:

To reset the access-checking policy to UNIX for file system ufs1 on server_2, type:

$ server_mount server_2 -option accesspolicy=UNIX ufs1 /ufs1

Output

server_2: done

Check the translation status

Action

To check the translation status of a file system, use this command syntax:

$ nas_fs -translate -access_policy status

where:

= name of the file system being translated

Example:

To check the translation status for ufs1, type:

$ nas_fs -translate ufs1 -a status

NotesOutput

If the translation failed, check if the file system ismounted as MIXED or MIXED_COMPAT.

If the translation does not complete due to system fail-ure, run the command again.

status=In progresspercent_inode_scanned=681097154093: ADMIN: 4: Commandsucceeded: acl database=/ufs1convertAccessPolicy status

Manage a Windows NT credential

The tasks to manage a Windows NT credential are:

Generate Windows NT credentials on page 42

Include UNIX groups in a Windows NT credential on page 42

Modify Windows NT credential settings on page 43

Set the Windows default domain on page 44

Migrate access_checking policy to MIXED and MIXED_COMPAT 41

Managing

Define the Windows NT credential cache on page 44

Set the time-to-live expiration stamp on page 45

Windows-style credential for UNIX users on page 26 provides conceptual information.

Generate Windows NT credentials

Action

To generate Windows NT credentials for a file system object, use this command syntax:

$ server_mount -option

accesspolicy={NT|UNIX|SECURE|NATIVE|MIXED|MIXED_COMPAT},ntcredential

where:




Note: The Windows NT credential function is for multiprotocol file systems. Use this feature only with NT, SECURE, andMIXED and MIXED_COMPAT access-checking policies.

Example:

To set the access-checking policy to NT and generate the Windows NT credential for file system ufs1 on server_2, type:

$ server_mount server_2 -option accesspolicy=NT,ntcredential ufs1 /ufs1

Output

server_2: done

Include UNIX groups in a Windows NT credential

EMC recommends setting the acl.extendExtraGid parameter if you use NT credentials. Whenthe user accesses the Celerra through CIFS, the Celerra can be configured to include theusers UNIX groups in their Windows credential. This is in addition to their Windowsgroups. The Celerra will include users UNIX groups in their Windows credential if theserver parameter cifs acl.extendExtraGid is set to 1. There is no limit to the number of groupsa Windows NT credential can contain.


Managing

Note: The acl.extendExtraGid parameter applies only in multiprotocol environments with a NetworkInformation Service (NIS) or .etc/group file on the Data Mover. The UNIX groups are retrieved fromthe UNIX name services configured on the Data Moverfor example local group file, NIS, LDAP andso onby using the username without the .domain extension.

Action

To include users UNIX group in their Windows NT credential, use this command syntax:

$ server_param -facility cifs -modify acl.extendExtraGID -value

where:


= 1 (to enable mapping) or 0 (to disable mapping)

Example:

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

Output

server_2: done

Modify Windows NT credential settings

For Windows 2000, access to a trusted domain requires setting additional rights for the CIFSserver retrieving a list of groups to which a user belongs. This server must be granted theList contents and Read all properties rights.

Perform the following steps to set rights for the CIFS server.

ActionStep

Use the Microsoft AD User and Computer MMC in expert mode.1.

From the menu, select View Advanced features.2.

Right-click the domain name, and select Security Advanced.3.

Grant rights:

For a Data Mover NetBIOS name: Everyone or Anonymous

For a Data Mover computer name: serverDomain\Domain Computers

4.

Manage a Windows NT credential 43

Managing

Set the Windows default domain

The default Windows domain name is used if several different SIDs match the user UNIXUID, or the UID-to-name reverse mapping returns an ambiguous username (no domain).

The nfs NTcred.winDomain parameter specifies the Data Mover default Windows NetBIOSdomain name to be used for NFS users accessing a file system where the ntcredential optionhas been used.

Note: This parameter does not apply to NFSv4, but can be used with NFSv2 and NFSv3.

Action

To set the Windows default domain, use this command syntax:

$ server_param -facility nfs -modify NTcred.winDomain -value

where:


= a valid NetBIOS domain name

Note: Parameter and facility names are case-sensitive.

Example:

To set the Windows default domain to nasdocs.emc.com, type:

$ server_param server_2 -facility nfs -modify NTcred.winDomain -value nasdocs.emc.com

Output

server_2: done

Define the Windows NT credential cache

The NT credential cache is a size-limited cache containing Windows NT credentials and anyUID entries that could not be mapped to SIDs.

Note: If the CIFS service is stopped, connected users can continue to use the cache for 20 minutes.When CIFS is restarted, all the failed mapped entries are removed from the cache.

Action

To set the Windows NT credential cache size, use this command syntax:

$ server_param -facility nfs -modify NTcred.size -value


Managing

Action

where:


= the maximum number of entries in the cache. The default is 1009.

Example:

To set the Windows NT credential cache size to 1000, type:

$ server_param server_2 -facility nfs -modify NTcred.size -value 1000

Output

server_2: done

Set the time-to-live expiration stamp

Each time entry has a time-to-live expiration stamp.

Note: Parameter and facility names are case-sensitive. This parameter does not apply to NFSv4, butcan be used with NFSv2 and v3.

Action

To set the time-to-live expiration stamp of the Windows NT entry in the NT credential cache size, use this command syntax:

$ server_param -facility nfs -modify NTcred.TTL -value

where:


= the number of minutes. The default is 20 minutes.

Example:

To set the time-to-live expiration stamp of the Windows NT credential to 30 minutes, type: $ server_param server_2-facility nfs -modify NTcred.TTL -value 30

Output

server_2: done

Manage a Windows NT credential 45

Managing

Use only UNIX permissions for access checking

User access control of file system objects on page 16 provides conceptual information.

Note: Setting the cifs acl.unixCheckAcl value to 0 (zero) alters the behavior of the UNIX file systemaccess policy so that only the UNIX mode bits on directories and files are used to determine user accessto filesregardless of the protocol they use for accessing the file system. The file system still storesany ACL set, but it does not effect user access rights.

Note: When you use the acl.unixCheckAcl parameter, you might also consider setting bit 1 of the serverparameter cifs acl.extacl value to 2. Doing so exposes the UNIX mode bits on directories and files asadditional ACEs in the ACLs of directories and files.Manage UNIX permissions from a Windows client on page 47 provides procedural information forthis task.

Action

To specify that only UNIX permissions are checked when the file system access policy is set to UNIX, use this commandsyntax:

$ server_param -facility cifs -modify acl.unixCheckAcl

-value

where:


= 0 to dismiss ACL checking; 1 to enforce ACL checking

Note: Parameter and facility names are case-sensitive.The cifs acl.unixCheckAcl parameter affects only those file systemson a Data Mover that are configured to use the UNIX access policy.

Example:

To ensure that only UNIX permissions are checked when the file system access policy is set to UNIX, type:

$ server_param server_2 -facility cifs -modify aclunixCheckAcl -value 0


Managing

Manage UNIX permissions from a Windows client

Action

To enable a specific capability for ACL management, use this command syntax:

$ server_param -facility cifs -modify acl.extacl -value

where:


= The bit list that enables special capabilities for access control list management.

The bit list consists of seven binary bits (0 to 6). Any combination of bits is allowed. Each bit is 1 when set, otherwise 0.

Bit 0 set (0000001 or +1) = UNIX metadata associated with files and directories is presented to CIFS backup client.

Bit 1 set (0000010 or +2) = Windows clients can view and modify UNIX permissions.

Bit 2 set (0000100 or +4) = CIFS network backup applications can backup and restore UNIX file and directory securityattributes.

Bit 3 set (0001000 or +8) = CIFS network backup applications can backup and restore UNIX symbolic links.

Bit 4 set (0010000 or +16) = CIFS network backup applications can backup and restore all three names of files and direc-tories.

Bit 5 set (0100000 or +32) = Allows NFS v2 and v3 clients to view and modify ACLs by using the emcsetsd client tool.

Bit 6 set (1000000 or +64) = Modifies the behavior of bit 1. UNIX rights applied are the granted rights less the denied rightsby the discretionary ACL.

Example:

To enable Windows users to view and modify UNIX permissions, type:

$ server_param server_2 -facility cifs -modify acl.extacl -value 2

Note: To use emcsetsd to view and modify ACLs, you must first enable the emcsetsd tool.

Examples:

To use emcsetsd or emcgetsd tools from a UNIX client, you must set bit 5, type:


To use emcsetsd and manage UNIX permissions from Windows, type:


Manage UNIX permissions from a Windows client 47

Managing

Manage Windows ACL from a UNIX client

Use the emcgetsd and emcsetsd tools to perform the following tasks:

Display the security descriptor on page 49

View access rights on page 51

Note: Before you can use the emcsetsd tool, you must first enable it by using the cifs acl.extacl parameter.Manage UNIX permissions from a Windows client on page 47 provides procedural information forthis task.

Appendix A provides detailed information about the emcgetsd and emcsetsd tools.


Managing

Display security descriptor

If a file or directory has SIDs in an ACL belonging to more than one domain, the output liststhe users in the format of domain/user or domain/group without the -D option being specifiedin the emcgetsd command.

Action

To display the security descriptor of a file system by using the verbose option, use this command syntax:

# ./emcgetsd -v

where:

= path of the file or directory on the UNIX client

Example:

To display the security descriptor of file system /fs2000A/apache/logs by using the verbose option, type:

# ./emcgetsd -v /fs2000A/apache/logs

Manage Windows ACL from a UNIX client 49

Managing

Output

Dump of /fs2000A/apache/logs Security Descriptor------------------------------------------------Owner uid=677 froGroup gid=2765 mediaDACLDENY Gid=10 soft64Access R-X--- 0x1200a9READ_DATAREAD_EAEXECUTEREAD_ATTRIBUTESREAD_CONTROLFlags 0x3OBJECT_INHERITCONTAINER_INHERITGRANT Uid=698 acl1Access RWXPDO 0x1f01ffREAD_DATAWRITE_DATAAPPEND_DATAREAD_EAWRITE_EAEXECUTEDELETE_CHILDREAD_ATTRIBUTESWRITE_ATTRIBUTESDELETEREAD_CONTROLWRITE_DACWRITE_OWNERFlags 0x1fOBJECT_INHERITCONTAINER_INHERITNO_PROPAGATE_INHERITINHERIT_ONLYINHERITED_ACEGRANT EveryoneAccess R-X--- 0x1200a9READ_DATAREAD_EAEXECUTE READ_ATTRIBUTESREAD_CONTROLFlags 0x3OBJECT_INHERITCONTAINER_INHERITSACLNone


Managing

View access rights

The emcgetsd tool allows you to view ACLs on a file or directory from a UNIX client orControl Station.

Action

To display the access rights of a user currently logged in from a UNIX client, use this command syntax:

# ./emcgetsd -a

where:

= path of the file or directory on the UNIX client

Example:

# ./emcgetsd -a /fred/test1/TestDir

Use UNIX GIDs for file system objects

The cifs acl.useUnixGid parameter controls whether the Celerra Network Server obtains anFSOs GID from a users primary group or from the users GID stored in the passwd file,NIS, or Active Directory.

Action

To set the GID mapping for FSOs created on a Windows client to the Windows users GID stored in the passwd file, NIS,or Active Directory, use this command syntax:

$ server_param -facility -modify acl.useUnixGid -value

where:


= value of the specified parameter

Examples:

To set the GID mapping for file system objects created on a Windows client to the Windows users GID, type:

$ server_param server_2 -facility -modify acl.UnixGid -value 1

Determine the GIDs on copied file system objects

Typically, when a Windows user copies a file system object (FSO) by using a tool such asWindows Explorer, the ownership of the FSO is assigned to the user who performed thecopy. The Celerra Network Server also maintains GIDs on FSOs; a GID must be applied tothe copied FSO.

Manage Windows ACL from a UNIX client 51

Managing

Action

To change the source of the GID for the copied FSO, that is to determine that the primary group is derived from the sourcespecified by the acl.useUnixGID, use this command syntax:

$ server_param -facility cifs -modify acl.takegroupship -value

1

where:


Example:

To determine that the primary group is derived from the source specified by the acl.useUnixGID, type:

$ server_param server_2 -facility cifs -modify acl.takegroupship -value 1

Set the file locking policy

When mounting a file system, the policy to control the interaction of CIFS and NFS lockingcan be specified.

The file locking option you choose depends on your business requirements and whetherthe network environment is CIFS only or a multiprotocol environment. File locking on page29 provides more information about file locking policies in a multiprotocol environment.

Action

To specify file system locking, use this command syntax:

$ server_mount -option [nolock|wlock|rwlock]

where:




Example:

To mount the file system ufs1 with a read/write lock, type:

$ server_mount server_2 -option rwlock ufs1 /ufs1

Output

server_2 : done


Managing

Configure and administer DFS support

Before you beginComplete the following tasks before configuring a DFS root on a CIFS share. ConfiguringCIFS on Celerra provides detailed instructions for 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.

3. On the CIFS server, configure a file system share on which to create the DFS root.

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

Number of DFS rootsShare typeDFS provided with

SingleLocalWindows 2000

MultipleThis is the recommended option as itcan manage multiple DFS roots on thesame CIFS server.

GlobalWindows 2003Windows XP

To create a DFS root on a CIFS share, do one of the following:

Create a DFS root using dfsutil.exe on page 53

Create a stand-alone DFS root using DFS MMC on page 54

Create a DFS root using dfsutil.exe

Note: If you intend to use a CIFS server as a stand-alone DFS server only (no domain structure), youmust use the dfsutil.exe to create the DFS root.

Note: You can use the optional flag to work with the API instead of the Windows Registry.

When the DFS is queried on the network by executing the dfsutil /siteinfo:command that comes with Microsoft Windows 2000 support tools, the client connects to thesrvsvc pipe and issues a NetrDfsManager ReportSiteInfo command. Celerra then returns a DCERPC Fault of 0x1c010002 or Range Error. To avoid this error, use the Microsoft Windows Server2003 dfsutil /sitename: command.

Configure and administer DFS support 53

Managing

Action

To create a DFS root on a global share in a Windows 2003 environment, use this command syntax:

C: dfsutil /AddstdRoot /Server:DM2-ANA0-1-SA /Share:wl_root-1

Output

Microsoft(R) Windows(TM) Dfs Utility Version 4.0Copyright (C) Microsoft Corporation 1991-2001. All Rights Reserved.Indicates that DfsUtil command completed successfully.

Create a stand-alone DFS root using DFS MMC

Use the New Root Wizard to create a stand-alone DFS root on the CIFS share.

ActionStep

Start the New Root Wizard tool from DFS MMC. Click Next on the Welcome screen to begin.1.

On the Host Server dialog box, type the name CIFS server on the Data Mover that will host the DFS rootand then click Next.

2.

On the Root Type dialog box, select Stand-alone root, and then click Next.3.

The Root Name dialog box displays the UNC path to the root and the share.

Type a unique name for the DFS root. Optionally, add a comment if you want to further describe this DFSroot. Click Next.

4.

Browse to a folder that you want to share as part of the DFS environment. Select the folder and click Next.5.

You can add additional shares to the DFS root at any time after the initial configuration.

Click Finish to complete the DFS New Root installation wizard.6.

Disable DFS support

ActionStep

Open the Registry editor of your choice and locate the following registry key:1.

HKEY_LOCAL_MACHINE\SOFTWARE\EMC\DFS\Enable

Set the registry key to zero on the Data Mover.2.

Stop and restart the CIFS service.

After starting the CIFS service, DFS support is enabled by default.

3.


Managing

Create wide links

The following task illustrates how to create two wide links to direct a Windows client to thefs_wslink-1\user1 directory on the local Data Mover and the fs_wlink-29\user1 directoryon the remote Data Mover. After the two wide links are created, the user 1 directory displaysthese symbolic links as directories in Windows instead of files, as previously shown.

For purpose of illustration, the DFS root name used throughout the procedure isDM2-ANA0-1-SA.

You can configure a wide link on a per Virtual Data Mover (VDM) basis. This enables aWindows client to be directed to as many different directory locations as needed.

Note: This task assumes that DFS support is enabled (by default) and that the DFS roots are created.Distributed File System server on page 31 provides conceptual information.

ActionStep

Start the MMC Distributed File System tool. From the Action dialog box, select Show Root.1.

In the Show Root dialog box, type the NetBIOS name of the CIFS server used as the DFS root, on which awide link is to be created. Then click OK.

2.

The system displays the DFS roots for DM2-ANA0-1-SA.

Select the DFS root on which a wide link is to be created.

3.

Create wide links 55

Managing

ActionStep

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

In the New Link dialog box, type the link name and path to target, which must be the same in Windows andUNIX and then click OK.

5.

Note: The UNIX name of each component must be the M256 name in Windows, as is shown in the followingillustration.

This example shows how to create the first wide link, wlink-1\user1 to user 1 on wlink-1 on the local DataMover.

Create the second link to user1 on the remote Data Mover by repeating step 5; type the link name and pathto target.

6.


Managing

ActionStep

Set the CIFS server and the DFS root in the Windows Registry:7.

1. Set the CIFS server and CIFS share by 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 a global share is used, only CIFS sharename is typed.

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"

2. Stop the CIFS service.

3. Restart the CIFS service.

If the Registry is updated with a share name that is not in DFS, errors similar to the following appear inserver_log:

SMB: 3: Widelink:\\Global\w1_root-1 is not in DFSSMB: 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 appearon 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.

Create wide links 57

Managing

ActionStep

After setting the Registry key, symbolic links appear as directories in Windows, enabling users to read thecontents 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 102Volume Serial Number is 0000-0014Directory of \\dm2-ana0-1-sa\wl_root-1\user1\user1_on_fs_wlink-1

02/02/2005 11:07 AM .02/02/2005 11:56 AM ..02/01/2005 07:08 PM 0 user1_NFS_file02/02/2005 10:27 AM CIFS-user

1 File(s) 0 bytes3 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 102Volume Serial Number is 0000-0014Directory of \\dm2-ana0-1-sa\wl_root-1\user1\user1_on_fs_wlink-29

02/02/2005 05:11 PM .02/01/2005 05:17 PM ..02/02/2005 05:11 PM 0 NFS_user1_wlink-291 File(s) 0 bytes2 Dir(s) 52,867,268,608 bytes free


Managing

4Troubleshooting

As part of an effort to continuously improve and enhance the performanceand capabilities of its product lines, EMC periodically releases new versionsof its hardware and software. Therefore, some functions described in thisdocument may not be sup

Documents

Managing Celerra for a Multiprotocol Environment 5.6.47 A03