Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

In a nutshell

After some time using the outer volume of a hidden volume in Truecrypt I cannot write to the outer volume anymore. The protection of the inner volume always kicks in before. How do I fix this?


Details

I'm using truecrypt's two layered encryption of a USB stick. The outer container carries my semi-sensitive stuff while the inner hidden values has a bit more valuable information. I use both, the inner and outer volume regularly and that is part of the problem. Truecrypt can mount the outer volume for writing while protecting the inner. Usually the inner volume, when not protected this way (or mounted read-only) would be indistinguishable from free space. That is of course part of the plausible deniability scheme of truecrypt.

Truecrypt outer volume

At the beginning, everything worked as expected. I could copy and delete data to the outer volume as I pleased. Now it seams that I have written and deleted enough data to have filled the outer volume once. Despite the write protection Ubuntu tries now to write to the continuous "free space" that is the inner volume. It does that although enough other free space is on the outer volume. But on this free space there used to be data so its fragmented and the file system write prefers continuous space. The write on the continuous free space of the outer volume of course fails (with the error message in the picture above) as Truecrypt's inner-volume-protection kicks in.

The Question

I know this is expected behaviour, but is there a better way to write to the outer volume that does not attempt to write to the hidden free space at the end?

The whole question could be more generally rephrased to: How do I control, where on a partition data is written in Ubuntu?

share|improve this question
    
This would be a bug or rather a design defect in truecrypt. They would need to patch the filesystem to avoid the areas actually used by the inner filesystem. –  psusi Dec 4 '12 at 15:38
    
@psusi But then, wouldn't the hidden inner volume be more obvious? It could be easily detected by merely attempting to fill up the outer volume. As soon as the person noticed that "hey, the files are all magically avoiding writing to this spot," it would reveal the existence of the hidden inner volume. (The whole point of the inner volume is that it doesn't even appear to exist unless you specifically attempt to decode the inner volume and get the password correct.) –  JamesTheAwesomeDude Dec 4 '12 at 16:06
    
If you have to make any explicit change to the configuration of the outer volume to protect the inner, then there is no point using an inner volume since you make it clear that it exists, and might as well have it exist safely as a separate volume. (I would question in general that truecrypt inner volumes serve any useful purpose, since the feature is so well known that any hostile party presented with a truecrypt volume is going to assume an inner volume exists regardless, plausible deniability be damned). –  chronitis Dec 4 '12 at 16:24
    
That is all true. However the hidden volume could be distributed across the whole memory area pseudo-randomly using the unlock key as a seed for distribution. This way Truecrypt would know what to protect while still looking random. Files are over written all the time so a hidden volume distributed in such a way would not be as obvious. Chronitis has a point, still the inner volume makes it harder for it might not even be there. That's not the point of my post however. I just want to use the inner volume again. It seems like a bug to me. –  con-f-use Dec 4 '12 at 17:09
    
@JamesTheAwesomeDude, that's how it works now... the driver won't let you write to the parts that hold the inner volume, but trying to causes the filesystem to error and go read-only. And yes, this only works if you provide the super secret password for the inner volume. –  psusi Dec 4 '12 at 18:30
show 5 more comments

1 Answer 1

I do not know how it works with ubuntu, but with windows you can try a defrag tool like "mydefrag" and move all your data to the beginning of your disk ("consolidate free disk space"). The position where to write new data will be set to the end of your existing data.

If all your data already IS at the beginning of your disk (so mydefrag does not move any data) and you still cannot write (although there should be space in the outer volume left) you need to make mydefrag make some data movement, e.g. by choosing the option "data disk monthly" and abort it as soon as the first file has been moved.

Edit: Works with FAT32. Don't know OP's filesystem. But FAT32 seems common to me for USB pendrives.

share|improve this answer
    
NTFS file systems belive that all data must be crammed up in as little contiguous space as possible and hence the need for defragmentation. ext4 inherently is fragmented from the free space point of view. it attempts to prevent file fragmentation but fragments freespace nevertheless. this is not what the OP is looking for. –  Mahesh Feb 3 '13 at 10:42
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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