I have a TrueCrypt-encrypted volume as an external USB drive used with my OSX tower. Usually when plugging in the drive, the OS gives a popup indicating it recognizes the drive that was inserted does not have a readable partition on it, and would I like to initialize, eject, or ignore that. I usually have to click "ignore" and then launch TrueCrypt to mount the drie.

A few days ago, when I went to go mount the drive, instead of the usual prompt, the OS actually mounted a blank partition on the drive! I tried to get TrueCrypt to mount the encrypted volume, but it said the device was busy. I used Disk Utility to unmount the blank volume and tried TrueCrypt again, however, the moment after I enter my volume password, the drive re-mounts, and TrueCrypt says the device is busy.

So, a few questions here:

Is it possible that the random encryption of my data randomly (10,000 monkeys jumping on a keyboard) created a partition map for this drive that makes the OS think there's one partition on it? I'm not sure where the location on the disk is for the partition map vs. the TrueCrypt volume header vs. the beginning of the data. If somehow the last time I mounted this drive, instead of hitting "ignore" I hit "initialize", and OSX overwrote the partition table with a single, OSX partition, did that destroy the TrueCrypt header on the drive? Or is that still there, able to be restored, somehow?

It may be that my encrypted volume is still there, but for some reason TrueCrypt seems to be mounting the partitions in the drive partition map as part of the decrypting process, which interferes. Is there any way to get TrueCrypt to decrypt a volume without triggering the OS to mount the drive and then complain that the device is already busy?

  • No; Its not possible the random encryption ( actually not all that random ) mimics that exact data required to appear to be a partition map. The drive worked at some point so the TrueCrypt encryption can't be viewed as a partition map. – Ramhound Jul 22 '14 at 14:14

So it appears the volume header got overwritten with a default partition map at some point, but I was able to use the backup volume header TrueCrypt hides at the end of the volume to get past this issue:

In TrueCrypt, I selected the device, but didn't mount it. Then using the "Volume Tools" option, chose "Restore Volume Header" and then chose the option to restore from the internal backup header.

That stopped the drive from auto-mounting a partition, but now I'm running into an "hdiutil" error that it still can't mount the drive, but I know the header is now correct, since if I enter the password incorrectly, I get a different error ("bad password, or not a TrueCrypt volume").

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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