Possible Duplicate:
Robocopy permission denied

When trying to run the following command

robocopy d:\directory \\server\directory /S /XO /COPY:DT

I get an access denied error. I am running Vista Ultimate x64, Administrator permissions, I am the owner of both directories.

I saw this question and thought it was similar, but I'm getting the following error message:

ERROR 5 (0x00000005)(Copying file d:\blah....)

Is there a fix for this? If not, Is there a way to skip the errored files and just continue on to the next files?

  • is one of the folders a network folder?
    – John T
    Sep 29, 2009 at 4:28
  • Presumably the \\server\directory is network (in response to John T). However, perhaps that should be \\server\SHARE_NAME\directory instead?
    – Chris_K
    Sep 29, 2009 at 4:56
  • Three points: 1. Is any file in the directory in use? (Check using Unlocker 1.8.7) 2. Is UAC on. If yes are you running the bat file with elevated permissions or no? 3. Can you first try connecting to the \\server manully & see if it requires any authorization for access.
    – Ganesh R.
    Sep 29, 2009 at 6:21
  • Duplicate of superuser.com/questions/25509/robocopy-permission-denied.
    – Kez
    Mar 15, 2010 at 8:08

1 Answer 1


Quoted from here :

In my case, I started out with full control on both the source and destination shares. The problem was that Robocopy was resetting the ACL on the destination share to a null value (nobody has permission) before it began recursing subdirectories. After some quick tests, my conclusion is that Robocopy does not handle inherited permissions. Say you are copying C:\Share1 to D:\, and C:\Share1 is inheriting its permissions from the C:\ root directory, it actually has no explicit ACL. Therefore, when you copy its ACL, you are actually copying... nothing. By copying an empty ACL to your destination your permissions are removed in the first step of the copy, and all subsequent writes to the share fail with Error 5.

This is only a problem when you are copying from a source which you are accessing WITH inherited permissions and a destination which you are accessing WITHOUT inherited permissions. If you copy C:\ (which has you explicitly in its ACL), to D:\, there is no issue. If this is indeed your problem, you can resolve it by adding yourself explicitly to the source ACL with full control. When the copy runs, your ACL entry is duplicated to the destination, and the subsequent file copies can be written. You can undo your changes (on both source and destination) after the copy completes.

If you continue to have problems despite the above, you might want to consider trying the /B switch, which attempts to back up the file using your privileges as a Backup Operator. This will allow you to copy files that you otherwise couldn't, for example, if you are not on the ACL on your destination share. Robocopy defaults to attempting a restartable copy. By giving up restartable copies the worst case is that you lose the file currently being transferred in the event of a disruption. The next pass will restart that file from its beginning instead of partway through.

Hope that helps. Here's a quote from Microsoft's Robocopy doc regarding the /B switch:


If you copy NTFS security information (ACLs) along with file data, it is possible to copy files to which you have read access, but not write access. After such a file is copied once, and the ACLs are applied, you may find that to get an “Access Denied” error when you try to copy the file again. In this situation you should use the /B or /ZB switch to copy the files in Backup Mode.

/B copies all files with backup semantics (Backup Mode). /ZB first attempts to copy files in restartable mode (for greater resiliency) but if that fails with an “Access Denied” error it automatically retries the copy using Backup Mode.

Not the answer you're looking for? Browse other questions tagged or ask your own question.