Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm having a problem transfering large (50-200GB) VHD files from a Windows Server 2008R2 machine to a QNAP NAS. After the transfer is completed, I verify the data using a CRC32 checksum to ensure it wasn't corrupted (these are important backups). I am getting constant CRC miss-matches for large files. I have tried using SAMBA and FTP, both with the same problem. I have tried several different tools to calculate the CRC checksum to rule out false negatives.

This is what I've tried so far:

  • Different Windows server (no fix).
  • Different NIC/Cables/Switches (no fix).
  • Different Updating NAS firmware (no fix).
  • Different destination server (I built a samba server in ubuntu which worked fine).
  • The same process works in another office with an identical model NAS using SMB.

IMO, this has been narrowed down to the QNAP device. I've ruled out the windows server, networking gear, samba protocol/version. Is there anything else I could try?

The QNAP share is configured as a RAID5 with the EXT3 filesystem.

share|improve this question
So now that the CRC shows a difference, go find out what the difference is -- do a byte-by-byte comparision of the files to help identify the source of the problem. – womble Sep 5 '11 at 3:32
Have you paused or shutdown the virtual machine first? – Matt Sep 5 '11 at 3:45
Yes, I shut down the VM, 'exported' it to another directory and that exported copy is what I'm working with. I have not done a byte-by-byte comparison of the 200GB files as I don't see what that could tell me apart from which bytes were accidentally corrupted during transmission. – PSA4444 Sep 5 '11 at 4:34
A byte-by-byte comparison could show you one of two things. 1) your checksumming plan is incorrect (files are identical but have different 'checksums' for some reason) 2) Additional information on the corruption. E.g. you find that only the last byte is corrupted. Or you find that every occurrence of the letter 'a' has become 'A'. Whatever the exact difference is, it may point directly at the source of the problem. – Slartibartfast Sep 8 '11 at 5:11
We're seeing a similar problem, which comes and goes on an irregular basis. I confess though that I don't understand how the byte-by-byte comparison could help pinpoint the source. Can someone give me some examples? – mahnsc Sep 8 '11 at 15:01
up vote 1 down vote accepted

Problem Solved.

It turns out to have been caused by a Faulty Western Digital SATA Hard Drive. We ended up replacing it and the problem went away (even though it passed all the drive tests).

WD drives have been nothing but trouble here. Thanks for the responses.

share|improve this answer

Maybe a Jumbo Frame issue? Here's some good info.

share|improve this answer
I believe that SAMBA and FTP are both TCP based protocols. TCP connections should either succeed without corruption, or fail (also implicitly without corruption) due to jumbo frame issues. – Slartibartfast Sep 8 '11 at 5:08
It turns out to have been caused by a Faulty Western Digital SATA Hard Drive. We ended up replacing it and the problem went away (even though it passed all the drive tests). – PSA4444 Mar 5 '12 at 5:30

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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