Cifs server cannot resolve SID's?

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.

Thanks!

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

Claude

Thank you Bergec

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?

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

Thanks!

SIDs for local users/groups or domain ?

Check which ones they are – lookup their names on the src

Check if the list of localgroups on the dst is at least a subset of the localgroups on the src

What lgdup does is that it reads the source CIFS servers local grousps and it creates local groups with the same name but different SID on the destination.

Emcopy then (for localgroups) translates the SIDs in owner and ACLs – i.e. it gets the source’s SID, looks up the name, looks us the new SID for the dest and uses that.

If for some reason the SID was already unresolvable on the src or the localgroup couldn’t be created on the dst you would still get unresolvable SIDs

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?

I assume the names of LG are the same on src and dst and that there are no unknown SIDs on src

Have you tried with /secfix in cas files already existed on destination?

Claude

Have you tried with /secfix ?

Claude

I appreciate everyone’s help with this…Claude your assumption is correct.  The LGs are the same on src and dst and there are no unknown SIDs on the src.  I tried the /secfix and that did not work - there are no files on the dst (as I delete files on the dst during each copy) and after each copy I still have an unresolved SID.  This unresolved SID is the src local group.

Just so I understand, the emcopy /lg switch is supposed to translate src local groups to dst local groups, so that the dst local group is used resulting in no unresolved SIDs on the dst.  Correct?

Now I could be making this up, but so far all talk has been about local groups.  Is it possible that the unresolved SID belongs to a local user?  Concept is the same as Rainer and Claude noted but for local users.  If not, then are there any notable error messages in the copy logs?

Speaking on behalf of an environment that has local users to also migrate, LGDUP can be used to create/replace/append the same local user database by passing the -u flag.  Then during the data copy via EMCOPY, just as you pass /lg to translate any reference of the src local groups' SID in the owner and ACL's of the files/folders but to the SID of the same named local group on the tgt, you do the same for local users via the /lu flag.

It is also important to note that when migrating local users via LGDUP, the password is not copied and needs to be changed manually.  Just a reminder.

Run a "server_cifssupport server_2 -secmap -list -sid SID" on the source and find the secname... then do a "server_cifssupport serrver_2 -secmap -list |grep SECNAME".  If it finds the group/user but has a different SID you've need to reapply permissions or change the SID in the usermapper database...

Usually when i've done things like this my first step is to export the usermapper db from the target (server_usermapper server_2 -Export -user ) then disable the usermapper (server_usermapper server_2 -disable) then import with -Import...  You can still do that if the target isn't in use yet..