take a look at the server_log

I guess that its not related to user mapping directly but rather the fact that by default the Celerra will only store CIFS ownership and ACLs for SID's that it can verify with the domain controller.

If you have orphaned SIDs (users were already deleted on the domain controller) you need to either:

- clean them up before migration

- change the cifs acl.mappingErrorAction parameter

It might also happen if you try to use localgroups that arent known on the Celerra.

Just search for "1308" in the knowledgebase

I would also suggest to use lgdup and emcopy and make sure your migration account has backup operator privileges

Rainer

Hi Rainer,

the server log reports only DNS errors and exactly as follows (just last four rows but they repeat in the log):

2011-07-09 19:06:49: LIB: 3: dns_updateMessage: gss_init_sec_context failed for 
target DNS@ELBERT.jeppesen.com
2011-07-09 19:06:49: LIB: 3: dns_updateMessage: GSS-API major error: Miscellaneous 
failure
2011-07-09 19:06:49: LIB: 3: dns_updateMessage: GSS-API minor error: Server not 
found in Kerberos database
2011-07-09 19:06:49: LIB: 3: DNS update ERROR: Primary name server not found while 
registering mitfs02.corp.gds.jeppesen.com

would you so kind to explain better waht do you mean with "by default the Celerra will only store CIFS ownership and ACLs for SID's that it can verify with the domain controller"?

The value of the cifs acl.mappingErrorAction parameter is equal to 0 both default and current.

I used lgdup as follows:

C:\>lgdup -r -s -l c:\lgdup_log.txt  \\entmitdc1  \\mitfs02

LGDUP 02.02

        Copyright (C) 2010, All Rights Reserved,

        by EMC Corporation, Hopkinton MA.

*****************************************************************************

LGDUP source:ENTMITDC1            target:MITFS02

Elapsed time: hours: 00, mins: 00, secs: 19

  - No local user duplicated.

  - 229 local group(s) have been fully duplicated.

  - 27 local group duplication ERROR(S).

  - 7 privilege(s) have been successfully duplicated.

  - 2 privilege duplication ERROR(S).

    Log file: c:\lgdup_log.txt

*****************************************************************************

NOTE: Only members of the Administrators or Account Operators local group

      on both source and target servers can successfully execute this tool.

      You also must grant the "Generate security audits" and the

      "Manage Auditing and security log" privileges to duplicate

      successfully all the privileges.

Parameter:

cifs acl.FailOnSDRestoreError

Values:

0, 1, or 2

Default: 1

Description:

Determines what to do when a mapping error occurs

during a security descriptor restore or a cifs update

setacl command. During a restore process

from a backup tool or regular migration tool such as

emcopy, the file must be opened with the backup bit

option that requires at least backup operator rights.

0 = No error is returned, wrong ACEs are discarded,

and a wrong owner or primary group of the node is

replaced by the current user ID (user performing the

restore).

1 = Error is returned, wrong ACEs are discarded, and

a wrong owner or primary group of the node is replaced

by one of the connected users.

2 = Error is returned and the security descriptor is rejected,

but the work has been done in the way described.

Parameter:

cifs acl.mappingErrorAction

Values:

0 - 15

Default: 0

Description:

Defines the rules for unknown mapping between security,

user, and group identifiers (SID/UID/GID) on ACL settings.

Two kinds of errors might occur:

◆ The SID set in the ACL is unknown to the domain

controllers being used.

◆ The username is not yet mapped to a UID/GID.

The bit list consists of four binary bits (bits 0 through

3, right to left). Each bit is 1 when set; otherwise 0.

Bit 0 (0001 or +1): Store unknown SID.

Bit 1 (0010 or +2): Store SID with no UNIX mapping.

Bit 2 (0100 or +4): Enable debug traces.

Bit 3 (1000 or +8): Do lookup only in cache (secmap

or global SID cache or per connection SID cache).

Refer to the cifs facility acl.retryAuthSid parameter.

Hi Fabio,

for each SID used (either as the owner of a file/dir or because its used in an ACL) the Celerra will try to resolve that SID to a Windows user name by asking the authorative sources (local users/groups database for local or Windows Active Domain controller for domain SIDs).

If it cannot figure out the Windows user name for a SID the default setting is to NOT allow storing that file.

That is typically the case when users have been deleted from the AD but their SID is still used on some files.

Thats why some companies dont delete users - they rather disable and rename them.

See the Parameters guide

Also take a look at the Using EMC Utilities for the CIFS Environment from Powerlink where lgdup is explained.

You should be able to identify the file where it fails from your robocopy log file - then take a look at its owner and ACLs.

Most likely its an unresolvable SID.

If that is the case you have two choices:

- cleanup the SIDs before migrating

- configure the params to allow storing unrevolvable

Also revisit the errors in your lgdup. They might be meaningless or not depending on whether any of these failed groups are used.

Rainer

If you do want to go ahead and store unrevolvable SIDs

From Knowledgebase (Primus) emc46968

In addition to the above attributes, the following parameters can be set on the Data Mover, but requires a system reboot.  Additionally, using the following parameters can degrade User access performance since the Data Mover will attempt to resolve unknown SIDs whenever files are accessed that contain invalid or unresolved SIDs.  If the data being migrated is known to contain orphaned SIDs (i.e., deleted User or Group accounts), it is suggested that the Source data be cleansed of these SIDs prior to the migration.

Basic parameters to allow for migration of data containing unknown SIDs

• param  cifs  acl.mappingErrorAction=3
  
• param  cifs  acl.retryAuthSid=600
  
• param  cifs  acl.FailOnSDRestoreError=0
  
  Changing Parameters from command line:
  
  # server_param server_2 -facility cifs -modify acl.mappingErrorAction -value 3
  
  Note:  This parameter defines rules for unknown mappings between SID, UID, GID on ACL setting, either because DC does not know SID or the username is not yet mapped to UID/GID.
  
  Bit 0 = store unknown SID
  Bit 1 = store SID without UNIX GID/UID mapping
  Bit 2 = enable debug traces
  Bit 3 = turning on bits 0 and 1
  
  # server_param server_2 -facility cifs -modify acl.retryAuthSid -value 600
  
  Note:  This parameter sets the timeout value of 600 seconds between authentication retries for unknown SIDs.
  
  # server_param server_2 -facility cifs -modify acl.FailOnSDRestoreError -value 0
  
  Note:  This parameter suppresses any errors resulting from unresolved ACLs during migration of files to Celerra, migrating all resolvable SIDs properly and placing unresolved SIDs in the delayed SID state.  Without this setting, errors will be returned when copying files with unresolvable SIDs, resulting in copying of files with default Everyone Full Control applied.
  

Hi Rainer,

why the folders are successfully copied while not the files? The owner of the files is the local group Administrators of the source box.

The Robocopy script is able to duplicate the Security settings exactly as they are in Windows.

I got the same error message both folders and files, anyway the folders are copied and the files not.

Hey Rainer,

I simply modified the acl.mappingErrorAction param to 1 w/o reboot and the script works properly!! (Do I need anyway to reboot?)

Let me examine closely tomorrow if everything is going well so that I can give you the best feedback.

thanks very much

Fabio.

Hi,

these 3 params does not require a DM reboot :

$ server_param server_2 -f cifs -i acl.FailOnSDRestoreError | grep change_effective
change_effective        = immediate
$ server_param server_2 -f cifs -i acl.retryAuthSid | grep change_effective
change_effective        = immediate
$ server_param server_2 -f cifs -i acl.mappingErrorAction | grep change_effective
change_effective        = immediate

Gustavo Barreto.

Be careful though and check your ALCs

You did have some errors in the lgdup

If not done properly you could create ACL's with the "old" localgroup SIDs that dont work for the "new" localgroups

emcopy with the correct switch uses the localgroup name and not the SID to do this - but only if the lgdup worked properly

I dont know if robocopy can do this

see http://support.microsoft.com/kb/250267/en-us

Rainer

I dont know how robocopy reacts to the error we sent - it might do differently for files than for directories

At EMC we typically use emcopy instead of robocopy