Mounting a LUKS Encrypted Data Partition at Boot

This guide covers how to set up a secondary LUKS-encrypted partition as a data drive that is automatically unlocked and mounted when Alpine Linux boots. This is useful if, for example, you have a root partition on one drive and want an encrypted data partition on another — or if you simply want a separate encrypted volume for personal data.

Prerequisites

A spare partition (this guide uses /dev/sda1 as an example)
cryptsetup installed: doas apk add cryptsetup
An Alpine system using OpenRC (the default)

1. Set Up the LUKS Container

If you are starting with a fresh or existing partition, format it as a LUKS container. This will erase all data on the partition.

doas cryptsetup luksFormat /dev/sda1
doas cryptsetup luksOpen /dev/sda1 data
doas mkfs.ext4 /dev/mapper/data
doas cryptsetup luksClose data

2. Create a Keyfile for Automatic Unlocking

A keyfile allows the partition to be unlocked at boot without a passphrase prompt. The keyfile itself is stored on your root partition, so it is protected by whatever encryption or access controls that partition has.

doas dd if=/dev/urandom of=/etc/crypto_keyfile.bin bs=512 count=1
doas chmod 600 /etc/crypto_keyfile.bin
doas cryptsetup luksAddKey /dev/sda1 /etc/crypto_keyfile.bin

Your original passphrase remains as a fallback for manual unlocking.

3. Create the Mount Point

doas mkdir -p /mnt/data

4. Add an fstab Entry

Add the following line to /etc/fstab:

/dev/mapper/data    /mnt/data    ext4    defaults,nofail    0    2

The nofail option ensures that if the device or keyfile is missing for any reason, the system will still boot.

5. Create an OpenRC Init Script

Alpine's OpenRC does not process /etc/crypttab by default. The root partition's LUKS container is typically unlocked via kernel parameters (cryptroot, cryptdm) in the initramfs, not via crypttab. For additional encrypted partitions, you need a custom init script to handle both the unlock and the mount.

Create /etc/init.d/cryptdata with the following contents:

#!/sbin/openrc-run
description="Unlock and mount LUKS encrypted data partition"

RC_NEEDED="modules lvm"
RC_AFTER="modules lvm"
RC_BEFORE="local"

start() {
    ebegin "Unlocking /dev/sda1"
    cryptsetup luksOpen /dev/sda1 data --key-file /etc/crypto_keyfile.bin
    eend $?

    ebegin "Mounting /mnt/data"
    mount /dev/mapper/data /mnt/data
    eend $?
}

Why both unlock and mount in the script?

The RC_BEFORE="local" directive is intended to make this script run before OpenRC processes fstab mounts. In practice, the timing is not always reliable, and the mount in fstab may be attempted before the LUKS container is open. Putting the mount directly in the init script guarantees the correct order: unlock first, then mount.

Dependencies

RC_AFTER="modules lvm" — ensures kernel modules and LVM volumes are available before this script runs.
RC_BEFORE="local" — requests that this script runs before the local service, which is where general fstab mounts are processed.

6. Enable the Service

doas chmod +x /etc/init.d/cryptdata
doas rc-update add cryptdata boot

7. Test

Reboot and verify:

df -h | grep data
# Should show something like:
# /dev/mapper/data    219G    2.0M    208G    0%    /mnt/data

You can also confirm the LUKS container is active:

doas cryptsetup status data

Manual Unlock (Fallback)

If you ever need to unlock the partition by hand (e.g. the keyfile is missing), you can do so with your original passphrase:

doas cryptsetup luksOpen /dev/sda1 data
doas mount /dev/mapper/data /mnt/data