How to Recover a LUKS Partition: Full Guide

Updated 14 November 2026 · Standard formula, shown below

This guide explains how to recover access to a LUKS-encrypted partition when you can’t unlock it, whether due to a forgotten passphrase, a corrupted LUKS header, or a system that won’t boot. You’ll learn how to diagnose the problem, use LUKS tools to restore the header or keyslot, and regain access to your data. Before starting, ensure you have backups of any critical data if possible, and work on a copy of the disk if you can, to avoid further damage.

What You’ll Need

A Linux system (live USB or another installed OS) with root access.
The cryptsetup package installed (most distros include it).
If recovering a header: a backup of the LUKS header (usually a file like luks-header-backup).
If you forgot a passphrase: any previously known passphrase or a key file that might still work.
Basic command-line familiarity and the device name of your encrypted partition (e.g., /dev/sda2).

Step-by-Step

Identify the encrypted partition. Run lsblk -f or blkid to list all block devices. Look for a partition with crypto_LUKS in the FSTYPE column. Note the exact device path (e.g., /dev/sdb1).
Check if the partition is already mapped. Run lsblk or cat /proc/mounts to see if the decrypted device (e.g., mapper/ entry) exists. If it does, you may just need to mount it. Otherwise, proceed.
Try to open the LUKS container normally. Use cryptsetup open /dev/sdX name (replace sdX with your partition and name with a chosen mapper name). It will prompt for a passphrase. If it succeeds, you can mount the mapped device (e.g., mount /dev/mapper/name /mnt). If it fails, continue to the next steps.
If the passphrase is wrong or forgotten: Try any other passphrases or key files you may have used. If you have a key file, use cryptsetup open --key-file /path/to/keyfile /dev/sdX name. If none work, you may need to recover from a header backup (step 6) or, if you have no backup, you may be stuck—LUKS is designed so that without a valid passphrase or keyslot, data is unrecoverable.
If the header is corrupted: First, check if the header is intact with cryptsetup luksDump /dev/sdX. If it fails or shows errors, you need to restore from a backup. If you have a backup file, use cryptsetup luksHeaderRestore /dev/sdX --header-backup-file /path/to/backup. This will overwrite the current header, so ensure the backup is from the same device and that you have no newer changes to the header (like added keyslots) that you need.
If you have no header backup but the header is partially damaged: Try cryptsetup luksHeaderRestore with a backup from a similar device? Not possible—each header is unique. Instead, you can attempt to use cryptsetup luksDump with the --dump-master-key option, but that requires a valid passphrase. Without a backup, header corruption is usually fatal unless you have a full disk image.
If the LUKS header is fine but the filesystem inside is corrupted: After opening the LUKS container, run fsck on the mapped device (e.g., fsck /dev/mapper/name) to repair filesystem errors. Be careful to unmount it first if it’s mounted.
If the system won’t boot and you suspect LUKS issues: Boot from a live USB, then follow the steps above to unlock the partition manually. Once unlocked, you can chroot into the system to fix bootloader or crypttab issues, or just mount and recover data.
After recovering access, back up your data immediately. Copy important files to an external drive. Then consider creating a fresh LUKS header backup with cryptsetup luksHeaderBackup /dev/sdX --header-backup-file /path/to/new-backup.

Common Mistakes

Using the wrong device path. Double-check that you’re operating on the LUKS partition, not the whole disk or a different partition.
Restoring a header backup from a different device. Each LUKS header contains a unique master key and salt; using a backup from another disk will make the data unrecoverable.
Overwriting a header that wasn’t corrupted. If you restore a backup over a working header, you might lose newer keyslots or changes. Always dump the current header first to see if it’s actually damaged.
Forgetting to unmount before fsck. Running fsck on a mounted filesystem can cause more damage. Always unmount first.
Not having a header backup. LUKS headers are small but critical. Without a backup, a corrupted header often means data loss.

Tips

Always create a LUKS header backup immediately after setting up encryption. Store it securely (e.g., on a USB stick) and update it whenever you change passphrases or keyslots.
Use a strong but memorable passphrase, and consider adding a second keyslot with a key file as a backup.
Test your recovery procedure on a spare disk to ensure you know the commands before you need them.
If you have a disk image (e.g., from dd), you can work on the image instead of the live disk to avoid accidental damage. Use losetup to attach the image as a loop device.
Keep a live USB with cryptsetup handy for emergency recovery.

Troubleshooting

cryptsetup open fails with “No key available with this passphrase.” This means the passphrase doesn’t match any keyslot. Try other passphrases or key files. If you have a header backup, you can restore it and then try again. If not, and you truly forgot the passphrase, the data is unrecoverable—LUKS has no backdoor.

luksDump shows “Device /dev/sdX is not a valid LUKS device.” This indicates the header is missing or severely corrupted. Restore from a backup if you have one. If not, you might try cryptsetup luksHeaderRestore with a backup from the same disk if you made one earlier. Without that, recovery is unlikely.

After restoring the header, the passphrase still doesn’t work. The header backup might be from an older state where the passphrase was different. You’ll need to use the passphrase that was valid at the time of the backup. If you have multiple backups, try them in order.

The mapped device appears but mounting fails with “wrong fs type.” The LUKS container opened, but the filesystem inside might be corrupted or not recognized. Run fsck on the mapped device, or check if it’s an LVM or other volume that needs further activation.

You accidentally overwrote the header with a wrong backup. If you have a full disk image, you can extract the original header from that image. Otherwise, if you have a newer backup, restore that. If not, you may have lost the ability to decrypt the data.

Frequently Asked Questions

Can I recover a LUKS partition without the passphrase? No, by design. LUKS uses strong encryption; without a valid passphrase or key file, there is no way to decrypt the data. The only exception is if you have a master key dump, but that requires a passphrase to obtain.

What is a LUKS header backup and why is it important? The LUKS header contains the encryption metadata, including the master key (encrypted with your passphrase). If it’s corrupted, you can’t unlock the partition. A backup allows you to restore the header and regain access.

How do I create a LUKS header backup? Use cryptsetup luksHeaderBackup /dev/sdX --header-backup-file /path/to/backup. Store it securely, as it contains sensitive information.

Can I recover a LUKS partition if the header is completely gone? Only if you have a full disk image taken before the header was lost. You could try to extract the header from the image using forensic tools, but it’s complex and not guaranteed. Without any backup, it’s essentially impossible.

What should I do if I forget my LUKS passphrase? Try any other passphrases or key files you might have used. If you have a header backup, you can restore it and use the passphrase that was valid at that time. Otherwise, the data is unrecoverable.

Is it safe to run fsck on a LUKS-encrypted partition? You should run fsck on the decrypted device (e.g., /dev/mapper/name), not on the raw encrypted partition. Always unmount the filesystem first, then run fsck.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.