Two ways to encrypting your /home (i.e. /Users)
in MacOSX with truecrypt

This howto will allow you to have an (efficiently, no FileVault) encrypted /Users/username with a lot of privacy. I will explain you how to do it in two different ways. The first one is my favourite one and it has the advantage of obscurity. The second one requires that you physically carry the key with you whenever you want to log in and unveils the fact that your home is encrypted.


I was recently given a macbook pro at work. I don't like it. I While I think that the hardware is still fine (even if apple's well know for their lousy hw, this laptop has a SSD, so the big problems of Apple's drives dying should be fixed), the software is trying to force me working its way and not the way I want.

On the other hand, I have been an OpenBSD user for years now, I buy the CDs etc. And I love the correctness of the project. But OpenBSD will not install well on the laptop.. I have tried also linux (even if I don't like it much), but it was as usual: random behaviour. They claim they support the hardware, but after a couple of lost days I found out that things were working randomly after a reboot. Sometimes they did, sometimes not. Probably the penguin is not ready or probably it's EFI (probably this "helped" too in the random behaviour).

While I wait that the brave OpenBSD developers write the code, I have to live with this "OS". But there are too many things I do not like. Specially the lack of privacy (why is apple store and itunes trying to constantly "communicate" with my laptop??), the stupid aqua interface and the lame "file encryption".

In this guide I provide you with a partial solution to some of these problems.


Because we can... and :

That looks like the sort of encryption ware that the police would

"We protect your data with AES-128 but protect your secret key
with rot13, for speed."

I like to use encryption ware that hasn't been hacked yet

Also, after a whole installation of the OS and a lof of software, I found out
that MacOSX defaults to a file system which is not case-sensitive!

I made a reinstall from scratch with care and realised that there's an option to
make it case-sensitive (is this a joke?)

And the best: when choosing this FS, FileVault cannot encrypt the drive because

"The home folder is located on a volume that isn’t in Mac OS Extended format"

And they call this user-friendly...


TrueCrypt seems to be the only possibility out there


In Snow Leopard (MacBook Pro 5,5)


# is the prompt for root
$ is the prompt for user
username in this example is (strange enough) "pau"
I will assume that FileVault is not being used on the system

My way (probably better than the next one and my favourite one)

Create a big truecrypt file, "example.img". Mine was of 175GB (took some 1.5 hours with AES-twofish algorithm and SHA-512 for the hash). I chose MacOS extended as the filesystem but it does not matter actually, and the "I will only mount this on MacOSX", but it does not matter either, since we're going to give it another format, case-sensitive

Once it is done, mount it

  sudo mkdir /Volumes/example_volume

  sudo truecrypt --text --verbose --filesystem=none \
  --protect-hidden=no -k "" \
  /Users/pau/example.img /Volumes/example_volume

As you might have gathered, I do not like GUIs. Read the man of truecrypt to find out what I am doing here

Now go to disk utility and format the bitch on the left, the volume.dmg to : "Erase" tab and and Mac OS Extended (Case-sensitive, Journaled)

A new item should have popped up on the left, "Untitled"

Now unmount the thing by clicking on the right (find your way with the showy one-buttom apple pad!).

And unmount it from truecrypt.

  gumby% sudo truecrypt --text --dismount /Users/pau/example.img

Mount it again from truecrypt

  sudo truecrypt --text --verbose --filesystem=none \
  --protect-hidden=no -k "" \
  /Users/pau/example.img \

  Enter password for /Users/pau/example.img:
  Volume "/Users/pau/example.img" has been mounted.

And attach it to a partition (i.e. mount it):

  /usr/bin/hdiutil attach /tmp/.truecrypt_aux_mnt1/volume.dmg \
  -readwrite -owners on -mountpoint \

And verify that it is case-sensitive:

  gumby% cd /Volumes/example_volume
  gumby% ls
  gumby% touch Hello hello
  gumby% ls
  Hello hello


Now you restore your data into the volume and then make your life simpler by using two scripts. One to mount it, one to unmount it.

In the first script we will also link all sensitive data from the mounted volume to our home directory, so that we can work normally. In the second one, after unmounting the volume, we delete the links... we do not want to leave hints, do we.

Of course, you can be original about where you decide to locate the encrypted file:

  gumby% cat
  # Definitions

  # Do it
  sudo mkdir $volume
  sudo $truecrypt --text --verbose --protect-hidden=no -k "" $file_tc $volume

  # Link the stuff
  ln -s $volume/* $home

  gumby% cat
  # Definitions

  # Do it
  sudo truecrypt -t -d $file_tc

  # Make sure we do not leave any hints
  rm $home/link1 \

This has the advantage that whilst your sensitive data will be protected, the "normal" stoopid mac stuff will still be in your home directory, so that nobody will notice that something is "missing".

More interestingly, in your .xinitrc you can define where your "new" $HOME is:


This means that X11 is told to take /Volumes/where/you/want/to/mount/it as your new home, instead of /Users/username!

Therefore, when you e.g. type "cd" in the terminal, you will end in the encrypted file, and your X programmes will store their hidden "." configuration files there, too...

I have also found out that you can tell the whole KDE environment to behave like that. I personally dislike KDE a lot (but compared to aqua is heaven... I am talking of kde 3.5, no compiz annoying things), but this is sure an advantage. All of your konqueror history (as compiled from macports) and cache (!!!) will be stored in the encrypted file. For that, parse the following option to .xinitrc:

  exec $SHELL -l -c /opt/local/bin/startkde

Also, take into account that some programmes, like pidgin or epiphany, allow you to store the config files and history in a different location. In the case of pidgin and epiphany, just use

  pidgin --config /Volumes/where/you/want/to/mount/it/.purple
  epiphany --private-instance --profile /Volumes/where/you/want/to/mount/it/.gnome2/epiphany

As for firefox, you can simply define a new profile

  /Applications/ -P

Use a folder in the encrypted file to store it. When the file is unencrypted, everything will work as usual. If your file is encrypted and somebody launches firefox, it will look as if it was the first one that it is been launched. It will ask you whether you want to import the safari bookrmarks etc...

While Apple claims to play fair etc, I have a very warm, nice feeling to know that Apple will know nothing about all of my surf and chat history (but then, if you are using gtalk, forget about any privacy)

If you are using this trick, then and should read

  # Definitions

  # Do it
  sudo mkdir $volume
  sudo $truecrypt --text --verbose --protect-hidden=no -k "" $file_tc $volume

  # Start our secret life in X

  ln -s $volume/xinitrc_kde_macosx \

  # Definitions

  # Do it
  sudo truecrypt -t -d $file_tc
  # Keep our X-identity secret!

  rm -f /Users/pau/.xinitrc

I am now using another approach: I do use aqua but only X applications on it, with a firefox profile living in the encrypted file, and my and look pretty different, but then you are free to come up with your own scenario.

At shutdown, the shutdown routine will deconfigure the tc and dismount the filesystems mounted on $volume

This allows you to lead two parallel lifes: In one you are a stoopid macosx user who has a history in safari and a couple of pdf in your /Users etc... then you have your personal life in X (kde). It's a bit like being Klark Klent and Superman :)

Manual deconfiguration (Caramba! The Secret Police are elbowing their way through the cyber cafe waving guns and shouting in coarse, bestial language). You quickly type:


System is then secure. Later, in the cellar of the Commissariat of Love, you may decide to share the password with the nice man with the Taser, but that's a different problem.

A clever lad might have those commands in a cron job requiring the user to touch a file of magickal name every ten minutes, (or ten seconds for delicate work) or they are executed. But this is getting a little Hollywoodish.

Second way (based on a page by Sebastian Köttinger)

Step 1

We love the command line :

  # ln -s /Applications/ /usr/local/bin/tc

We'll be using a flash pen to decrypt /Users/pau WITHOUT a password.
(paranoia ist great)

The last point is extremely important, because the way of encrypting your /Users I will describe now does only work if you use a keyfile, without a password.

This is so because the tricky part of this guide is that we'll be using something called the loginhook and logouthook of apple, which allows you to run a script before anything else happens when logging in and out of a session, but that has to happen without any interaction from your side. Since typing a password would require that, we have to use the keyfile and leave the encryption without a password.

For this, mount a flash drive which in my case has been formatted as vfat for historical reasons
(useful for sharing with OpenBSD, linux and mac computers and windows users).

It is called in my case "256MB":

Create a randomised file, the key for TrueCrypt to mount the encrypted file:

  # dd if=/dev/random of=/Volumes/256MB/.tc/keyForHome.img count=1 bs=4096

4kB = 4096 Byte = 32768 Bit -- This is enough, because the encryption is "only" 256 Bit

Create now a TrueCrypt volume home.pau.img and use a Keyfile the keyForHome.img...
I have used the GUI because it's easier to generate random numbers with  the mouse than the 320 characters.

My volume is of 120GB and it took it some 55 minutes on a SSD drive with plenty of RAM (8GB).
Probably on a hard "spinning" drive with less RAM it'll take much longer.

Once it's done, move it to /Users and mount it:

  # mv /Users

  # tc -t --filesystem=none /Users/

Now we have to give the volume a new HFS+ partition (please case-sensitive!) with "Disk Utility"

At that moment a new icon will automagically (I hat this word) pop up in the Desktop: It's the new "disc". Unmount it.

We will also have to unmount the truecrypt volume:

  # tc -t -d /Users/

Then we mount it like this (note the "non-interactive" part, that's crucial and the reason why this will not work if you have to be prompted for a password) :

  # tc - t --filesystem=none --non-interactive -v -k /Volumes/256MB/keyForHome.img /Users/ 
 Volume "/Users/" has been mounted.

Assign it a mount point on the table:

  # /usr/bin/hdiutil attach /tmp/.truecrypt_aux_mnt1/volume.dmg \
                  -readwrite -owners on -mountpoint /tmp/tc_pau

and copy all of our home directory into it after setting the right permissions

  # chown -R pau /tmp_tc_pau
 $ cp -Rp /Users/pau /tmp/tc_pau
 $ rm -rP /Users/pau

Umount everything:

  # hdiutil detach /tmp/tc_pau
 # tc -t -d /Users/

And then purge your home carefully with -P
(man rm ... you'll realise that the userland has been taken from a BSD) :

     "-P  Overwrite regular files before deleting them.  Files are overwritten three times,
         first with the
byte pattern 0xff, then 0x00, and then 0xff again, before they are

  # rm -rP /Users/pau

Now you wil have to copy the three following files to the correct place:

  # cp loginhook logouthook /Library/Management

to your needs

 # loginhook
 /Library/Management/ start $1

 # logouthook
 /Library/Management/ stop $1


 StartService() {


 $PATHTOTC -t --filesystem=none --non-interactive -v -k $KEYFILEMOUNTDIR$KEYFILEPATH $TCIMAGEPATH >> $LOGPATH/tc.log

 /usr/bin/hdiutil attach /tmp/.truecrypt_aux_mnt1/volume.dmg -readwrite -owners on -mountpoint $TCIMAGEMOUNTPATH >> $LOGPATH/tc.log




 StopService() {
  /usr/bin/hdiutil detach -force $TCIMAGEMOUNTPATH >> $LOGPATH/tc.log
  $PATHTOTC -t -v -d $TCIMAGEPATH >> $LOGPATH/tc.log


 echo >> $LOGPATH/tc.log

 if [ "$2" = "$USERNAME" ]
 echo "`date`: $2, $1" >> $LOGPATH/tc.log
 case "$1" in
  "start") StartService;;
  "stop") StopService;;

And tell your showy mac what it should do next time it boots:

  # defaults write LoginHook /Library/Management/loginhook
 # defaults write LogoutHook /Library/Management/logouthook

And a couple of final suggestions...

  $ defaults write FocusFollowsMouse -string YES
    $ defaults write wm_ffm -bool true
    $ defaults write no-glass -boolean YES
    $ defaults write _FXShowPosixPathInTitle -bool YES
    $ defaults write org.x.X11 wm_click_through -bool true
    $ defaults write org.x.X11 app_to_run /usr/bin/true

Have a look at

To conclude, if you do not want to commit suicide waiting for the cursor to think faster than a macuser, I recommend you to set this option to the maximum:

Last modified on Apr 10/2010 by Pau Amaro-Seoane             (Please be sure to read the LEGAL NOTICE)