How to Encrypt a Disk Partition with LUKS in Linux

You added a second disk—a USB drive, an extra volume on a VM, or a new partition on a server—and you need the data encrypted at rest. Without encryption, anyone who removes the drive or clones the block device can read your files offline. LUKS is the standard answer on Linux: cryptsetup stores a passphrase-protected header on the partition, and the kernel decrypts blocks only while the volume is unlocked.

While the volume is locked, lsblk shows crypto_LUKS on the partition. After you run cryptsetup open, Linux exposes a mapper device (for example /dev/mapper/secure_data) that you treat like any other disk—mkfs, mount, and copy files there. The filesystem never sits directly on /dev/sdX1; it lives inside the encrypted mapper.

This guide walks through that end to end: partition the disk, run luksFormat, open the mapper, create ext4, and mount the volume.

The steps use /dev/sdc (disk) and /dev/sdc1 (partition) as example device names. On your system the letter will differ—always confirm with lsblk before running wipefs or luksFormat.

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

Quick reference

Examples below use /dev/sdc and /dev/sdc1. Replace them with your disk and partition from lsblk.

Step 1 — Install cryptsetup

First install the tool that talks to the kernel’s dm-crypt layer. Without it, none of the LUKS commands exist.

On Ubuntu or Debian:

sudo apt update
sudo apt install -y cryptsetup

The cryptsetup commands in the rest of this guide work the same on Fedora, Debian, and other Linux distributions; install the cryptsetup package with your distribution's package manager if you are not on Ubuntu.

More package flags are in the apt cheat sheet if you need them.

Check that you have a 2.x release (LUKS2 is the default there):

cryptsetup --version

Sample output:

cryptsetup 2.8.4 flags: UDEV BLKID KEYRING FIPS KERNEL_CAPI HW_OPAL

Step 2 — Identify your disk

Work on the whole disk you plan to partition (example: /dev/sdc), not a partition that belongs to your running system. List block devices and check size, model, and mount points:

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

Choose a row where TYPE is disk, MOUNTPOINT is empty, and the size matches the hardware you attached. Example output from a single empty data disk:

NAME   SIZE TYPE FSTYPE MOUNTPOINT MODEL
sdc      5G disk                   VBOX HARDDISK

Your device name and capacity will differ; trust size and model over the /dev/sdX letter. USB disks can change names after reboot—run lsblk again each session.

Step 3 — Create a partition

In this guide we create LUKS on a partition (/dev/sdc1 in the examples). You can also use LUKS directly on a whole block device in some setups, but a partition is easier to identify, resize, and document. Here we use one GPT partition spanning the full disk.

Clear old signatures, create the partition table, and rescan:

sudo wipefs -af /dev/sdc
sudo parted -s /dev/sdc mklabel gpt mkpart primary 1MiB 100%
sudo partprobe /dev/sdc

You should now see sdc1 under sdc:

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

Sample output:

NAME   SIZE TYPE FSTYPE PARTLABEL
sdc      5G disk
└─sdc1   5G part        primary

FSTYPE stays blank until Step 4. Prefer fdisk or gdisk? That works too—see partition a disk with parted.

Step 4 — Encrypt with LUKS2

luksFormat initializes a new LUKS header and key slots on /dev/sdc1. It does not overwrite the entire data area byte-for-byte, but any existing filesystem on that partition becomes practically inaccessible unless you still have the old header and keys. Treat the command as destructive and back up data before you run it.

sudo cryptsetup luksFormat --type luks2 /dev/sdc1

Type YES when prompted (uppercase on recent versions), then enter the passphrase twice. Pick a strong passphrase you can reliably type whenever you unlock the volume. For boot-time unlock, use the separate crypttab guide.

After format, the partition shows as LUKS:

lsblk -f /dev/sdc1

Sample output:

NAME FSTYPE      FSVER LABEL UUID
sdc1 crypto_LUKS 2           5f452b2f-3b11-4494-890b-d6c3e509c0ef

Save that LUKS UUID—you will use it in crypttab and recovery docs. A fuller header dump looks like this:

sudo cryptsetup luksDump /dev/sdc1 | head -20

Sample output (trimmed):

LUKS header information
Version:       	2
UUID:          	5f452b2f-3b11-4494-890b-d6c3e509c0ef
...
Keyslots:
  0: luks2
	Key:        512 bits
	PBKDF:      argon2id

Confirm the partition is locked

After luksFormat, the disk holds a LUKS header and encrypted payload—not a mountable filesystem. You cannot browse it or drop files on /dev/sdc1 the way you would on an unencrypted USB stick.

The partition identifies as LUKS, not ext4:

sudo file -sL /dev/sdc1

Sample output (trimmed):

/dev/sdc1: LUKS encrypted file, ver 2 ..., UUID: 5f452b2f-3b11-4494-890b-d6c3e509c0ef, ...

A normal mount fails because the kernel sees crypto_LUKS, not a filesystem type it can attach to a directory:

sudo mkdir -p /mnt/luks-locked-test
sudo mount /dev/sdc1 /mnt/luks-locked-test

Sample output:

mount: /mnt/luks-locked-test: unknown filesystem type 'crypto_LUKS'.
       dmesg(1) may have more information after failed mount system call.

Without a mount point, there is nowhere to create check.txt or copy data. The first bytes on disk are the LUKS header (LUKS magic), not a directory tree:

sudo hexdump -C -n 32 /dev/sdc1

Sample output:

00000000  4c 55 4b 53 ba be 00 02  00 00 00 00 00 00 40 00  |LUKS..........@.|
00000010  00 00 00 00 00 00 00 04  00 00 00 00 00 00 00 00  |................|

That is the point of LUKS at rest: offline readers see ciphertext and metadata, not your files. The next step opens the container with your passphrase and creates the mapper device where a filesystem can live.

Optional but recommended — Back up the LUKS header

After you create the volume, take a header backup and store it somewhere safe—not on the same encrypted disk:

sudo cryptsetup luksHeaderBackup /dev/sdc1 --header-backup-file luks-sdc1-header.img
ls -la luks-sdc1-header.img

Sample output:

-r-------- 1 root root 16777216 Jul  4 21:55 luks-sdc1-header.img

This file holds the LUKS header and key-slot area. It is useful if the on-disk header is damaged later. Protect it carefully: anyone with this backup and a valid passphrase can attempt to unlock the encrypted data. See LUKS header backup and recovery for restore workflows.

Step 5 — Open the volume

Unlocking checks your passphrase and creates /dev/mapper/secure_data (you can choose another mapper name—letters, numbers, underscore only):

sudo cryptsetup open /dev/sdc1 secure_data

Enter the passphrase. Confirm Linux created the node:

ls -l /dev/mapper/secure_data

Sample output:

lrwxrwxrwx 1 root root 7 Jul  4 20:30 /dev/mapper/secure_data -> ../dm-1

From here until you close, treat /dev/mapper/secure_data as the disk you format and mount—not /dev/sdc1.

Step 6 — Create ext4 on the mapper

This is the step people get wrong: you format the mapper, not the LUKS partition.

sudo mkfs.ext4 -L secure-data /dev/mapper/secure_data

Sample output (trimmed):

mke2fs 1.47.2 (1-Jan-2025)
Creating filesystem with 1306112 4k blocks and 327040 inodes
Filesystem UUID: 9fe05bbb-e530-48ed-a8f7-461febc7329f
...
Writing superblocks and filesystem accounting information: done

You now have two different UUIDs on disk. After mkfs, list both so you can tell them apart when you edit crypttab and fstab later:

sudo blkid /dev/sdc1 /dev/mapper/secure_data

Sample output:

/dev/sdc1: UUID="5f452b2f-3b11-4494-890b-d6c3e509c0ef" TYPE="crypto_LUKS" PARTLABEL="primary" PARTUUID="b2ec5a76-8585-4e6b-9926-3ca5094fcea1"
/dev/mapper/secure_data: LABEL="secure-data" UUID="9fe05bbb-e530-48ed-a8f7-461febc7329f" BLOCK_SIZE="4096" TYPE="ext4"

Use the /dev/sdc1 UUID (LUKS container) in /etc/crypttab when you set up boot-time unlock. Use the /dev/mapper/secure_data UUID (ext4 filesystem) in /etc/fstab for the mount entry. Stable paths such as /dev/disk/by-uuid/5f452b2f-3b11-4494-890b-d6c3e509c0ef work the same way if you prefer symlinks over raw /dev/sdX names.

Quick type check with file:

sudo file -sL /dev/mapper/secure_data

Sample output:

/dev/mapper/secure_data: Linux rev 1.0 ext4 filesystem data, UUID=9fe05bbb-e530-48ed-a8f7-461febc7329f, volume name "secure-data" ...

Step 7 — Mount and try a write

Create a mount point and attach the filesystem:

sudo mkdir -p /mnt/secure-data
sudo mount /dev/mapper/secure_data /mnt/secure-data

mount should point at the mapper:

mount | grep secure_data

Sample output:

/dev/mapper/secure_data on /mnt/secure-data type ext4 (rw,relatime)

Usable size is slightly below the partition size because of the LUKS header and filesystem metadata:

df -h /mnt/secure-data

Sample output:

Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/secure_data  4.9G  1.3M  4.6G   1% /mnt/secure-data

Write a test file and read it back—if that works, the full stack (LUKS → mapper → ext4 → mount) is healthy:

echo 'encrypted test file' | sudo tee /mnt/secure-data/check.txt
cat /mnt/secure-data/check.txt

Sample output:

encrypted test file

Copy your data with rsync or cp while the mapper stays open. A healthy stack shows the LUKS partition with a child mapper and ext4 mount point:

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

Sample output:

NAME                  SIZE TYPE  FSTYPE      LABEL       MOUNTPOINT
sdc                     5G disk
└─sdc1                  5G part  crypto_LUKS
  └─secure_data         4.9G crypt ext4        secure-data /mnt/secure-data

If you move this disk to another PC later, the flow is the same: open LUKS on another machine, then mount.

Step 8 — Unmount and lock

When you are done for the day, unmount first so pending writes flush, then close the mapper so the key leaves memory:

sudo umount /mnt/secure-data
sudo cryptsetup close secure_data
lsblk -f /dev/sdc1

The mapper line disappears; only the locked LUKS container remains:

NAME FSTYPE      FSVER LABEL UUID
sdc1 crypto_LUKS 2           5f452b2f-3b11-4494-890b-d6c3e509c0ef

Your check.txt file is still on the encrypted volume, but it is not visible until you unlock again. Mounting the raw partition fails, and the path does not exist without the mapper:

sudo mount /dev/sdc1 /mnt/secure-data
ls /mnt/secure-data/check.txt

Sample output:

mount: /mnt/secure-data: unknown filesystem type 'crypto_LUKS'.
       dmesg(1) may have more information after failed mount system call.
ls: cannot access '/mnt/secure-data/check.txt': No such file or directory

To use the disk again: cryptsetup open /dev/sdc1 secure_data, enter the passphrase, then mount /dev/mapper/secure_data /mnt/secure-data—check.txt reappears. For boot-time unlock, set up crypttab and fstab next.

Troubleshooting

References

• cryptsetup FAQ (official)
• Linux kernel dm-crypt documentation
• Ubuntu man page: cryptsetup(8)
• cryptsetup command cheat sheet
• Auto mount LUKS at boot with crypttab
• Back up the LUKS header
• Resize a LUKS volume

Summary

You identified the target disk, created a partition, ran luksFormat on it, opened a mapper device, formatted ext4 on /dev/mapper/name (not on the LUKS partition), mounted the filesystem, and closed the mapper when finished. Keep that split in mind: LUKS metadata on the partition, your files on the mapper. For unlock at boot, continue with crypttab and fstab.