RoboCopy unable to copy between a server on a domain to a computer in a workgroup












2














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.10Pictures 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:UsersstefaOneDrivePictures

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:UsersstefaOneDrivePictures
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.10IPC$ ... 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.










share|improve this question
























  • Can you run Robocopy with elevated privileges just to see if that helps
    – Dave
    Jun 25 '15 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.
    – Stefán Jökull Sigurðarson
    Jun 25 '15 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.
    – Frank Thomas
    Jun 25 '15 at 13:04






  • 1




    Also have you tried using the literal UNC path to the share rather than the mapped drive?
    – Frank Thomas
    Jun 25 '15 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.
    – Stefán Jökull Sigurðarson
    Jun 25 '15 at 13:45


















2














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.10Pictures 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:UsersstefaOneDrivePictures

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:UsersstefaOneDrivePictures
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.10IPC$ ... 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.










share|improve this question
























  • Can you run Robocopy with elevated privileges just to see if that helps
    – Dave
    Jun 25 '15 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.
    – Stefán Jökull Sigurðarson
    Jun 25 '15 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.
    – Frank Thomas
    Jun 25 '15 at 13:04






  • 1




    Also have you tried using the literal UNC path to the share rather than the mapped drive?
    – Frank Thomas
    Jun 25 '15 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.
    – Stefán Jökull Sigurðarson
    Jun 25 '15 at 13:45
















2












2








2







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.10Pictures 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:UsersstefaOneDrivePictures

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:UsersstefaOneDrivePictures
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.10IPC$ ... 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.










share|improve this question















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.10Pictures 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:UsersstefaOneDrivePictures

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:UsersstefaOneDrivePictures
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.10IPC$ ... 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.







windows network-shares domain robocopy workgroup






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jul 1 '15 at 21:34

























asked Jun 25 '15 at 11:23









Stefán Jökull Sigurðarson

21136




21136












  • Can you run Robocopy with elevated privileges just to see if that helps
    – Dave
    Jun 25 '15 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.
    – Stefán Jökull Sigurðarson
    Jun 25 '15 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.
    – Frank Thomas
    Jun 25 '15 at 13:04






  • 1




    Also have you tried using the literal UNC path to the share rather than the mapped drive?
    – Frank Thomas
    Jun 25 '15 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.
    – Stefán Jökull Sigurðarson
    Jun 25 '15 at 13:45




















  • Can you run Robocopy with elevated privileges just to see if that helps
    – Dave
    Jun 25 '15 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.
    – Stefán Jökull Sigurðarson
    Jun 25 '15 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.
    – Frank Thomas
    Jun 25 '15 at 13:04






  • 1




    Also have you tried using the literal UNC path to the share rather than the mapped drive?
    – Frank Thomas
    Jun 25 '15 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.
    – Stefán Jökull Sigurðarson
    Jun 25 '15 at 13:45


















Can you run Robocopy with elevated privileges just to see if that helps
– Dave
Jun 25 '15 at 11:28






Can you run Robocopy with elevated privileges just to see if that helps
– Dave
Jun 25 '15 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.
– Stefán Jökull Sigurðarson
Jun 25 '15 at 11:42




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.
– Stefán Jökull Sigurðarson
Jun 25 '15 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.
– Frank Thomas
Jun 25 '15 at 13:04




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.
– Frank Thomas
Jun 25 '15 at 13:04




1




1




Also have you tried using the literal UNC path to the share rather than the mapped drive?
– Frank Thomas
Jun 25 '15 at 13:06




Also have you tried using the literal UNC path to the share rather than the mapped drive?
– Frank Thomas
Jun 25 '15 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.
– Stefán Jökull Sigurðarson
Jun 25 '15 at 13:45






@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.
– Stefán Jökull Sigurðarson
Jun 25 '15 at 13:45












3 Answers
3






active

oldest

votes


















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





share|improve this answer





















  • 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...
    – Stefán Jökull Sigurðarson
    Jul 1 '15 at 17:53



















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






share|improve this answer





























    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...






    share|improve this answer





















      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "3"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f932496%2frobocopy-unable-to-copy-between-a-server-on-a-domain-to-a-computer-in-a-workgrou%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      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





      share|improve this answer





















      • 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...
        – Stefán Jökull Sigurðarson
        Jul 1 '15 at 17:53
















      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





      share|improve this answer





















      • 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...
        – Stefán Jökull Sigurðarson
        Jul 1 '15 at 17:53














      0












      0








      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





      share|improve this answer












      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






      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Jun 27 '15 at 21:07









      Bernd

      663




      663












      • 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...
        – Stefán Jökull Sigurðarson
        Jul 1 '15 at 17:53


















      • 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...
        – Stefán Jökull Sigurðarson
        Jul 1 '15 at 17:53
















      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...
      – Stefán Jökull Sigurðarson
      Jul 1 '15 at 17:53




      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...
      – Stefán Jökull Sigurðarson
      Jul 1 '15 at 17:53













      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






      share|improve this answer


























        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






        share|improve this answer
























          0












          0








          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






          share|improve this answer












          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







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Oct 10 '15 at 6:27









          yossi

          1




          1























              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...






              share|improve this answer


























                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...






                share|improve this answer
























                  0












                  0








                  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...






                  share|improve this answer












                  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...







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Oct 15 '15 at 15:44









                  Spiralis

                  1715




                  1715






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Super User!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.





                      Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                      Please pay close attention to the following guidance:


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f932496%2frobocopy-unable-to-copy-between-a-server-on-a-domain-to-a-computer-in-a-workgrou%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Plaza Victoria

                      Puebla de Zaragoza

                      Musa