4

I have a RoboCopy problem and here is the scenario.

My server is running Windows Server Essentials 2012 R2. My laptop is running Windows 10 Technical Preview. The server is running as a domain controller but my computer is not joined to that domain.

I have a share on the server called "Pictures", so it's located at ~ \\192.168.1.10\Pictures which I have mapped as P: using an account tha thas Full Control privileges on that folder. I've been trying to mirror that folder to my local machine using the simple command:

RoboCopy P:\ "C:\Users\[MyUsername]\Pictures" /MIR

This always returns the error ERROR 5 (0x00000005) Accessing Destination Directory even though the destination directory is under my user account where I am the owner. I have tried using both an administrative command prompt as well as the standard user command prompt. Neither works :(

Using RoboCopy between two local folders using the Pictures folder as a destination works just fine, so I'm guessing this has something to do with domain permissions rather than the actual destination permissions.

P.S.

The funny thing is this worked just fine when my computer was using Windows 8 and connected to the Server Essentials using the Connector application without domain joining (The Connector app isn't available for Windows 10).

P.P.S

Copying directly in Windows Explorer works just fine, but I need RoboCopy since it's much more efficient at syncing large folders.

Any help would be appreciated.


Update

I am unable to try with a local user on the server since the server is a domain controller. I did however try to give the domain user I use to map the network drive on the workgroup machine full permissions on the folder as well as making him owner and still no dice. Here is the exact RoboCopy output:

-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows                              
-------------------------------------------------------------------------------

  Started : fimmtudagur, 25. júní 2015 21:40:01
   Source : P:\
     Dest : C:\Users\stefa\OneDrive\Pictures\

    Files : *.*

  Options : *.* /V /S /DCOPY:DA /COPY:DAT /R:1000000 /W:30 

------------------------------------------------------------------------------

                      25    P:\
2015/06/25 21:40:02 ERROR 67 (0x00000043) Accessing Destination Directory C:\Users\stefa\OneDrive\Pictures\
The network name cannot be found.

Waiting 30 seconds...

Update 2 I'm fairly certain I have just hit a bug in Windows 10 (still there in 10159). When I try this on a Windows 8.1 machine (x64 as well as RT, clean install on both) by using robocopy over a mapped network drive or net use \\192.168.1.10\IPC$ ... everything works just fine. But using a Windows 10 client, this does not work. My theory is that either something is has broken in the way Robocopy does network copies in Windows 10 or something in the network stack in Windows 10 has broken RoboCopy.

8
  • Can you run Robocopy with elevated privileges just to see if that helps
    – Dave
    Jun 25, 2015 at 11:28
  • Already tried that. Same error. Only difference is that I have to map the ndrive manually using net use when running elevated since that can't access the user mapped drives, but it results in the same error message. Jun 25, 2015 at 11:42
  • I assume the robocopy is being run as a workgroup (eg local) user? Is the drive mapped using a domain user account? Have you considered creating a local account on the server you can use for operations where the client is not in the domain? then you could map the drive and run the robocopy under the same account. Jun 25, 2015 at 13:04
  • 1
    Also have you tried using the literal UNC path to the share rather than the mapped drive? Jun 25, 2015 at 13:06
  • @FrankThomas: Yes, RoboCopy is running as my local user on my computer (Microsoft Account). I haven't thought of creating a local user on the server and trying that. I'll do that once I get home (I'm at work currently). I have tried mapping the UNC literal path, that did not work either. Jun 25, 2015 at 13:45

3 Answers 3

0

If it is a domain controller he cannot create local accounts. Please note that there are several caveats to follow to allow proper access between a domain joined computer and workgroup computer. These mostly focus on remote powershell, remote command line and server manager.

Try to use UNC path instead, similar to:

net use \\<SOURCE>\IPC$ /user:username password
robocopy  \\<SOURCE>\backup c:\BACKUP / /S /SEC /V  /NDL /NP /NFL /LOG:"c:\log.txt" /R:1 /W:1 
net use /delete
1
  • 1
    This doesn't work. I think I have however narrowed this down to being a bug in Windows 10. This fails in the above manner no matter what I do on Windows 10, but a fresh install of Windows 8.1 x64 (tried on two separate laptops I have at home, witj Win 10 as well as Windows 8.1) as well as Windows 8.1 RT can do the RoboCopy just fine using either a mapped drive or through net use. Now it's just a matter of getting MS to fix it... Jul 1, 2015 at 17:53
0

I stumbled across the same problem, on a Windows 10 installation. I am able to workaround it though, as I found that the problem was the /DCOPY:DA switch. Using /DCOPY:T for instance worked fine. So, not sure about the real cause, but I can live with the workaround, at least for now...

0

This answer is related to sync copy data to an existing directory with the same root folder name e.g.

robocopy "C:\Public" "H:\public" /s /e /w:01 /r:01 /NODCOPY

In case you want to original permission at the destination file use the option /NODCOPY

  • /s /e /w:01 /r:01 /NODCOPY
1
  • This is incorrect. It was caused by a bug in a very early version of Windows 10. Also, you shouldn't use both the /s and /e switch with Robocopy as they conflict; choose one of them. /nodcopy improves network performance but cannot help in a situation like this. Sep 9, 2019 at 3:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .