A USB drive is the easiest thing you own to lose. It slips out of a pocket, gets left in a borrowed laptop, or rides along in a bag that goes missing, and everything on it goes with it. Encryption is the one fix that works after the drive is already gone: without the passphrase, the contents are just noise. On Linux, the standard tool for that job is LUKS, the Linux Unified Key Setup, and setting it up takes about ten minutes.

This guide encrypts a whole USB drive with LUKS2, puts a filesystem on it, and shows you how to unlock it on any Linux machine. It also covers the one step most tutorials skip: backing up the LUKS header, because a damaged header can lock you out just as surely as a forgotten passphrase.

What you need

  • A USB drive you can completely erase. Encryption wipes the drive, so copy anything you want to keep somewhere else first.
  • A Linux machine with cryptsetup installed. On Debian and Ubuntu it is sudo apt install cryptsetup; on Fedora, sudo dnf install cryptsetup; on Arch, sudo pacman -S cryptsetup.
  • A strong passphrase you do not use anywhere else. LUKS has no password reset. If you forget the passphrase and have no header backup with a working key slot, the data is gone, full stop.

Step 1: Identify the drive, then check twice

Plug the drive in and list block devices:

BASH
lsblk -o NAME,SIZE,MODEL,MOUNTPOINT

Find your USB drive by its size and model name. It will usually be something like /dev/sdb, with a partition such as /dev/sdb1. Note the device name carefully: every command below is destructive, and pointing it at the wrong device erases the wrong disk. If the drive auto-mounted, unmount it first:

BASH
sudo umount /dev/sdb1

If you are unsure which device is the USB drive, unplug it, run lsblk again, and see which entry disappeared. That thirty-second check has saved more data than any backup tool.

Step 2: Wipe the old filesystem signatures

Clear leftover partition tables and filesystem headers so nothing from the drive's previous life interferes:

BASH
sudo wipefs -a /dev/sdb

This only removes signatures, not the data itself, but combined with the encryption step that follows, the old contents become unreadable anyway.

Step 3: Create the LUKS container

Now format the whole device as a LUKS2 container. Using the whole device (/dev/sdb) rather than a partition keeps things simple and avoids confusion about which partition holds the encrypted volume:

BASH
sudo cryptsetup luksFormat --type luks2 /dev/sdb

cryptsetup will warn you that the data will be overwritten and ask you to type YES in capitals. Then it asks for your passphrase twice. Choose a long one: a sentence of five or more random words beats a short string of symbols, and it is far easier to type correctly every time you unlock the drive.

You can confirm the container with:

BASH
sudo cryptsetup luksDump /dev/sdb

This shows the LUKS version, cipher (typically aes-xts-plain64), and key slots, without revealing anything secret.

Step 4: Open it and create a filesystem

Unlock the container under a name of your choice. The name becomes a device under /dev/mapper/:

BASH
sudo cryptsetup open /dev/sdb myusb

Then put a filesystem on the unlocked device. ext4 is a safe default for Linux-only use:

BASH
sudo mkfs.ext4 -L myusb /dev/mapper/myusb

If you need the drive to work on Windows or macOS too, use exFAT instead (sudo mkfs.exfat /dev/mapper/myusb), and accept that you lose Linux permissions and journaling. For a drive that mostly lives on Linux machines, ext4 is the better choice.

Step 5: Mount it, test it, close it

Mount and verify you can actually write to the drive:

BASH
sudo mkdir -p /mnt/myusb
sudo mount /dev/mapper/myusb /mnt/myusb
echo "encryption works" | sudo tee /mnt/myusb/test.txt
ls -l /mnt/myusb

Then unmount and close the container properly, every time:

BASH
sudo umount /mnt/myusb
sudo cryptsetup close myusb

From this point on, the normal routine is: plug in, cryptsetup open, mount, work, unmount, cryptsetup close. On GNOME, KDE, and other desktop environments you can skip the terminal for unlocking: the file manager will prompt for the passphrase when you click the drive, then mount it for you. The terminal route still matters on servers and headless machines, and it is worth knowing even if you usually click.

Step 6: Back up the LUKS header

This is the step people skip, and it is the one that saves you. The LUKS header, stored at the start of the device, holds the encrypted master key. If that small region gets corrupted, by a bad sector, a yanked drive mid-write, or a partitioning accident, no passphrase in the world will open the volume. A header backup is tiny, and restoring it brings the drive back:

BASH
sudo cryptsetup luksHeaderBackup /dev/sdb --header-backup-file ~/luks-usb-header.img

Store that file somewhere that is not the USB drive itself: another machine, a password manager's secure storage, or an encrypted backup. Guard it like a key, because combined with knowledge of the passphrase it is part of the lock. If disaster strikes, restore with:

BASH
sudo cryptsetup luksHeaderRestore /dev/sdb --header-backup-file ~/luks-usb-header.img

Note that restoring a header also restores the old key slots, so if you changed your passphrase after making the backup, the restored header accepts the old one. Keep the backup current whenever you change passphrases. A regular encrypted backup routine, for example with a tool like restic, pairs naturally with this: the header backup protects the container, and the file backup protects the contents. For a broader look at keeping backups that actually restore, see the restic backup and restore playbook.

Pitfalls that catch real people

The wrong device. The lsblk check in step 1 is not optional decoration. Typing /dev/sda instead of /dev/sdb encrypts your system disk. Slow down on this one command.

A passphrase you cannot type reliably. A passphrase that is strong but mistyped half the time will tempt you to weaken it or write it on the drive's label. Pick something long, memorable, and typeable, and test unlocking twice before you trust the drive with real data.

Pulling the drive without closing it. Unmount and cryptsetup close before unplugging. A dirty unmount risks filesystem corruption, and on a flash drive that corruption can land exactly on the header.

Assuming encryption equals backup. LUKS protects confidentiality, not availability. A lost drive with a header backup is recoverable; a dead flash chip is not. Keep a second copy of anything irreplaceable.

Locking yourself out of a system disk. This guide encrypts a removable drive. Encrypting a boot drive is a different job with its own recovery story, and the failure mode there is a machine that will not start. If you have ever wondered what that failure looks like, the encrypted Arch box that updated fine and then refused to unlock is a useful cautionary tale.

Verify it worked

The honest end-to-end test takes one minute: close the container, unplug the drive, plug it back in, and unlock it again:

BASH
sudo cryptsetup open /dev/sdb myusb
sudo mount /dev/mapper/myusb /mnt/myusb
cat /mnt/myusb/test.txt
sudo umount /mnt/myusb
sudo cryptsetup close myusb

If test.txt reads back, the encryption round-trips. Delete the test file, copy your real files on, and the drive is ready to travel. Losing it from here on is an inconvenience, not a data breach. That is the whole point.

For the same defensive mindset applied to a machine that stays online, the SSH hardening audit playbook covers locking down remote access, and the btrfs snapshots playbook covers rolling a system back when an update goes wrong.

Sources