$linuxjunkies
>

Linux Disk Encryption Strategies

A practical guide to Linux disk encryption: full-disk LUKS2, encrypted /home partitions, kernel-native fscrypt, and file-level tools age and gocryptfs.

IntermediateUbuntuDebianFedoraArch11 min readUpdated June 7, 2026

Before you start

  • Root or sudo access on the target system
  • cryptsetup 2.1 or later installed (provides LUKS2 support)
  • A backup of any data on partitions you intend to encrypt
  • Basic familiarity with Linux partition layout and /etc/fstab

Encrypting data at rest on Linux ranges from whole-disk protection during boot to lightweight per-directory encryption for shared servers. This guide covers the four main strategies: full-disk LUKS2 encryption, LUKS on a dedicated home partition, kernel-native fscrypt, and file-level tools age and gocryptfs. Pick the approach that matches your threat model — they are not mutually exclusive.

Understanding the Strategies

Each approach protects against a different attacker. LUKS full-disk encryption (FDE) stops someone who steals your powered-off laptop. Per-home LUKS protects user data from other local users and physical theft. fscrypt integrates with the VFS layer and is especially useful on multi-user servers or Android-derived systems. File-level tools like age and gocryptfs encrypt individual files or virtual filesystems, useful for cloud storage, backups, or selectively protecting sensitive directories without re-partitioning.

Strategy 1: Full-Disk Encryption with LUKS2

LUKS2 is the current standard, replacing LUKS1. It supports Argon2id for key derivation (much stronger than PBKDF2), detached headers, and hardware token unlock. Most modern Linux installers offer FDE during setup — prefer that over post-install conversion, which is risky without a full backup.

Installing on a New Disk (Manual)

The following example formats /dev/sdb. Substitute your device. This destroys all data on the target.

# Wipe existing signatures
wipefs -a /dev/sdb

# Create LUKS2 container with Argon2id
cryptsetup luksFormat --type luks2 \
  --cipher aes-xts-plain64 \
  --key-size 512 \
  --hash sha512 \
  --pbkdf argon2id \
  /dev/sdb
# Open the container
cryptsetup open /dev/sdb cryptdata

# Create a filesystem inside
mkfs.ext4 /dev/mapper/cryptdata

Adding a Recovery Key

LUKS2 supports up to 32 key slots. Always add a second passphrase or keyfile as a recovery option.

# Add a second passphrase (slot 1)
cryptsetup luksAddKey /dev/sdb

# Or add a keyfile
dd if=/dev/urandom of=/root/luks-recovery.key bs=512 count=1
cryptsetup luksAddKey /dev/sdb /root/luks-recovery.key

Configuring /etc/crypttab for Boot Unlock

For a root or data partition that must unlock at boot, add an entry to /etc/crypttab. On Debian/Ubuntu dracut or initramfs-tools, and on Fedora/RHEL dracut, this file is read during early userspace.

# Get the UUID of the LUKS device
cryptsetup luksUUID /dev/sdb
# /etc/crypttab entry format:
# name       device-UUID                            keyfile   options
cryptdata   UUID=<paste-uuid-here>   none      luks,discard

Use none for interactive passphrase at boot. Replace with a keyfile path for automated unlock. The discard option enables TRIM on SSDs — acceptable for most use cases, but know it leaks which sectors are in use.

Verifying LUKS2 Status

cryptsetup luksDump /dev/sdb

Confirm Version: 2, PBKDF: argon2id, and that only the expected key slots are active.

Strategy 2: Encrypted Home Partition

If the OS partition is already set up and you want to encrypt only user data, create a dedicated LUKS2 partition for /home. This is simpler than FDE retrofits and keeps the system bootable without a passphrase, requiring unlock only at login.

# Assuming /dev/sdb1 is your designated home partition
cryptsetup luksFormat --type luks2 /dev/sdb1
cryptsetup open /dev/sdb1 crypthome
mkfs.ext4 /dev/mapper/crypthome

# Mount and populate with existing home data
mount /dev/mapper/crypthome /mnt/newhome
rsync -aAX /home/ /mnt/newhome/
# Update /etc/fstab
echo '/dev/mapper/crypthome  /home  ext4  defaults  0 2' >> /etc/fstab

# Update /etc/crypttab for PAM-based auto-unlock at login
# (pam_mount can pass the login passphrase to cryptsetup)
echo 'crypthome  UUID=<uuid>  none  luks' >> /etc/crypttab

For PAM passphrase forwarding, install libpam-mount (Debian/Ubuntu) or pam_mount (Fedora) and configure /etc/security/pam_mount.conf.xml. This lets a single login passphrase unlock the LUKS volume transparently.

Strategy 3: fscrypt (Kernel-Native Per-Directory Encryption)

fscrypt operates at the VFS layer, encrypting individual directories rather than block devices. It requires a filesystem with fscrypt support: ext4, f2fs, or UBIFS. The kernel handles encryption transparently once a directory is unlocked; no FUSE overhead is involved. This is the mechanism used by systemd-homed under the hood.

Installation

# Debian/Ubuntu
apt install fscrypt libpam-fscrypt

# Fedora
dnf install fscrypt

# Arch
pacman -S fscrypt

Setup

# Enable fscrypt on the filesystem (only once per filesystem)
fscrypt setup --all-users

# Tune2fs must confirm the filesystem supports encryption
tune2fs -l /dev/sda2 | grep encrypt
# Encrypt a directory — must be empty first
mkdir -p ~/private
fscrypt encrypt ~/private --source=pam_passphrase
# Lock and unlock manually
fscrypt lock ~/private
fscrypt unlock ~/private

With libpam-fscrypt installed and configured, directories using --source=pam_passphrase unlock automatically at login and lock on logout. Check /etc/pam.d/common-auth (Debian/Ubuntu) or the relevant PAM stack for the fscrypt module line after installation.

Checking Status

fscrypt status ~/private

Output shows the policy, encryption mode (AES-256-XTS by default), and whether the directory is currently locked or unlocked.

Strategy 4: File-Level Encryption

Block and filesystem-level encryption protect data at rest on the local machine. File-level tools protect individual files independent of where they land — useful for cloud sync, offsite backups, or sharing encrypted archives.

age: Simple, Modern File Encryption

age (stylised lowercase) uses X25519 or SSH keys and outputs a simple binary or armored format. It has no config files, no key rings, and intentionally limited options.

# Debian/Ubuntu (22.04+)
apt install age

# Fedora
dnf install age

# Arch
pacman -S age
# Generate a key pair
age-keygen -o ~/.age/key.txt
# Output: Public key: age1ql3z7hjy54fw3x5wx...  (will vary)
# Encrypt a file to a recipient public key
age -r age1ql3z7hjy54fw3x5wx... -o secrets.tar.gz.age secrets.tar.gz

# Encrypt with a passphrase (interactive)
age -p -o secrets.tar.gz.age secrets.tar.gz

# Decrypt
age -d -i ~/.age/key.txt -o secrets.tar.gz secrets.tar.gz.age

age is ideal for encrypting backup archives before sending them to S3, Backblaze, or any untrusted remote. Pipe it directly with tar c /data | age -r <pubkey> > backup.age.

gocryptfs: Encrypted FUSE Filesystem

gocryptfs mounts an encrypted directory as a transparent FUSE filesystem. It is well-audited, actively maintained, and a strong replacement for the deprecated encfs.

# Debian/Ubuntu
apt install gocryptfs

# Fedora
dnf install gocryptfs

# Arch
pacman -S gocryptfs
# Initialize an encrypted directory
mkdir ~/encrypted-store ~/plaintext-view
gocryptfs -init ~/encrypted-store
# Mount (prompts for passphrase)
gocryptfs ~/encrypted-store ~/plaintext-view

# Work with files normally in ~/plaintext-view

# Unmount when done
fusermount -u ~/plaintext-view

The ~/encrypted-store directory contains individually encrypted files — suitable for syncing with Dropbox, rclone, or rsync where you only want to re-upload changed files. With encfs now deprecated upstream, gocryptfs is the recommended drop-in replacement.

Comparing the Approaches

Method Granularity Threat addressed Overhead
LUKS2 FDE Whole disk Powered-off theft Minimal (AES-NI)
LUKS2 /home Partition Theft + local users Minimal
fscrypt Directory (VFS) Local users, per-directory Very low (in-kernel)
gocryptfs Directory (FUSE) Cloud/remote storage Low (FUSE)
age File/stream Backup, transfer None at rest

Troubleshooting

LUKS: Wrong passphrase / no key available

Run cryptsetup luksDump /dev/sdX to confirm active key slots. If you are locked out and have a keyfile backup, use cryptsetup open --key-file /path/to.key /dev/sdX name. Without any valid key, recovery is impossible — LUKS is working as intended.

fscrypt: Directory shows garbled filenames after reboot

The policy key was not re-injected. Run fscrypt unlock ~/private manually, or verify the PAM fscrypt module is in the correct position in your PAM stack (pam_fscrypt.so must appear in auth and session sections).

gocryptfs: "fuse: device not found" error

The FUSE kernel module is not loaded. Run modprobe fuse and confirm /dev/fuse exists. On hardened kernels, FUSE may be disabled — check CONFIG_FUSE_FS with zcat /proc/config.gz | grep FUSE.

TRIM and SSDs with LUKS

The discard flag in /etc/crypttab leaks which sectors hold data. For most desktop/laptop use cases this is an acceptable tradeoff for SSD longevity. On high-security systems omit discard and run periodic fstrim during maintenance windows instead.

tested on:Ubuntu 24.04Fedora 40Debian 12Arch rolling

Frequently asked questions

Can I add LUKS encryption to an existing partition without reinstalling?
Not in place — LUKS requires writing a header at the start of the device, destroying existing data. Back up, repartition, apply LUKS, restore data. Some installers offer online conversion but a fresh encrypted install is always safer.
What is the difference between LUKS1 and LUKS2?
LUKS2 adds Argon2id key derivation (much more resistant to GPU brute-force than PBKDF2 used in LUKS1), a more resilient binary header with a backup copy, detached header support, and up to 32 key slots. Use LUKS2 for all new volumes on kernels 3.17+ and cryptsetup 2.1+.
Does full-disk LUKS encryption protect a running system?
No. LUKS protects data when the system is powered off and the key is not in memory. Once the volume is unlocked at boot, the data is accessible to the running kernel. A live system can still be attacked via root exploits, DMA attacks, or cold-boot attacks on RAM.
Is encfs still safe to use?
encfs has not been actively maintained and had a security audit in 2014 that found several issues. Use gocryptfs instead — it was written specifically to address encfs weaknesses and has received a clean independent audit.
Can fscrypt and LUKS be combined?
Yes, and it is a reasonable layered setup. A LUKS-encrypted partition protects against offline theft, while fscrypt on top provides per-user directory isolation so one local user cannot read another's home directory even with root access bypassed at the filesystem level.

Related guides