How to Open and Unlock a LUKS Disk on Another Linux Machine

You pulled a LUKS encrypted drive from one machine—USB enclosure, spare SSD, or a disk moved after a failure—and need the files on a different Linux box. The partition still shows crypto_LUKS in blkid; nothing is readable until you install cryptsetup, open a device-mapper node, and mount the filesystem inside.

Typical rescue cases:

• Copy data off a laptop disk before reinstall.
• Read a USB backup on a desktop.
• Recover files when the original host will not boot (live ISO on the same machine).

This walkthrough unlocks an external-style volume on Ubuntu. The lab uses /dev/sdc1 on a 5 GiB virtual disk—the same device name as the encrypt a disk partition with LUKS guide, reformatted for this retest on July 2026. LUKS UUID e2e306a9-d94e-45d9-b209-4c9975fcede5; ext4 label secure-data inside. For command syntax in one place, see the cryptsetup command cheat sheet.

Tested on: Ubuntu 26.04 LTS (Resolute Raccoon); kernel 7.0.0-27-generic; cryptsetup 2.8.4

What you need

Before you plug in the disk, confirm you have:

Also:

• cryptsetup installed on the rescue host (or on the live ISO session).
• A LUKS header backup if the header may be damaged—do not run luksFormat on a disk you need to recover.

Quick reference

Pick a fresh mapper name (rescue_data in the lab). Avoid names already used on the host, such as ubuntu--vg-ubuntu--lv.

Install cryptsetup

On Ubuntu or Debian:

sudo apt update
sudo apt install -y cryptsetup

Confirm the binary is on your PATH:

cryptsetup --version

Sample output:

cryptsetup 2.8.4 flags: UDEV BLKID KEYRING FIPS KERNEL_CAPI HW_OPAL

Notes:

• Unlock and mount steps are the same on Fedora and other Linux hosts—install cryptsetup with your distribution package manager when apt is not available.
• Many Ubuntu and Fedora live images already ship the package.
• On a minimal rescue image, enable networking and install from repositories before attaching the encrypted disk.

Identify the LUKS partition

Plug in the USB disk or attach the moved drive, then list block devices:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL

Look for a part line with crypto_LUKS under the expected size and model:

sdc                           5G disk                              VBOX HARDDISK
└─sdc1                        5G part  crypto_LUKS

Filter LUKS signatures directly:

sudo blkid -t TYPE=crypto_LUKS

Sample output:

/dev/sdc1: UUID="e2e306a9-d94e-45d9-b209-4c9975fcede5" TYPE="crypto_LUKS" PARTLABEL="primary" PARTUUID="b2ec5a76-8585-4e6b-9926-3ca5094fcea1"

Read the LUKS container UUID alone:

sudo cryptsetup luksUUID /dev/sdc1

Sample output:

e2e306a9-d94e-45d9-b209-4c9975fcede5

What the fields mean:

• UUID= in blkid — LUKS container UUID (use as UUID=<uuid> device parameter or in /dev/disk/by-uuid/… paths).
• Not the ext4 filesystem UUID inside—you get that from blkid on the mapper after open.
• You need the LUKS passphrase or key file from the machine that created the volume.

Open by device path

Choose an unused mapper name and run cryptsetup open on the LUKS partition:

sudo cryptsetup open /dev/sdc1 rescue_data

Enter the passphrase when prompted. Verify the mapper exists:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT /dev/sdc

Sample output:

NAME            SIZE TYPE  FSTYPE      MOUNTPOINT
sdc               5G disk
└─sdc1            5G part  crypto_LUKS
  └─rescue_data   5G crypt ext4

The crypt line under sdc1 is the decrypted mapper—ready to mount.

Check the inner filesystem type:

sudo blkid /dev/mapper/rescue_data

Sample output:

/dev/mapper/rescue_data: LABEL="secure-data" UUID="9a2a62ff-52cb-4974-97cc-9581100b978e" BLOCK_SIZE="4096" TYPE="ext4"

Wrong passphrase test (mapper is not created)—lab automation only; do not put real passphrases in shell commands (see note below):

sudo cryptsetup close rescue_data
printf '%s' 'wrongpass' | sudo cryptsetup open /dev/sdc1 rescue_data --key-file=-

Sample output:

No key available with this passphrase.

Re-open with the correct passphrase before mount:

sudo cryptsetup open /dev/sdc1 rescue_data

Type the passphrase at the interactive prompt. For real rescue work, prefer that prompt over piping secrets into --key-file=-—passphrases in shell commands can remain in shell history or terminal scrollback. The printf pattern above is for lab automation only.

Open by LUKS UUID

cryptsetup open does not use a separate --uuid flag. You can pass the LUKS UUID as the device parameter in UUID=<uuid> form (documented in cryptsetup(8)), or open through the stable udev symlink.

Close any existing mapper on that volume first:

sudo cryptsetup close rescue_data

Option A — UUID= device parameter

sudo cryptsetup open UUID=e2e306a9-d94e-45d9-b209-4c9975fcede5 rescue_data

Verified on cryptsetup 2.8.4 with the lab disk above.

Option B — /dev/disk/by-uuid/ path

Confirm the symlink points at your partition:

ls -l /dev/disk/by-uuid/e2e306a9-d94e-45d9-b209-4c9975fcede5

Sample output:

lrwxrwxrwx 1 root root 10 Jul  5 22:55 /dev/disk/by-uuid/e2e306a9-d94e-45d9-b209-4c9975fcede5 -> ../../sdc1

Open through that path:

sudo cryptsetup open /dev/disk/by-uuid/e2e306a9-d94e-45d9-b209-4c9975fcede5 rescue_data

Both options avoid relying on changing /dev/sdX names when the disk renumbers on the rescue host.

Unlock with a key file (either device form):

sudo cryptsetup open --key-file=/path/to/keyfile \
  UUID=e2e306a9-d94e-45d9-b209-4c9975fcede5 rescue_data

Store key files with restrictive permissions (chmod 600) and prefer a dedicated path—not your shell history.

If the source host used auto-mount at boot, the passphrase or key file is the same one crypttab references—not necessarily the host OS login password.

Open Clevis Tang-bound disks on a rescue host

When the disk was bound with network-bound disk encryption (Clevis and Tang), a passphrase slot may still exist, or you may rely on Tang policy.

On the rescue machine:

• Install clevis and clevis-luks.
• Ensure the host can reach the Tang server URL from the bind (not 127.0.0.1 unless Tang runs on that rescue host).
• Run sudo clevis luks unlock -d /dev/sdc1 -n rescue_data instead of plain cryptsetup open when only the Clevis slot is available.

If a passphrase slot remains, cryptsetup open still works without Clevis or Tang.

Mount read-only when rescuing data

If the disk may be failing, or you only need to copy files off a machine that will not boot, mount read-only first. That avoids accidental writes while you inspect or rsync data.

sudo mkdir -p /mnt/rescue-data
sudo mount -o ro /dev/mapper/rescue_data /mnt/rescue-data

Use a normal read-write mount only when you trust the disk and need to modify files:

sudo umount /mnt/rescue-data
sudo mount /dev/mapper/rescue_data /mnt/rescue-data

Mount the filesystem (ext4 / xfs)

After cryptsetup open, check what sits inside the mapper—not every LUKS volume is a plain ext4 filesystem.

sudo blkid /dev/mapper/rescue_data

On the lab disk the type is ext4. Create a mount point and mount the mapper—not /dev/sdc1:

sudo mkdir -p /mnt/rescue-data
sudo mount /dev/mapper/rescue_data /mnt/rescue-data

Confirm the mount:

mount | grep rescue_data

Sample output:

/dev/mapper/rescue_data on /mnt/rescue-data type ext4 (rw,relatime)

Check free space and list files:

df -h /mnt/rescue-data
ls -la /mnt/rescue-data

Sample output:

Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/rescue_data  4.9G  1.3M  4.6G   1% /mnt/rescue-data
total 28
drwxr-xr-x 3 root root  4096 Jul  5 22:55 .
drwxr-xr-x 4 root root  4096 Jul  5 22:56 ..
-rw-r--r-- 1 root root    14 Jul  5 22:55 lab-check.txt
drwx------ 2 root root 16384 Jul  5 22:55 lost+found

Read the marker file:

cat /mnt/rescue-data/lab-check.txt

Sample output:

rescue lab ok

Filesystem notes:

• Use the TYPE from blkid /dev/mapper/rescue_data—ext4, xfs, or LVM2_member (see LVM section below).
• For xfs: sudo mount -t xfs /dev/mapper/rescue_data /mnt/rescue-data.

Copy files with rsync, cp, or your file manager.

Mount LVM volumes inside a LUKS disk

Many Linux installations—especially older root layouts—use LVM inside LUKS: disk → partition → LUKS → LVM physical volume → logical volumes (root, home, swap).

After cryptsetup open, check the mapper type:

sudo blkid /dev/mapper/rescue_data

If you see TYPE="LVM2_member", the mapper is not the final filesystem. Mounting it directly often fails with unknown filesystem type 'LVM2_member'.

Install LVM tools and activate volume groups:

sudo apt install -y lvm2
sudo vgscan
sudo vgchange -ay
sudo lvs

Sample output (names vary by source machine):

LV   VG        Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root vgubuntu  -wi-a-----  <size>
  swap vgubuntu  -wi-a-----  <size>

Mount the logical volume that holds your data—not the LUKS mapper:

sudo mkdir -p /mnt/rescue-data
sudo mount -o ro /dev/vgubuntu/root /mnt/rescue-data

Replace vgubuntu/root with the VG/LV names from lvs. Use -o ro for rescue copies when you do not need to write.

When finished, unmount the LV, deactivate the source volume group, then close LUKS:

sudo umount /mnt/rescue-data
sudo vgchange -an vgubuntu
sudo cryptsetup close rescue_data

Replace vgubuntu with the source disk's VG name from sudo lvs or sudo vgs. Avoid plain vgchange -an on a normal rescue host because it may try to deactivate other active volume groups on that machine.

Moved disks with LUKS root often follow this pattern—see encrypt root with LUKS for how the source system was laid out.

Close and disconnect

Unmount before closing the mapper so the kernel flushes pending writes:

sudo umount /mnt/rescue-data

Close the mapper:

sudo cryptsetup close rescue_data

Verify only the encrypted container remains:

lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINT /dev/sdc

Sample output:

NAME   TYPE FSTYPE      MOUNTPOINT
sdc    disk
└─sdc1 part crypto_LUKS

You can safely remove the USB device or move the disk to another machine.

Live ISO and rescue environments

Ubuntu, Fedora, and most installer ISOs boot a full desktop or shell where you repeat the same steps: terminal → identify disk → open → mount under /mnt → copy data.

Workflow on a live session:

1. Boot the ISO and choose Try without installing.
2. Attach the encrypted disk; wait for udev to create /dev/disk/by-uuid/… nodes.
3. Install cryptsetup if cryptsetup: command not found.
4. Follow identify → open → mount above.
5. Copy rescued files to another USB stick or network storage on the live system.
6. Unmount, cryptsetup close, then shut down.

You do not need to edit /etc/crypttab on the rescue machine for a one-time copy—cryptsetup open is manual unlock only.

When the LUKS header is damaged but you have a header backup, see LUKS header backup and restore before forcing a format. luksFormat writes a new header and destroys access to existing data on the partition.

Troubleshooting

For header damage, use LUKS header backup and restore before destructive recovery attempts.

References

• cryptsetup FAQ (official)
• Ubuntu man page: cryptsetup(8)
• Linux kernel dm-crypt documentation

Summary

On the rescue Linux host, install cryptsetup, find the crypto_LUKS partition with lsblk and blkid, then cryptsetup open on /dev/sdX1, UUID=<luks-uuid>, or /dev/disk/by-uuid/<luks-uuid>. Mount ext4 on the mapper, or activate LVM and mount the logical volume when blkid shows LVM2_member. Prefer read-only mount for rescue copies. Unmount, deactivate LVM if used, and cryptsetup close before disconnecting. Clevis-bound disks need Tang reachability or a remaining passphrase slot.