My failed attempt at using autofs to automount TrueCrypt volumes on OS X

I was trying to make it as easy as possible to access our YNAB file which lives in an encrypted TrueCrypt volume. The idea was to have OS X autofs automount the TrueCrypt volume so that when YNAB starts and attempts to load our document, TrueCrypt launches and asks for the password and then the volume mounts. I never got it working smoothly. I also tried sticking the password in the script, which is less than ideal, but that didn’t work either.

The following almost works, but not quite. If you can get it working, please let me know.

First, /etc/auto_master:

09:30:48 $ cat /etc/auto_master
# Automounter master map
+auto_master		# Use directory service
/net			-hosts		-nobrowse,hidefromfinder,nosuid
/home			auto_home	-nobrowse,hidefromfinder
/Network/Servers	-fstab
/-			-static
/auto			auto_truecrypt

Then /etc/auto_truecrypt (which is executable):

09:30:53 $ cat /etc/auto_truecrypt 



if [ "$1" == "Truecrypt" ]; then
    echo "-fstype=truecrypt    :${TRUECRYPT_VOLUME}"

And /sbin/mount_truecrypt:

09:30:58 $ cat /sbin/mount_truecrypt 

echo "$0: Called with $@" >> /dev/ttys000
# echo open -W /Applications/ --args "$7" "$8" >> /dev/ttys000
# open -W /Applications/ --args "$7" "$8"
echo /Applications/ --text --non-interactive --password=(password) "$7" "$8" >> /dev/ttys000
/Applications/ --text --non-interactive --password=(password) "$7" "$8"

As is, when I have the script calling /Applications/ with a password, I get:

$ cd /auto/Truecrypt
(Mac locks up with spinning beach ball)

The script actually locks up my MacBook Pro with OS X 10.6.8. The script is probably called in a kernel context or with some big lock and trying to launch a complex userland process from there creates some kind of deadlock. Well, that’s my guess anyway. So be careful — don’t try this if you’re not ready to reboot.