you should look at the files in question and see what is set for SIDs on them.  Perhaps these are local sids to the original server and the users/groups were not copied over to the VNX first.

Many apologies for letting so much time go by.  An issue came up that caused me to put my migration on hold.

It seems that correcting the 1307 error also corrects the 1308 error.  For the most part, I have been able to isolate orphaned SIDs on files or folders and then take ownership of them.  Last night I moved on to another share and seem to have quite a few 1308 errors but no 1307.  I'll have to figure out what's going on.  There are also a lot of 1337 errors which are:  "The security ID structure is invalid."  Why can't these errors be a little more clear?

Error codes returned by EMCopy are standard Windows error codes

You can run "net helpmsg 1308" from Windows command line to get more details

Those codes correspond to unknown Sids in either owner, group or ACL of the object. Usually Sid is unknown because AD user was deleted or AD server is slow to respond (less likely)

Claude

Thanks Vince!

We ended up buying Secure Copy by ScriptLogic.  It works flawlessly.  I simply didn't have the time to comb through the logs and try to figure out what was working and what wasn't.

I'm sure your post will go a long way in helping others.

Thanks again!!

Hi revcall, I'm guessing this issue has been resolved for you, but I wanted to post a reply here with our experience in case it can help somebody else.

We were receiving a number of 1308 errors when attempting an EMCopy.  After looking at the permissions for the affected files and folders, we didn't see anything wrong.  Nothing was referring to a local user or group; only domain accounts.

I downloaded a utility from Microsoft called SubInACL (found here: http://www.microsoft.com/en-us/download/details.aspx?id=23510) and ran it against some of the files in question.  I received output like this:

E:\>SubInACL.exe /file E:\Staff\vince.valenti\docs
==================================
+File E:\Staff\vince.valenti\docs
==================================
/control=0x400 SE_DACL_AUTO_INHERITED-0x0400
/owner             =bend\vince.valenti
/primary group     =S-1-5-21-2479175398-2769753764-3671669682-513
/audit ace count   =0
/perm. ace count   =4

   
Elapsed Time: 00 00:00:00
Done:        1, Modified        0, Failed        0, Syntax errors        0
Last Done  : E:\Staff\vince.valenti\docs

Notice the primary group entry.  As far as I can tell, this is not visible anywhere from within the Windows GUI, and it's set to an unresolvable SID.

I used a command like this to update the primary group:

E:\>SubInACL.exe /file E:\Staff\vince.valenti\docs /setprimarygroup="bend\domain users"

After doing this, EMCopy worked without a hitch.

SubInACL is incredibly powerful.  I used a command like this to search for that old SID and replace it with domain users:

E:\>SubInACL.exe /applyonly=group /subdirectories E:\Staff\ /replace=S-1-5-21-2479175398-2769753764-3671669682-513="bend\domain users"

Anyway, I hadn't seen mention of the primary group entry in the security descriptor, so I wanted to document my findings here.  Hopefully this will help somebody in the future.

love Secure Copy, it used to be affordable when it was still SmallWonders software but then ScriptLogic bought that them and $$$ became ridiculous for what it does.

Good info – thanks for the feedback

Thanks for the info... worked perfectly.