A practical guide to LUKS encryption in elementary OS
Full-disk encryption is one of those settings that feels invisible until it matters. A notebook left on a train from Melbourne to Sydney, a desktop sent for repair in Brisbane or an older computer sold through a local marketplace can expose years of photos, work files and messages. elementary OS can protect that storage with a Linux Unified Key Setup (LUKS) container, provided the encryption and its keys are configured carefully.
This guide explains the practical choices for a new elementary OS installation, from selecting full-disk encryption to checking it after the first reboot. It also covers manual LUKS2 setup for experienced users and the recovery habits that keep encrypted data accessible. For day-to-day unlocking, “no worries” is a reasonable goal; the recovery key still deserves a proper plan.
What full disk encryption protects
Linux Unified Key Setup, usually called LUKS, is the Linux standard for encrypting block devices. LUKS stores a protected master key in metadata called a keyslot. At boot, cryptsetup uses your passphrase to unlock that key, and device mapper exposes the decrypted volume so the filesystem can be mounted. LUKS2 is the modern format and the appropriate choice for new installations.
Full-disk encryption is valuable when the threat is loss or theft. If someone removes the drive from an Australian home computer or powers up a stolen laptop without your passphrase, the encrypted filesystem remains unreadable. The boot partition may still be visible because the bootloader needs it, but that small area normally contains system files rather than personal documents.
It does not protect a running, unlocked system from someone who can use your session, nor does it replace a strong login password, updates or careful backup practice. Data copied to an unencrypted USB drive, cloud storage or an email account can still leak. Encrypting only a home directory may also leave swap and temporary files outside the protected area. Think of LUKS as protection for data at rest, not a shield around every running process.
Choosing encryption during installation
Start by checking the installer supplied with your elementary OS release. Where full-disk encryption is supported, the option appears alongside the erase-disk choices; exact wording differs between releases and installation methods. If the option is absent, do not assume that an existing home directory has been encrypted. Upgrading an unencrypted installation is a different process from selecting encryption during installation.
Before choosing an erase-and-install workflow, back up your files. That option removes existing partitions on the selected drive, including another operating system. Install into unallocated space if you intend to keep another system, but note that an encrypted Linux installation may require additional partition planning when sharing a disk with Windows or another distribution. The simplest full-disk setup usually involves giving the installer the entire disk.
Use a separate, strong disk passphrase rather than assuming your ordinary login password will do. The installer creates the encrypted volume and arranges for it to be unlocked before the desktop appears. It normally leaves the EFI System Partition, and sometimes a separate boot partition, unencrypted so the firmware can load the bootloader. This is normal and does not expose the encrypted home directory or root filesystem.
Setting up LUKS manually
Manual setup is for an experienced administrator working on the correct block device. A modern layout normally uses GPT, a separate EFI System Partition on a UEFI machine, a small BIOS boot partition where needed, and one or more Linux partitions for encrypted data. Create that layout before formatting a LUKS container. An installer handles the firmware-specific details more reliably than a short sequence of copied commands.
The following demonstrates the core encryption operations rather than a complete bootable installation:
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
sudo cryptsetup luksFormat --type luks2 /dev/sdX2
sudo cryptsetup open --type luks2 /dev/sdX2 cryptroot
sudo mkfs.ext4 /dev/mapper/cryptroot
Here, /dev/sdX2 is a placeholder for an actual partition on a SATA disk or NVMe drive. The formatting command destroys data on the selected partition, so check the lsblk output and confirm that it is not mounted. luksFormat creates the encrypted container, open creates the active decrypted mapping, and mkfs places a filesystem inside it.
That mapping still needs to be connected to the operating system. Record the LUKS UUID in /etc/crypttab, point /etc/fstab at /dev/mapper/cryptroot, ensure the initramfs contains the necessary cryptsetup support, and install the bootloader to the correct drive. From the installed system or a suitable chroot, rebuild the initramfs with update-initramfs -u -k all and refresh the bootloader configuration with update-grub. A missing initramfs mapping can leave a correctly encrypted disk that never opens at boot.
Do not reduce the key-derivation protection merely to make unlocking feel faster, and avoid copying an old container onto a disk without a migration plan. Different BIOS and UEFI layouts require different boot arrangements. For a first elementary OS installation, the graphical installer is usually the safer route.
Checking encryption and planning recovery
After installation, power the machine off completely and start it again. The boot screen should request the disk passphrase before the desktop or login screen appears. Then run lsblk -f, sudo cryptsetup status cryptroot and sudo cryptsetup luksDump /dev/sdX2. The first command should show the physical partition as crypto_LUKS and the decrypted mapping as crypt. The status command reports the active mapping, while luksDump reveals the header version and available keyslots without displaying your plaintext passphrase.
Two separate secrets are involved. The disk passphrase unlocks storage before login, while the desktop account password protects your user session. Store the disk passphrase in a password manager if it is long enough to be inconvenient, and never reuse it for an unrelated website. If the disk is unlocked but the desktop still requests a login, that is expected.
A typical elementary OS installation does not issue a separate universal recovery password. You can add a second LUKS keyslot with sudo cryptsetup luksAddKey /dev/sdX2, supplying the current passphrase and then a distinct recovery passphrase. Store that recovery credential away from the computer, perhaps in a password manager and an offline copy. Removing an old keyslot is possible only while another valid passphrase remains.
Back up the LUKS header when convenient with sudo cryptsetup luksHeaderBackup /dev/sdX2 --header-backup-file elementary-luks-header.bin. This helps with metadata damage but is not a replacement for a recovery passphrase. Back up actual user data as well. An encrypted partition image preserves ciphertext, while an exported archive needs its own encryption. A backup uploaded over a regional fixed-wireless or satellite connection can take much longer than one sent over a metropolitan NBN connection, so an encrypted copy on a separate drive can be a practical first step.
Keeping the encryption secure in daily use
Full-disk encryption is only as strong as its passphrase. A generated passphrase with five or more unrelated words is easier to type than a short complex password and far stronger than a familiar phrase. Let a password manager generate it, and keep it separate from the recovery credential if the manager also holds the latter. Do not rely on memory for the only copy.
Keep elementary OS, cryptsetup and the initramfs packages updated through normal system updates. Changes to kernel or bootloader files can affect how the encrypted root is unlocked, so resist copying old boot files between installations. Secure Boot, where supported, is a useful complementary control, but it does not encrypt the filesystem. Suspending a machine also leaves the encrypted volume unlocked in RAM; shutting it down provides the strongest at-rest protection.
Check swap and hibernation rather than assuming the installer covered every storage path. The swapon --show command reveals active swap devices, and the relevant entries in /etc/crypttab should show how encrypted swap is unlocked. A swap file created later may live outside the protected volume. If hibernation is enabled, its memory image needs the same encryption and passphrase protection.
For Australian organisations, full-disk encryption supports the data-at-rest control in the Australian Signals Directorate’s Essential Eight, but it is only one part of a sound setup. Patching systems, controlling privileged access, using multifactor authentication and maintaining recoverable backups remain necessary. For households and the second-hand computer market, a clean reinstall and removal of the old account are still needed when selling a machine. Encryption protects the old drive; it does not automatically sanitise flash storage.
The rule to remember is simple: encrypt the installation, protect the passphrase, escrow a recovery credential, and test the path back in. A missing key is not the kind of problem that “she’ll be right” can solve, because reinstalling elementary OS will not restore encrypted data.
LUKS makes a lost or exposed drive unreadable without its key. A checked recovery plan keeps that protection from becoming an outage, preserving both the security and the practical usefulness of the encrypted system.
