you dont have access based enumeration enabled on target share?

Sent from my Verizon Wireless 4G LTE DROID

emcabe /g /t /s

I haven't enabled any, but where can we check if that is enabled?

Christopher is right, the /l switch will not copy files

Also, if you specify /r:0 /w:0 then EMCopy will default to /r:100 and /w:30 so you should use something like /r:3 /w:2

Note also that EMCopy 4.15 is now available from support.emc.com:

https://support.emc.com/products/12781_VNX-Series/Tools

Here are the latest enhancements:

04.15:  - Fixed a copy iconsistency when source reports inconsistency in file size.  Copied file is a non

          empty file without content when source presents a non empty file as empty when the file is opened

          in backup mode.

        - added option /hda option that activates the homedir migration mode. In that mode security

          information for any containers or files are derived from the target dir if it exists or from the

          target parent dir. is considered as the creator owner of any objects.

        - Added option check mode : /cm

          bin mode forces emcopy to compare source and destination file after the copy. Usage of this option

          reduces the overall performance of the migration. In differential mode, option /d, content of file

          that should be identical (same date same size) are compared.

          md5 mode forces emcopy to compute a md5 sum on the source file during its transfer. After the copy

          a md5 sum is computed on the target file and compared to the md5 sum of the source file.

        - Fixed display of unexpected message in the initialization phase, ERROR (1332), when the target is a

          standalone server.

        - Fixed bad detection of non-existent target share when the target path is given as an UNC path.

Claude

Christopher,

Thanks for pointing that out, now I remember this all happened after I added the switch /l

Also this is mentioned in logs as:

Copy engine Statistics : results should be like this

====================================================

I don't know how I missed finding this   I was only looking at the stats below that and assumed it copied the data.

It worked like a charm after I removed the switch /l.

Thanks

thanks dynamox for bringing up this one, I have never used emcabe before, thing to keep in mind while troubleshooting any in future.

Anyway it is not enabled on the shares. 

dynamox wrote: emcabe /g /t /s

Also the the issue with security ACLs not being copied before is resolved now.

The difference is that I was running emcopy from my local workstation before, and now I ran from  a management server.

Both of these are in a different domain groups and might have different group policies, so I think this caused the issue.

I am not sure what policy/rights are actually required for the machine I am executing from? I have to take a look.

The output of copy engine statistics from log before when the ACLs are not copied:

Copy engine Statistics

======================

File(s) copied                            : 10

File(s) recovered                         : 0

Directory(ies) created                    : 2

Security Descriptor Setting(s) failed     : 13 !

Amount of copied byte(s)                  : 256 KB (262 221 Byte(s))

Estimated copy bitrate                    : 1924.271 KB/s

Global copy duration                      : 0.133

The output now when the ACLs are also taken care:

Copy engine Statistics

======================

File(s) copied                            : 11

File(s) recovered                         : 0

Directory(ies) created                    : 2

Security Descriptor Setting(s) done:      : 14

Amount of copied byte(s)                  : 268 KB (274 861 Byte(s))

Estimated copy bitrate                    : 3449.298 KB/s

Global copy duration                      : 0.078

The switches that I used is:

C:\>emcopy_v4.14.exe \\server1\testing \\server2\testing /s /o /c /a /d /lg /f /secforce /preservesidh /r:0 /w:0 /th 40 /log+:c:\emclog2.txt

Thanks for the help guys.

good, i have seen this happen before and customer was confused how that could happened.

It looks like the /SECFORCE is not setting the new ACLs.  Is the account you're copying with in the Backup Operators group on the source and destination NAS?  Typically, you want your copy account in the Administrators and Backup Operators groups on source and destination.

See if that helps you out at all!