Truecrypt mounts device instead of partition

Hi,

I have a external hard-disk, wich is encrypted entierly with truecrypt ext3 on Ubuntu 12.04 32 bit.
Last week on a startup the truecrypt partition was unable to mount, giving the message that the password is not right one.
I restarted the system as i was unable to acces it. At the moment i was restarting i wasn't write any file to hard0dsik. Some are saying that the docking station is faulty and the hard disk disapears due to power issues. Is a Dell docking station using with a Dell Inspiron E6430.

I did a "Restore Volume Header" and after that i could mount the device /dev/sdb, not the partition /deb/sdb1, with truecrypt.
The issue is that the device apears to be empty, no files are shown, but there is ocupied space on device.

I tried to find/fix with testdisk-6.14-WIP but even if it reports Structure Ok i can't see any file. (with testdisk_static)
As the space is ocupied seems the files are there, but can't acces them, i think MBR is lost.

In atempt to recover/fix the partition with fsck i i get many inode errors, stoped after 1 min.

Any help is much aprecieted.

I tryed to get help on truecrypt forums, but they have a issue with account validation, you don't get the activation link by email, just information about acount.

 

Re: Truecrypt mounts device instead of partion

Hi,

I've been through a similar loss of data situation. I strongly sympathize with you. I can't address all of the questions you raise, but I do have a couple of thoughts that might help.

Unless TrueCrypt is totally different on Linux as compared to Windows, it isn't possible to encrypt an entire disk unless you are encrypting the System partition. So with your external drive and multiple partitions, this means each of the partitions would have needed to have been encrypted separately. The point I'm trying to get to with this logic, is that restoring the header of one partition shouldn't be expected to do anything to fix the other partition, because the other partition was separately encrypted. Instead, the other encrypted partition should have its own separate headers that need to be restored. So perhaps you can fix the other partition by restoring different headers.

Second, when you use recovery software, it won't do any good at all unless the partition is mounted using Truecrypt. If the partition is not mounted, the recovery software will find only encrypted data, and cannot recover anything.

And here's another potential problem and solution. I use BitDefender (BD) for antivirus. At one point, BD introduced a modification to give extra protection in the case of drives mounted by usb ports. But it turned out that for many of us that the extra BD protection actually ended up preventing proper use of the usb port(s) to mount external drives. After much effort I realized at that time that unexpected usb port problems were actually caused by BD. Then, after a great deal of searching, I found that BD had issued a registry fix for the usb port problem. Bottom line here is for you to consider whether antivirus or other new, or newly changed, software could be causing a usb port problem. One easy way to test this is to try mounting the partitions of your external drive using someone else's computer -- install TrueCrypt on their system and see if you can mount the partitions of your external drive using their computer.

That's all I can think of at the moment -- except -- don't give up, keep at it; you may yet find a solution -- And others here know a great deal more about all of this than I do. Those others are likely to offer additional help if you need it.

__

 

At the encryption there was a single partiton, not multiple ones. The entier drive was encrypted.

Thanks for trying.

 

Perhaps we have actually made some progress after all.

If I understand correctly, you are saying:

(i) you encrypted the external drive as a single partition;

(ii) then you had a problem mounting the drive;

(iii) and then after that you tried to fix the problem and found that the drive now has two separate partitions, even though it should only have a single partition.​

Is this correct? If so, it likely means that the problem is a bad partition table entry that is interfering with proper mounting and use of the TC partition.

Identifying the precise cause of a problem often turns out to be the biggest step in fixing the problem.

There is software to repair partition table entries -- again there are others, who have more expertise and perhaps can help you fix this.

__

 

The order is like this.

1. Encrypted the hole external drive with one partition directlly from TC, ext3 format.
2. I wasn't able to acces/unmount the drive so i rebooted Ubuntu.
3. After reboot the password wasn't recognized
4. Restore volume header from TC and the password worked again
5. TC mounts the external drive, but not the partition /dev/sdb1 as before, instead mounts the device /dev/sdb.
6 There are no files or directories listed
7. Space is ocupied on mounted volume, indicating that information is there.

Thanks!

 

While you're waiting for help, let me tell you what I did to partially recover my lost data.

Don't do this unless everything else has definitely failed -- and hopefully not until you have done a full sector by sector backup of the entire drive.

Ok -- In my case, I did a dumb thing that overwrote a small portion of the beginning of an encrypted TC partition. MFT was gone. I was able to restore the TC header but still could not read any files in the partition. And various recovery software I tried indicated that the restored partition was not formatted.

So. Since the partition was originally formatted by TC using my selection of "NTFS" for format type, I mounted my damaged partition with it's restored header using Truecrypt. Then I used a "quick format" command for "NTFS" for the damaged partition. After that I was able to recover numerous files from the partition using recovery software ("Recuva" as I recall). There was a problem however in that the recovered files did not retain anything of their original names. So the recovered files had names like "[1123].doc" and "[466].cab", [387].jpg, etc.

I had to look at each recovered file to figure out exactly what it was -- and in some cases it was just beyond my experience level to do this -- no idea what program some files such as various .cab files were originally associated with.

I did recover a lot of useful files. Lost a bunch of other files too.

This is not optimum solution -- Obviously -- but it did recover some of my lost files.

One thing of interest -- the other encrypted partitions on the same physical drives were just fine -- unharmed. So one good lesson I learned was that it is a good idea to use multiple partitions, instead of a single partition. With a single partition you risk a lot more harm in the event of damage to the partition. With multiple partitions, harm to one partition can be limited to that one partition while the other partitions are completely unharmed.

Subsequently I've used backup processes on a much much more regular basis.

Hope you find a more complete solution.

__

 

Sorry I can't be of more help.

Hope that someone else here can aid you.

__

 

Apparently the header was restored to the beginning of the disk rather than the beginning of the partition. If the header is not in exactly the right spot then the data will not decrypt. In this case things will appear to behave normally (the password will be accepted, the volume will mount), but the contents of the volume will not be decrypted, and thus there will be no viewable files or file system present. This happens to a lot of users who lose their partition structure and then restore their header to the wrong location. You need to restore the header to the partition, not the drive.

 

Can you help out with some instructions on how to do that, as no partition is shown now?

Some tips might also be usefull.

Thank you for your time!

 

I'm not familiar enough with Linux or ext3 to be particularly useful here, but take a look at the "TrueCrypt Missing Partition Table" thread (link below) for an overview of how things might go in Windows. If you can connect your external disk to a Windows box and install WinHex on it you might be able to perform many of the diagnostic steps listed in that thread, especially Post #6, Parts 1 and 2. Alternatively, install a hex editor that will run under Ubuntu and try to adapt my WinHex instructions to accomplish the same tasks.

https://www.wilderssecurity.com/showthread.php?t=336671

Note: Partitions set up by Ubuntu might be aligned differently, although I'm fairly sure the latest versions match the current alignment used by Windows. Thus, I can't guarantee that your lost partition used to start at offset 1048576 (decimal), but I would try there first.

I also don't know if my testing methodology would be valid under your particular conditions, so I guess you'll have to find out. I can't promise anything, as these are uncharted waters for me.

 

I'll try on linux, as i havent encrpted he hard disk to be accessible in windows

Thanks for trying,i understand.