3

I am getting bizarre error with RoboCopy in Server 2008. It will randomly hang with "The specified network name is no longer available." error. Once that happens, it will continue to fail on the retries. But of course the remote server IS still available on the network and can be reached with other tools.

I think it must be somehow permission related but I can't figure out what is wrong. Any ideas would be much appreciated.

Other info:

Options : *.* /S /E /COPY:DAT /NP /R:10 /W:30

If I turn on the /B option it will fail 100% of the time at the very beginning (that's why

I think it has to be somehow permission-related)

The two servers are standalone and I am doing a NET USE command prior to the robocopy

It does not matter what user account on the remote server. Tried both Administrator and another user which was also a member of the local Administrators group

UAC is turned off on both sides

It is not always the same file that hangs. Sometimes it will get through half or more and sometimes it will fail on the first file

  • forgot to mention: used this script on Windows Server 2003 for a couple years with no issues. –  Dec 23 '09 at 19:21

3 Answers3

1

I am having this exact same issue. I am thinking it is something on the server that is killing my robocopy session as well. I have to dump a 60GB folder onto a server across the country. I start the robocopy and it goes for about 30 min and then times out. It goes farther and farther in it's session each time but it still times out after a while. I am using the /mir switch to get it all copied. I have about 5GB of the 60 now copied and now its hanging on the same 200MB file. It hangs on different percentages of the file but it still hangs.

I think its the server itself because I can copy to another server that is Windows 2000 with no issues. Until I get this resolved, I am just going to copy to the older server, it has the space for now. I will look at the symantec bulletins and let you know my results.

0

This may be some kind of network error. Here's a few more things that you can try:

  1. Have you tried specifying IP addresses instead of hostnames?
  2. Can you run this script on other non-2008 systems? I know you have in the past, but can you now?
  3. Have you checked the event log?
  4. Does this problem persist if the servers are directly connected? (not through a switch)
  5. Have you tried other copy utils? (xcopy, rsync, or even scp)
Joseph Kern
  • 9,809
  • 3
  • 31
  • 55
  • 1: using IP address makes the problem less frequent (roughly 1 out of 10) but does not solve it entirely. Also, even when it succeeds it still hangs for a while on certain files. Read on... 2: Yes if I target 2003 server it works fine (the origin of the transfer is 2008 in both cases). All servers are in the local network, but copying to the 2003 averages 300MB per minute while the 2008 is often 50MB or less depending on how long it hung up on one file. 3: nothing interesting in the event logs –  Dec 23 '09 at 22:18
  • I think it might be time to break out wireshark and sniff the packets. Just to verify if it's a timeout or an RST is being sent from some where. The hit in speed is pretty intense, I was going to say "Welcome to 2008." but even that seems a bit low. See numbers 4 and 5 in my answer (I added two). – Joseph Kern Dec 24 '09 at 00:58
  • one other bit of info related to #5: once it starts throwing the error I go to a separate command prompt and attempt to read the directory on the remote server. This also fails, which tells me that it's not strictly related to robocopy. If I then un-map and re-map the remote drive it works OK in the other command prompt but robocopy continues to fail on the retries. –  Jan 04 '10 at 19:37
  • was now able to reproduce the problem using xcopy, though less frequently than with robocopy –  Jan 04 '10 at 21:46
0

With the error message you mentioned, I don't think this is related to permissions. A few possible causes of the problem:

1) If you're copying to a clustered fileshare, check the dependencies. The file share should depend on disk and a network name, and the name should depend on an IP address. 2008 clustering might sort the dependencies for you automatically (I need to learn more about 2008 clustering), but Windows 2003 didn't really. If the dependencies are wrong, the name (and the share) can drop off the network.

2) You might want to try using RichCopy with the "turn off system buffer" option. This is a GUI option, but there should be a command-line equivalent. You can also do the same thing with eseutil. Either option will get you around an annoying problem (especially common on 32-bit servers) with CIFS transfers failing due to running out of system cache.

3) If you're running Symantec, check out these articles about fileshares deadlocking on Windows Server 2008:

http://blogs.technet.com/windowsserver/archive/2009/12/11/symantec-solution-available-for-network-path-not-found-and-other-errors.aspx

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007102613484948

4) It might be worthwhile to check the NIC and switch port error statistics and verify that speed/duplex are correct, but in my experience with this type of problem, the other causes are more likely unless you have other network-related problems.

jlupolt
  • 884
  • 1
  • 7
  • 10