Closed deryb closed 3 years ago
So your scenario indeed looks like quite "normal" one and indeed I've been doing something very similar for years without any problem.
One very small thing that's probably irrelevant is that 1.21 is a bit old by now and I'd recommend you to upgrade to the latest 1.23-hotfix2 instead.
As for the corruption though - in this setting, if we rule out VeraCrypt bug for now (which is not impossible, but very unlikely given this is a very typical scenario and you haven't observed any explicit malfunction), I'd say the network or your host RAM or a NAS may be the suspect.
As you open the file on your share (I assume using either a mapped drive on your Windows host or directly via a UNC path to the container, \\your.nas\vol\file
), Windows uses SMB/CIFS protocol for that and depending on the specifics, there may be some data corruption going on without any explicit manifestations - or that was a one-time thing.
This one could be checked (if that's still active only though) by running some data transfer workload withween your WIndows host and NAS and capturing the network traffic using Wireshark. The trace should expose some of the basic problems like retransmissions and so on.
NAS may have disk or RAM problems, which could manifest themselves as [silent] data corruption. This could be checked by running S.M.A.R.T. tests and memory tests. Whether this is possible and how specifically would depend on your NAS model.
Finally RAM on your host could be checked by something like memtest86+
.
As for log files - on Windows you could check Event Log. Specifics of accessing it depend on the Windows version, but usually right-click the My/This Computer icon, Manage and it will be there in the tree. Look for Application and System logs.
Hope this helps.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had recent activity. This probably means that it is not reproducible or it has been fixed in a newer version. If it’s an enhancement and hasn’t been taken on for so long, then it seems no one has the time to implement this. Please reopen if you still encounter this issue with the latest stable version. You can also contribute directly by providing a pull request. Thank you!
I had exactly the same issue today. Windows 11 and VeraCrypt v1.25.9, HDD encryption, NTFS file system. I have copied 2Tb of data (mostly mp4 files) to a encrypted drive and 4 files were corrupted. After comparing both files I found out that the difference was only, in 1 bit, so on each file only 1 bit was corrupted.
I had some files on an encrypted container which became corrupted. I cannot find cases where this happened and cannot reproduce this at the moment (it happened a while ago and did not have time to waste), but needless to say I freaked out and hoped this wasn't a widespread issue. I use this container to store financial documents, mostly pdf files. The corruption appeared when trying to open some of these files and the reader app complained the files were corrupt. I tried with a bunch, Acrobat, Foxit, Chrome, etc.
I realize there's nothing to debug with this blurb of anecdotal info, but at the very least I'd like to know steps to try and help pinpoint what was the issue.
My environment:
Here's my typical usage scenario:
I'm pretty sure no dismount happened while these files were being written, and usually am careful to dismount manually volumes. Please suggest steps I can do to tackle this. One idea I had was to look at log files somewhere, but did not find how.