This issue has been extremely frustrating for us: when transferring a large VHD (virtual hard disk) file from a Windows 7 machine over the network to a physical Windows Server 2008 machine at our datacenter, the windows file transfer fails at 4 GB consistently. We have a direct 100 mbit connection from our main office to our data center.
When the transfer fails, the error message we receive is:
There is a problem accessing \\server-name\d$
Make sure you are connected to the network and try again.
It is only VHD files larger than 4 GB that fail. If we send any other file type, it works fine. If we zip the VHD, that also works. Moreover, we can send a VHD the other direction (from the data center to the main office) no problem. It is just VHD files in that direction.
Important notes:
- All partitions are NTFS!!
- There is no firewall between workstation and server
- We have tried disabling the antivirus on the workstation (no antivirus on server)
- We have tried transferring the file from a machine not on the domain
- We have tried transferring the file from a Ubuntu machine (still fails but at around 450MB instead of 4GB)
- Wireshark capture shows 40 DUP ACKs when transfer fails
- Xcopy and Robocopy (with restart flags) both fail (same point)
- FTP transfer fails at 4,14X,XXX,XXX bytes and cannot be restarted at that point
- We tried changing the file extension (stupid, but a last resort) to something other than vhd before sending it, but it still failed
- Connection is as follows: Dell Workstation (Main Office) -> Dell PowerConnect 5448 Managed Switch (MO) -> HP Procurve 2910al-24G Layer 3 Router (MO) -> 100Mb TLS link -> HP Procurve 2910al-24G Layer 3 Router (Data center) -> Dell PowerConnect 5448 Managed Switch (DC) -> Dell Server (DC)
So basically, it is JUST vhd files > 4GB, from our main office to our datacenter that fails. This all just doesn't add up... at this point I believe it is a issue with our network hardware settings, but I don't understand what the difference is between transferring a large VHD (which fails, at 4GB) and a large video file (which works always).
After troubleshooting this for many hours (and trying all the suggestions posted here), the issue turned out to be the TLS link between our main office and the datacenter. I called our TLS provider and after talking to several NOC technicians, one of them had heard of the exact issue before. It turned out that some of their layer 2 equipment was old and had issues with VHD data.
The solution was upgrading the firmware on these devices, which was performed by the TLS provider. We now have no issues transferring large VHDs. For those interested, our TLS provider is Shaw Communications in Victoria, Canada.
Try Xcopy or Robocopy; at least one or both have a "resume" switch. Rsync may be of help, too.
Out of curiosity, is one of the machines 32-bit, but the other is 64-bit? If so, can you try your copy with a 64-bit machine temporarily.
Searching google for large file network copy failures and you'll find some threads talking about similar issues but not just vhd's. This KB is usually linked to see if tweaking NIC settings help. TCP offload, chimney settings, etc.
http://support.microsoft.com/kb/951037
Mmmmhhhh... I see the various answers above and I realize that I still can't tell if you really tried to copy with a 64-bit copy program. (xcopy, robocopy and most FTP clients are 32 bit, even on a 64 bit Windows.)
Can you give it a try with the 64-bit version of TotalCommander V8.0 ? (It is still a Release Candidate, but very stable.) That is truly 64-bit only.
Another thing to try if the server has IPV6 enabled (usually does on W2K8): Disable IPV4 completely on the workstation so the copy will have to use IPV6. Will be interesting to see if that makes a difference.
If neither of the above brings relieve.... You can allways use HJSplit (or the split function of TotalCommander) to split the file in 1GB chunks, but of course you must have a means of re-joining them on the server. That will depend on if you have access to run a program on the server itself. (Just "copy /b chunk1+chunk2+chunk3 total.vhd" will do if you are not allowed to install additional software server-side.)
Just a thought: Is the VHD in use by the hypervisor or mounted?
It could be failing because part of the VHD is locked and unable to be read from the filesystem. This is why zipping the file works and why video files of the same size also work, but not VHD files.
Looking for a file lock in windows:
There appears to be an experts exchange post with similar issues. But there are no resolutions in the answers.
This sounds like it might even be a permissions issue, when you try to copy the file to the network location it gets stopped or fails, perhaps you could try to create a network folder make it fully open, meaning shared to the "Everyone" Group and also set that way in the security tab. If that fixes the problem, then it looks like a permissions issue, in fact since you mentioned the Linux copy failed sooner, it seems that permissions might be the problem. Make sure the files inside the VHD are not in use and you have proper permissions to access them.
Also make sure the folder you are copying from has open permissions. Remember this is just to see if the permissions are getting in the way, you can always tighten them up later once you get a staring point of the copy working properly.
Another thing and it might be a long shot, but have you tried updating the NIC drivers? Perhaps there might be a fix in the most recent driver for your machine.
I hope this helps out, Cheers