Mounting Truecrypt Volumes by Disk ID

Are you using scripts to mount your Truecrypt drives? Do the device paths seem to mix up randomly upon each system boot which confuses your scripts? Here is a technique to make sure each Truecrypt encrypted drive mounts in the correct mount point using disk identifiers to specify drives.

The Problem

It happens. Connecting a new USB device or installing another hard drive can cause the device paths to switch around for inexplicable reasons. What was once /dev/sda is now /dev/sdb, and this can cause Truecrypt volumes to mount in the wrong mount points if you are using scripts to automate the process. This also confuses other scripts dependent upon drives mounted in specific mount points.

Normal Mounting

A Truecrypt volume normally mounts by specifying its device path followed by a mount point.

truecrypt /dev/sda /media/mountpoint

But if /dev/sda refers to a different drive because the drive cables were swapped around or a new drive was installed, this can be a problem. Isn’t there a way to refer to the drive specifically no matter what its device path may be?

Using UUID

UUID (Universally Unique Identifier) is a 128-bit value that uniquely identifies a drive. Each hard drive and USB device connected to the computer has its own UUID. The blkid command will list them.

sudo blkid

You can use this UUID to refer to the drive no matter what its device path may be. If a hard drive is normally /dev/sda, then it does not matter if it changes to /dev/sdb or /dev/sde3. Using the UUID always refers to the specific drive.

“Why not use the UUID to mount Truecrypt volumes?”

In theory, Truecrypt will mount by UUID, but in practice, it is useless because the UUID of a Truecrypt volume is not available until after the Truecrypt volume is mounted. So, mounting by UUID will not work.

Using the Disk Identifier (Disk ID)

The command sudo fdisk -l shows a list of detected drives along with extra information for each. Among this information is a disk identifier. Each drive has a disk ID as the last consecutive line of its six-line information block.

sudo fdisk -l

Sample fdisk output:

Disk /dev/sda: 200 GB, xxxxx bytes
xx heads, xx sectors/track, xxxx cylinders
Units = cylinders of xxxx * xxxx = xxxx bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xa52f2c38

Disk /dev/sda doesn't contain a valid partition table

The disk ID is unique to each drive, and it is available whether the Truecrypt volume is mounted or not. Of course, this assumes that the entire drive is a Truecrypt volume.

We can use the device identifier to refer to a specific drive and mount it no matter what its device path may be. Whether a hard drive is located at /dev/sda or /dev/sdb, its device ID obtained from sudo fdisk -l will remain the same. All we need to do is write a Bash script that extracts the device path from its associated disk identifier block and use that device path to mount the Truecrypt volume.

The Script


# Run this script as root to avoid entering the root password twice


# Generate tempfile
sudo fdisk -l > $tempfile

# --------------------------------------------------------------------------
# Locate secret drive and mount it
# --------------------------------------------------------------------------
num=$[ $(grep -n "^Disk identifier: $secret" $tempfile | cut -f1 -d:) - 5 ]
if [ $num \> 0 ] # num will be greater than 0 if drive exists

 # Get line containing /dev
 # ----------------------------------------------------------------------
 dev=$(sed -n "${num}p" $tempfile | cut -f2 -d' ' | sed 's/://')
 truecrypt $dev /media/secret

# Check
# ----------------------------------------------------------------------
 if [ ! -f /media/secret/secret ]
   zenity --error --text="There was a problem mounting secret"

rm $tempfile


In the line if [ $num \> 0 ], be sure to escape the > using \> or else Bash will interpret the > as a redirection operator and create a file named 0.

The sudo in sudo fdisk -l > $tempfile might seem redundant, but including it anyway makes it clear what the line is intended to do (fdisk needs sudo in order to dump all drive information), and it ensures that fdisk returns the proper information if the script executes without root privileges.

How It Works

1. Dump the contents of sudo fdisk -l to a temporary file for processing

2. Discover which line contains the desired disk ID

3. The device path for the given disk ID is five lines up, so subtract 5 from the line number containing the disk ID. (If the resulting line is less than 0, then the Truecrypt volume is not found and the script does nothing.)

4. Extract the device path and store it in a variable

5. Mount Truecrypt using the discovered device path

6. Perform a check to ensure that the correct drive mounted to the correct mount point

7. Clean up by deleting the temporary file

Drive Check

How can we tell if the drive secret mounted to the mount point named secret? This requires some preparation beforehand by creating an empty file named secret in the root of the secret Truecrypt volume (sudo touch /media/secret/secret).

The drive check looks for a file name secret in the path. If the Truecrypt drive in this example mounted to /media/secret correctly, then the absolute path /media/secret/secret will be true. (A false return value check is performed to see if the secret file does not exist.) If secret is missing from the path, Zenity produces an error message. This is a convenience feature to help notify of possible errors before running any scripts that might rely upon the secret drive.

Other Notes

When running the script, a message like this might appear:

Disk /dev/sda doesn't contain a valid partition table

This is normal. Truecrypt volumes using whole disk encryption appear as unpartitioned drives.

After entering the system root password, Truecrypt will prompt for the volume password. Once the passphrase is entered correctly, the Truecrypt volume mounts.

If running the script from a Custom Application Launcher in the panel, in the Launcher Properties, set the Type to Application in Terminal and use include sudo in the Command path. Selecting only Application never allows time to enter the sudo password, which the script needs to continue.

The script may be modified to accommodate multiple Truecrypt drives.


The beauty of this technique is that many drives may be added to the system (hot-swapping, for example), yet the correct Truecrypt drive will always mount to its intended mount point. The device paths might change, but the disk IDs remain the same.

, , , ,

  1. #1 by imran-uk on July 15, 2012 - 9:27 PM

    Many thanks for this article – it provided a basis for me to create my own script to automate TrueCrypt mounts. Thought you and others might like to see:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: