This project has moved and is read-only. For the latest updates, please go here.

Drive unmounts during copy

Topics: Technical Issues
Mar 9, 2016 at 5:52 PM
I'm a first time VeraCrypt user.

I've searched these forums and Google, and can't seem to find an answer to my problem. Apologies in advance if this has been covered a zillion times and I'm just too dense to construct search criteria to find it.

I'm using the latest version of VeraCrypt 64bit (1.17) on a Windows 7 Pro system.

Attached to that system is an external USB 3.0 1TB hard drive, formatted with NTFS. I created a 900GB container, and mount that as Drive G:

We're backing up a medical database (the reason we need to encrypt it) and a Virtualbox VM containing the OS and application to the container (G:). I'm using Micro$oft's SyncToy to back up the system. All seemed to go well creating and mounting the drive, so I started up SyncToy to begin the copy. There is about 70 GB in the VM folder tree, and another 400 GB in the database folder tree. There are > 500K files in the database folder tree (PDFs, .DOCs, .TIFFs with patient information), and only 8 files in the VM folder tree.

I started the copy around midnight, and when I checked it the next morning, it had failed about halfway through. Checking Windows Explorer, drive G: was not mounted. The error from SyncToy said that it was unable to complete a copy operation. I went into the VeraCrypt dialog box and remounted the device (I had it saved in Favorites). I got the messages about it was not cleanly unmounted, and was prompted to run CHKDSK, which I did. Thinking that it may have been a one-off glitch, I restarted the backup the next night. Again, SyncToy got about halfway through, failed, and drive G: was unmounted.

One oddity about the database folder INSIDE the container - checking Properties shows that the size of data is 25 GB, but "size on disk" is 65 GB. The files in the database include an MSSQL .MDB and .LDB file set, is it possible those are "sparse" data files and are confusing the VeraCrypt driver? Just a thought.

I double checked to see that the system wasn't going to sleep (power options - Never Sleep).

I wasn't able to find any useful info in the Windows Event Viewer, nor was I able to find a VeraCrypt log file.

Any suggestions on how to troubleshoot this would be appreciated.
Mar 11, 2016 at 4:34 PM
Bump!

Anybody?

Does VeraCrypt have a logfile, or something easy to identify in the Windows Event Viewer so I can troubleshoot this problem?

Thanks...
Mar 15, 2016 at 10:18 PM
I'm hardly qualified to answer, but since this is almost a week old, I'll drop some
thoughts here.

I don't see a log in the place I'd expect one (/var/log) on my gnu/linux system but
there are other places one might be, I haven't diligently searched, and Windows
would be different anyway. You might check the manual on that subject, but it
wouldn't surprise me if the default behavior was to NOT log anything, but to
only do so if some sort of debug option (Windows used to call cli options
"switches", don't know if it still does) is invoked. Given the objective of this
program to give away as little info as possible, that's the way I would do it.

But, I wouldn't limit myself to Veracrypt logs. Does SyncToy have its own log?
If not, wouldn't a failed write be logged in some sort of system log? You might
want to check all logs that changed in the appropriate time frame.

Also, a work around occurs to me. Security in med records is a matter of legal
compliance (damn all bureaucrats to the hottest part of Hell) and I'm don't know
how specific the security requirements are. But if you are storing the original
records in a container crypt, you could just back up the crypt as a file. There are
2 problems with this approach:
1-It is profligate with drive space, since it backs up everything, not just what
has changed. But unless you are storing a lot of media files (x-rays for example)
those records must be mainly text. So they probably aren't too big.
2-It is somewhat less secure, since an adversary can compare different versions
of the file and see what part is data (the needle) and what part is noise (the hay),
which is one step toward being able to crack the encryption.
But the data WOULD still be encrypted, and, provided you used a good pass
phrase, it would still be encrypted in a manner that I believe (I am open to
correction) that any reasonable person would consider adequately secure for
the purpose. Of course, not all lawyers, politicians, and bureaucrats fall in the
category of "reasonable person". So - that would almost certainly be good
enough for privacy concerns, but Finagle knows if it is good enough for
compliance or avoiding suit.

One more possible work-around: Have you tried using an encrypted partition
rather than a container file? Since backups should be on removable media anyway,
that wouldn't waste drive space if SyncToy will play nice with it. If it were me, I'd be
doing it that way anyway, and it avoids the security compromise involved in
copying multiple versions of a container file.

And BTW, is the whole system backed up regularly in some fashion? If so, the
problem with multiple versions of the container problem already exists anyway
if that file is subject to the backup. Not, I repeat, that I think that is a REALISTIC
privacy problem. The point is that there is no reason to avoid making more copies
if you are making copies anyway.
Mar 17, 2016 at 4:13 PM
I had a similar problem. When copying large amounts of data to a new VC-encrypted device, which was attached to an new SATA-controller, VC dismounted this device after some minutes. But there were no problems with an unencryted device attached to the same controller.
After replacing the SATA-controller by a more powerfull model this problem had vanished. So maybe that there is a timeout problem with some hardware which causes VC to dismount.
Mar 28, 2016 at 1:59 PM
Some addtional tests with the "bad" controller revealed, that the dismounted drive also disappears from Windows Disk Management Console.
There is an informaton in event log:
Command [0x12] on physical disk 1 failed. Sense key=0xb, ASC=0x47, ASCQ=0x3.
Using Truecrypt instead of VC doesn't help.
Seems to be the same problem as mentioned in Issue #415
Mar 29, 2016 at 6:39 PM
Thanks for the replies, JWalker and ContinentalOP...

Sorry for taking so long to post back, we've had some family health issues since my original post.

I'm going to try again taking M$ SyncToy out of the equation and just use Windows Explorer to do the copy.

It was also suggested by a friend of mine to first encapsulate the data folder into a virtual drive and access it "inside" the VM. That way, instead of copying 500,000 files to the encrypted container, I'll only be copying one file to it.

If using Windows Explorer fails, I'll give plan B a try.

I'll post the results after the test.

Thanks again,

Bob
Mar 29, 2016 at 6:52 PM
Edited Mar 29, 2016 at 6:53 PM
Don't use explorer to copy, use robocopy -- robocopy is "robust copy" ... it can be used to mirror a folder tree or just for copying single files; it only copies changed files. There are lots of options to work with too.

Here is a typical robocopy command incarnation:

robocopy "c:\somedir" "z:\somedir" /mir /tee /copy:DAT /DCOPY:T /TIMFIX /SL /xf excludefilename /xj /z /fp /log:c:\logdir\job.log

Do "robocopy /?" to see all the options....
Mar 29, 2016 at 7:14 PM
Affinity,

Sounds similar to what SyncToy does, although from the command line. SyncToy only copies changed files as well.

I'll keep it in mind.
Mar 29, 2016 at 7:18 PM
Edited Mar 29, 2016 at 7:18 PM
By the way, this is a legacy system, so files aren't updated. It's an old medical records database that the client needs to access for 7 years to comply with HIPAA requirements. I'm trying to create an archive we can store it securely offsite in case the place burns down or the host PC dies. I've built it into a virtual machine so we can restore it easily on just about any hardware the client owns.
Apr 1, 2016 at 10:28 PM
If this is external drive, it could be power problem. I had similar problems you describe on one PC and it was solved by using usb cable with extra power "Y cable", you can get micro usb 3.0 Y cable for ~$5 including shipping on amazon, aliexpress, etc.

I had also problems with dismounts when I have checked "auto dismount volume after no data has been read/written to it" in preferences. This is probably not releated to your case, but it happened like this: 1. I downloaded a movie. 2. when I played it right after the download, media player read the file from RAM instead from disk (vecause windows buffered that), so VC autodismounted the volume, which eventually led to stop of playback of the movie :( Quite annoying, because this happened only on a system with large RAM and took me a while to figure it out...