Truecrypt is a very cool way to store files in an AES or other cyptographically secure container that can be used to encrypt your documents or other files. At home, I have a large, 2 GB truecrypt container that I use to file all of my scanned bills in in an attempt for a paperless filing system. One day, I was adding some bills. I wanted to make sure I had the most recent copy from my backup server, so I used rsync to start pulling it down before I started. 1:1. Awesome. Added my files on the local box, and used the same rsync command to push it back up… NO! WAIT!! Ctrl+C!! I was pulling from the Backup server again, so all of my additions would be over-written. OK, now let me change the directory and source and… OK off it goes. Waitaminute.. this is even worse… rsync complete….
I just messed up the entire container by using two different files into a single, one… Not. Good. And since we’re dealing with crypto, one bit of difference results in a HUGE change.
Try mounting it:
“device-mapper: resume ioctl failed: Invalid argument. Command Failed”
… uh…. dang.
OK… what can I do now? May I can recover the original? I tried the using the awesome testdisk/photorec tools to recover the .tc file, but there’s a problem. Truecrypt contains an encrypted key, information about encryption algorithms, and partition information in the headers of each .tc, so there really isn’t a set container header flag like there is with JPEGs.
After some reading, I resolve to recreate it the best I can using my offsite backup which was temporarily down and didn’t contain the most recent version.
A side note: I use rsync to make backups of my files to my offsite, through SSH. rsync uses the date/time information on a file to determine what to send by default, as it is extremely fast. Using rsync to update and transfer truecrypt containers pose a problem however, as the date modified doesn’t always update when mounting in linux. This can either be resolved by using the command “touch -m container.tc” to update the time modified timestamp for the container, and thus making rsync force a check on it, or by using the “-c” option for rsync to compare by checksums rather than timestamps. It is significantly slower, as both ends need to do an MD5 checksum of the file and compare, but it is better than arbitrarily updating the date modified IMHO. And now, back to our original programming.
The problem was using an old copy of my bills container was it was missing all of 2013 and some other bills I filed and sorted throughout since 2010… I make a copy of now screwed up container and label it as the corrupted version. I figure that I MIGHT be able to do something with it later on down the road and recover SOME of the files. I look around some more, and find that I can use a hex editor to go into the free-space of the drive and I might be able recover the original container… OK, not exactly ideal and I might not even be able to recover it at all. I resolve myself that I just lost ~ 1GB of bills that I may need to reference forever. I cannot scan these in again, as the bills have been used to make confetti by the almighty paper shredder, and the thumbdrive I used to scan them to has since been overwritten.
Last resort, I see this post suggesting I use a mount option (-m=nokernelcrypto). I give it a shot. And it works. HALLELUJAH! I copy all of the files to the newly created bills.tc and backup like crazy to my offsite.
Lessons learned:
- If you are getting a “device-mapper: resume ioctl failed: Invalid argument. Command Failed”, try the -m=nokernelcrypto option.
- Double check your rsync source/destinations.
- Because rsync goes by date/timestamps, and the Truecrypt container may not be updated, either do a “touch -m container.tc” or “rsync -c” option to go by checksum and not by day/time.
- I’d take 1 or 2 corrupted PDFs rather than lose ~1GB of data.
Gomez Development 