I am replicating a CIFS file system between a celerra and vnxe using replicator. The vnxe does not support vdm's so I had to create a new CIFS server on the vnxe and use lgdup & sharedup to copy local groups, shares and acls - basically the source_celerra CIFS config. Both CIFS servers are connected to the same AD domain.
After executing lgdup - "lgdup.exe -v -l lgdup.log \\source_celerra \\target_vnxe" and sharedup - "sharedup.exe \\source_celerra \\target_vnxe ALL /SD /R" I decided to check some of the share permissions on the target. When I select the target CIFS server and view security permissions I see SID's that cannot be resolved to a user or group i.e. S-1-5-21-819283928...The source celerra does not have any local users only domain users.
So from a replication perspective, if replicator is handing data and NTFS permissions, and sharedup is handing shares and acls, I should not see SID’s that cannot be resolved to a user or group, correct? Again, both CIFS servers belong to the same domain and no local users are being used.
Are you sure it is not your client ?
I think (not sure) that if you are displaying CIFS file security from a Windows client the VNX sends the SID and the client does the resolution to a Windows name
The unresolvable SID's on the target folders belong to local groups. I think they are showing up as unresolvable because the local groups were not present on the target file server prior to starting replicator. (I used lgdup after the replication was synced with the target)
I will restart replicator now that the local groups are on the target, to see if that resolves the unresolvable SID issue.
If using Replicator to migrate data, then the ACLs will contain same SIDs as on the source
When using LGdup to copy the local groups, they will get a new SID on destination (same as if you manually created those LG), then when looking at ACLs you will still see unresolved SIDs
If you copy files using EMCopy or Robocopy (file based utilities) and use a switch to specify that you have local groups (it’s /LG with EMCopy) then the program will “translate” ACEs so that they apply to the local group name on the target and in that case you should no longer see unresolved SIDs
Thank you Bergec for this explanation - very helpful.
So I should not use replicator for the replication as this will always produce unresolved SIDs? as there is no "translate" option when copying NTFS permissions? The source file server has over 300 local groups that I need to move to the target. Not sure if this can be resolved with replicator?
IP Replicator is block based, so it has no way to translate SIDs
SIDs for local groups are local to the CIFS server and as you said there are no VDMs on VNXe
You could as well take the opportunity of this migration to get rid of those LG and recreate permissions using groups from the domain (the LGs were probably created when the CIFS server was a member of an NT4 domain)
I moved the source local groups to the target using lgdup, and I included the /lg switch in my emcopy command to "translate” ACEs so that they apply to the local group name on the target. I still see unresolved SIDs. Any ideas?
Here is the emcopy command:
emcopy.exe \\10.10.10.1\dir\ \\10.10.10.2\dir\ *.* /o /lg /s /c /r:1 /f /sdd /log+:C:\EMCopy\log1.txt
SIDs for local users/groups - The unresolvable SIDs that I see belongs to local groups from the source file server.
I thought by copying the local groups databse and using the /lg switch with emcopy would fix this?