You need a computer running Linux, your own user password (the one you type when a command asks for sudo), and a USB stick, SD card or microSD card you are willing to erase completely. Nothing here costs money, and nothing is downloaded except one package your system may already have.
The button and menu names below are the ones Linux Mint uses, because that is the friendliest place to start. Every command is identical on Ubuntu, Debian, Fedora, Arch and the rest — LUKS lives in the Linux kernel, not in any one distribution.
🔴 Everything on that card or stick will be destroyed. Not moved, not hidden — destroyed. Copy anything you want to keep off it first, then look at it again to be sure you copied the right one.
If you have never opened a terminal, that is fine: every command is written out in full, and you only need to know how to open one and press Enter. Our Introduction to the Linux Terminal covers that in a few minutes. Allow about forty minutes for this page the first time, and five minutes every time after that.
What you will be able to do: turn a USB stick or memory card into an encrypted volume that is unreadable to anyone without your passphrase, that opens on other computers and not just the one you made it on, and that you can prove is working at every single step instead of hoping.
These commands encrypt a removable drive. They cannot encrypt the disk your operating system is currently running from, for the same reason you cannot rebuild a floor while standing on it. Most installers offer to encrypt the whole installation while it is being set up, on the disk-setup screen, and that is the supported way to protect the system itself. If that is what you came for, back up your files and reinstall with that option chosen. Everything below still applies to every other drive you own.
The Recipe Card
The whole job on one screen. If you have done this before, you need nothing else on this page. If this is your first time, skip past it — the walkthrough below does every line slowly, and tells you what your screen will say.
Throughout, DEV means /dev/disk/by-id/ plus the name you find in step 3, and myvault is a name you choose.
cryptsetup --versionA version number means you already have it — skip ahead. Only on
command not found: sudo apt install cryptsetup.
cryptsetup --help | tail -n 12Read
Memory required: — usually 1048576kB, which is 1 GiB. That is the thing this recipe fixes.
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS with it out, then in.ls -l /dev/disk/by-id/ | grep sdbTake the entry without
-part1.
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS DEVMOUNTPOINTS must be empty. If not:
sudo umount <that path>.
sudo dd if=/dev/zero of=DEV bs=1M count=16 oflag=direct conv=fsync status=progressMust copy
16777216 bytes.
sudo cryptsetup --verbose luksFormat --type luks2 --label myvault --cipher aes-xts-plain64 --key-size 512 --pbkdf argon2id --pbkdf-memory 65536 --iter-time 1000 DEVAnswer
YES in capitals. Ends Key slot 0 created.
sudo cryptsetup luksDump DEV | grep -E 'UUID|Memory'Must say
Memory: 65536. Copy the UUID down.
sudo cryptsetup --verbose open DEV myvaultEnds
Key slot 0 unlocked.
sudo mkfs.ext4 -L myvault -E root_owner=$(id -u):$(id -g) /dev/mapper/myvaultEnds
done. The journal line pauses; it is not stuck.
sudo mkdir -p /mnt/myvault && sudo mount /dev/mapper/myvault /mnt/myvaultthen
cd ~, sudo umount /mnt/myvault, sudo cryptsetup close myvault.
sudo cryptsetup luksHeaderBackup DEV --header-backup-file ~/myvault-luks-header.img16 MiB. Verify with
luksDump on the file; UUID must match step 7.
The one number to remember: Memory: 65536. If luksDump shows anything much larger, the drive was built with machine-chosen defaults and will one day refuse to open on a machine that matters.
Before Your First Command
If you have never used a terminal, read this once. It is everything you need, and nothing you do not. If you already use a terminal daily, skip to the next chapter.
$. That is all a terminal is: a place to type one instruction and press Enter.
$ is not part of the command
Guides often show a $ at the start of a line. It is the computer's way of saying “ready”. This page never prints it, so everything inside a grey box is exactly what you type — nothing to strip off.
$ to come back before doing anything else. Some commands take several seconds and print nothing while they work. A missing $ means still busy, not broken.
sudo means
“Do this as the administrator.” The first time you use it, it asks for your own login password — the one you type when the computer starts. It will not ask again for a few minutes.
How to Read the Walkthrough
Every step has the same four parts, always in the same order, so you never hunt for anything:
Where a step could change your machine, it first gives you a read-only command that tells you whether the change is even needed — and shows you both answers. You may well find the tool is already there and the whole step is one line long. No step asks you to paste something on the assumption that you need it.
In every command box, the parts you must change are printed in amber with a dotted underline, like myvault and usb-Generic_STORAGE_DEVICE-0:0. Everything in plain grey is typed exactly as printed.
So you never have to read a word to know what to edit — just replace what is highlighted. The ✏️ Change: line under each command then tells you what to replace it with, and which step gave you that value.
The highlighting is only styling: the Copy button still copies the plain command, with no colours and no extra characters.
Inside the screen samples, two marks point at things:
Iteration time: 2000, Memory required: 1048576kB, Parallel threads: 4
^^^^^^^^^^
the characters above are what matters
sdb 7,5G disk <-- this whole line is the thing
Sizes, dates, UUIDs and version numbers differ on every machine, and that is fine. What must match is the shape: the same lines saying the same kind of thing. Where one exact value genuinely must match, it is marked MUST.
Commands are clean so you can copy them. Only the output boxes carry marks — never copy an output box.
The One Word You Will Type a Lot
myvault anywhere. Not once.
It is not your passphrase, it is not secret, and nobody but you will ever see it. Leaving it exactly as printed removes the single most common way this procedure goes wrong. You can rename the drive later in ten seconds, once it exists and works.
Here is why that warning is the strongest one on this page. The word myvault is not one thing — it appears in five different roles, and they are not automatically connected. Change it in one place and the others silently disagree with you:
--label myvault when you create the container. Cosmetic — it is what your file manager shows instead of “119 GB Encrypted”.
cryptsetup open … myvault. You invent it each time you unlock; nothing about it is stored on the drive.
/dev/mapper/myvault — created automatically by role 2. It must match role 2 exactly, because role 2 is what made it.
-L myvault when you create the filesystem. Cosmetic again, and completely separate from role 1.
/mnt/myvault — an ordinary empty folder you create with mkdir. The folder you create and the folder you mount on must be the same one, or the mount fails.
Roles 1 and 4 are decoration. Roles 2, 3 and 5 are real plumbing, and a mismatch between them is what produces these two messages, both of which mean “you used two different words” rather than anything being broken:
mount: /mnt/microsd2: mount point does not exist.
^^^^^^^^^^^^^ you created /mnt/myvault but tried to mount on /mnt/microsd2
mount: special device /dev/mapper/myvault does not exist.
^^^^^^^^^^^^^^^^^^^ you unlocked it as something else
Write your word down before you start, and every time this page prints myvault, type yours instead — including inside /dev/mapper/ and /mnt/. Each step's ✏️ Change: line names every occurrence in that command, so nothing is left to memory.
Lost track already? The next box gets you back without losing anything.
Lost? Find Out Exactly Where You Are
Nothing below changes anything. Run all three whenever you are unsure what state your drive is in — after an error, after a break, or if you suspect your names got out of step. Between them they answer every “what did I actually do?” question on this page.
1 — which containers are unlocked right now, and what are they called?
ls /dev/mapper/control microsd2 vgmint-root vgmint-swap_1
^^^^^^^^ THIS is the name you unlocked it with, whatever the page said.
Use it in /dev/mapper/... from now on.
'control' is part of Linux -- ignore it, always there.
2 — what is your drive actually doing?
lsblk -fsdb crypto_LUKS 2 microsd2 28c566b9-... └─microsd2 ext4 1.0 myvault 83ce9eec-... /mnt/myvault ^^^^^^^^ unlocked as this ^^^^^^^ fs label ^^^^^^^^^^^ mounted here No indented line at all = the container is sealed (normal when not in use). An indented line with no mountpoint = unlocked but not mounted yet.
3 — which mount folders exist?
ls -l /mnt/Now you can see all three names at once and make them agree. Nothing you have done is lost — a name mismatch never damages the drive or the data, it only stops a command finding what it is looking for. Pick the name ls /dev/mapper/ showed you, use that one consistently, and carry on from wherever you stopped.
The Walkthrough
Thirteen steps. Each one shows what to type, what your screen will say, and which single line to look at. Steps 1–4 change nothing. Step 5 is the first that destroys data.
At step 10 your card is encrypted, sealed and working, and it is very tempting to stop there. Steps 11, 12 and 13 are the ones people skip and then regret. They add nothing to the card — they test it, and each one catches a different way this can quietly have failed:
Step 11 proves your desktop can unlock it, which uses a different code path from the terminal. Step 12 saves a spare copy of the header and verifies that copy is real. Step 13 opens it on another computer — the only test that proves the card travels, which is the whole reason for the settings in step 6.
You are finished when step 13 succeeds, not when step 10 does.
Go: a terminal — press Ctrl+Alt+T.
Do: do not install anything yet. First ask whether you already have it. Most Linux systems ship it.
✏️ Change: nothing.
cryptsetup --versionYou will get one of exactly two answers:
cryptsetup 2.7.0 flags: UDEV BLKID KEYRING FIPS KERNEL_CAPI HW_OPAL
^^^^^^^^^^^^^^^^^^^^^^ a version number = YOU ALREADY HAVE IT.
Skip the install. Go straight to step 2.
bash: cryptsetup: command not found ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not installed. Only now run the command below.
Only if you saw command not found:
sudo apt install cryptsetupYou should see: if you did have to install it, apt finishes with a summary. The version numbers will differ from any example and any version is fine:
Setting up cryptsetup (2:2.7.0-1ubuntu4) ... 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Either way you now have the tool, and if it was already there nothing on your system was changed. Run cryptsetup --version once more if you want to see it confirmed.
If not: • E: Unable to locate package → your package list is stale, not the tool missing. Run sudo apt update, then the install again
• E: Could not get lock → something else is installing. Wait a minute and retry
• Fedora / Arch → the check is the same; only the install differs — sudo dnf install cryptsetup or sudo pacman -S cryptsetup
Go: same terminal. This changes nothing.
Do: run the command below.
✏️ Change: nothing — paste it exactly as printed.
cryptsetup --help | tail -n 12You should see: twelve lines. Ignore eleven of them. Find this one:
Default PBKDF for LUKS2: argon2id
Iteration time: 2000, Memory required: 1048576kB, Parallel threads: 4
^^^^^^^^^^
1048576 kB = 1 GiB of RAM, every unlock
That number is the whole reason this page exists. Left alone, your card would demand 1 GiB of free memory every time it is opened — on every machine, forever. Step 5 replaces it with 64 MiB. Why that is safe →
If not: • Memory required: 65536kB → your build already uses a small default — carry on anyway, step 5 pins it explicitly
• no Memory required line at all → your cryptsetup predates LUKS2 — see the reference, Very old systems
• command not found → go back to step 1
Go: same terminal, drive unplugged.
Do: run the command below.
✏️ Change: nothing — paste it exactly as printed.
Run it once now. Then plug the drive in, count to five, and run the same command again.
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTSYou should see: a block in the second listing that was not in the first:
sda 931,5G disk ├─sda1 512M part /boot/efi └─sda2 931,0G part / sdb 7,5G disk <-- NEW. This is your drive. └─sdb1 7,5G part /media/you/SD32G ^^^^ size matches the card
Now turn that letter into a name that cannot change tomorrow:
ls -l /dev/disk/by-id/ | grep sdb✏️ Change:
sdb → the letter your own listing showed.
usb-Generic_STORAGE_DEVICE-0:0 -> ../../sdb <-- TAKE THIS ONE usb-Generic_STORAGE_DEVICE-0:0-part1 -> ../../sdb1 ^^^^^^ not this: -part1 is inside the drive
Write that name down. Every command from here uses /dev/disk/by-id/ followed by it.
If not: • no new block appears → different USB port, then different cable, then reseat the microSD in its adapter
• two new blocks appear → something else was plugged in at the same moment — remove it and repeat
• the name starts mmcblk0 → a built-in card slot. Use that name; its partitions carry a p, as in mmcblk0p1
• grep prints nothing → wrong letter — read the listing again
Go: same terminal.
Do: run the command below.
✏️ Change: usb-Generic_STORAGE_DEVICE-0:0 → your drive name from step 3. Nothing else on the line.
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0You should see: the last column decides. Empty is what you want:
NAME SIZE TYPE FSTYPE MOUNTPOINTS
sdb 7,5G disk
└─sdb1 7,5G part exfat /media/you/SD32G
^^^^^^^^^^^^^^^^ NOT empty -- unmount it first
If a path appeared, unmount that exact path, then run the command again and confirm the column is empty:
sudo umount /media/you/SD32G✏️ Change: the path → exactly what your own MOUNTPOINTS column showed.
If not: • target is busy → close file manager windows; type cd ~ in every terminal
• not mounted → good — already done, move on
• something listed in ls /dev/mapper/ → an old unlocked container: sudo cryptsetup close NAME. Ignore control
Go: same terminal. First command that destroys data. Read the device name twice.
Do: run the command below.
✏️ Change: usb-Generic_STORAGE_DEVICE-0:0 → your drive name from step 3. Nothing else on the line.
sudo dd if=/dev/zero of=/dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 bs=1M count=16 oflag=direct conv=fsync status=progressYou should see: one number matters:
16+0 records in 16+0 records out 16777216 bytes (17 MB, 16 MiB) copied, 3,3396 s, 5,0 MB/s ^^^^^^^^ must be 16777216, and no error line
This prevents a step-6 failure that leaves no trace in any log, and doubles as a write test.
If not: • Permission denied → the sudo was left off
• No space left on device → counterfeit card — stop, and test it (reference, Hardware)
• Read-only file system → the write-protect switch on the card or adapter. Eject, slide it, reinsert
• fewer bytes than 16777216 → the card is failing. Replace it
Go: same terminal. Choose your passphrase first — five or more random words. Nobody can reset it.
Do: run the command below.
✏️ Change: usb-Generic_STORAGE_DEVICE-0:0 → your drive name. Optionally myvault → any name. ❌ Do not touch --pbkdf-memory 65536 or --iter-time 1000 — those two are the difference between a card that opens anywhere and one that opens only here.
sudo cryptsetup --verbose luksFormat --type luks2 --label myvault --cipher aes-xts-plain64 --key-size 512 --pbkdf argon2id --pbkdf-memory 65536 --iter-time 1000 /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0You should see: a confirmation you must answer in capitals, then two passphrase prompts, then two lines:
Are you sure? (Type 'yes' in capital letters): YES
^^^ capital YES only. 'yes' cancels silently
Enter passphrase for /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0:
Verify passphrase:
Key slot 0 created.
Command successful.
^^^^^^^^^^^^^^^^^^ both lines = done
If not: • back at the prompt, never asked for a passphrase → you did not type capital YES. Nothing changed; run it again
• Device ... is in use → back to step 4
• Device wipe error, offset 0 → step 5 was skipped or cut short. Run step 5, then this again
• Cannot open device ... in write mode → the write-protect switch
Go: same terminal. Read-only, shows nothing secret.
Do: run the command below.
✏️ Change: usb-Generic_STORAGE_DEVICE-0:0 → your drive name from step 3. Nothing else on the line.
sudo cryptsetup luksDump /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 | grep -E 'Version|Label|UUID|luks2|PBKDF|Memory|Threads|Time cost'You should see: eight lines. One of them is the proof this whole page worked:
Version: 2
UUID: f36fca8f-dbcb-4e2a-8811-c6578d65f2ce <-- copy this down
Label: myvault
0: luks2
PBKDF: argon2id
Time cost: 73 <-- yours will differ. Normal.
Memory: 65536 <-- MUST say 65536. This is the proof.
Threads: 4
If not: • Memory: 1048576 or similar → the options in step 6 did not apply — the long line probably split on paste. Redo steps 5 and 6 as one line
• not a valid LUKS device → step 6 never finished. Run it again and watch for Command successful.
Go: same terminal.
Do: run the command below.
✏️ Change: usb-Generic_STORAGE_DEVICE-0:0 → your drive name. The trailing myvault is the temporary name it gets while open.
sudo cryptsetup --verbose open /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 myvaultYou should see: about one second, then:
No usable token is available. <-- normal, means no hardware key Enter passphrase for /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0: Key slot 0 unlocked. Command successful.
If not: • No key available with this passphrase → on this machine, minutes after creating it, the passphrase really was mistyped. Check Caps Lock and layout; type it into a text editor to look at it
• Device ... does not exist → you shortened the path to /dev/sdb and the letter moved. Use the full by-id path
• Device myvault already exists → already unlocked — skip to the next step
Go: same terminal. The path must be /dev/mapper/myvault. Aiming this at your drive path destroys the header you just made.
Do: run the command below.
✏️ Change: nothing, if you kept myvault. If you renamed it, this one line contains two occurrences with different jobs and both must become your word: -L myvault is only a cosmetic label, while /dev/mapper/myvault must match exactly what you typed at the end of step 8. Leave $(id -u):$(id -g) alone — your shell fills in your own numbers, which is what makes the drive yours.
sudo mkfs.ext4 -L myvault -E root_owner=$(id -u):$(id -g) /dev/mapper/myvaultYou should see: several lines ending in done:
Creating filesystem with 1965824 4k blocks and 491520 inodes
Creating journal (16384 blocks): done
^^^^ can sit here 15s on a slow card. Not stuck.
Writing superblocks and filesystem accounting information: done
If not: • No such file or directory → either step 8 did not unlock it, or you unlocked it under a different name than the one you typed here. Run ls /dev/mapper/ — whatever is listed there is the real name, and that is what goes after /dev/mapper/
• you aimed it at the by-id path by mistake → the header is gone. Start again from step 5
• is mounted; will not make a filesystem here → unmount it first
Go: same terminal.
Do: six commands, each in its own box below. Run one, wait for the $ to come back, then run the next.
✏️ Change: nothing, if you kept myvault. If you renamed it, every one of these six lines contains your word — /mnt/myvault appears in four of them, /dev/mapper/myvault in one, and the bare name in the last. Boxes 1 and 2 must name the same folder, and box 2's /dev/mapper/ name must match what you typed at the end of step 8.
1 — make a folder to attach the drive to. Harmless if it already exists:
sudo mkdir -p /mnt/myvault2 — attach the unlocked drive to that folder. Two names in one line: /dev/mapper/myvault must match step 8, and /mnt/myvault must match the folder box 1 just made.
sudo mount /dev/mapper/myvault /mnt/myvault3 — write a file and read it straight back. No sudo: that is the point.
echo "it works" > /mnt/myvault/proof.txt && cat /mnt/myvault/proof.txt4 — step out of the folder, or the next command will refuse:
cd ~5 — detach the folder:
sudo umount /mnt/myvault6 — lock the encryption again. Do not skip this one — unmounting without closing leaves the drive decrypted until you reboot.
sudo cryptsetup close myvaultYou should see: silence from five of them, and two words from the third. Silence is success.
it works ^^^^^^^^ you can write to your own encrypted drive without sudo
Now look at it sealed:
lsblk -f /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0✏️ Change:
usb-Generic_STORAGE_DEVICE-0:0 → your drive name from step 3. Nothing else on the line.
NAME FSTYPE FSVER LABEL UUID
sdb crypto_LUKS 2 myvault f36fca8f-dbcb-4e2a-8811-c6578d65f2ce
^^^^^^^^^^^ and NOTHING indented underneath = sealed, safe to unplug
Your card is encrypted and sealed, and everything looks finished. Three untested things remain, and each one has caught somebody out:
Step 11 — can your desktop unlock it, not just the terminal?
Step 12 — is there a spare copy of the header, and is that copy actually valid?
Step 13 — does it open on a different computer?
None of them changes your card, and all three are quick. Continue to step 11.
If not: • mount point does not exist → box 1 made one folder and box 2 named a different one. Run ls -l /mnt/ to see which folder really exists, then use that exact path in box 2 — or re-run box 1 with the path box 2 uses. Nothing is broken and nothing is lost
• special device /dev/mapper/… does not exist → you unlocked the drive under a different name in step 8. Run ls /dev/mapper/; the name listed there is the real one. Use it
• no mount point specified → you already unmounted it — this is the second attempt. Nothing to do; carry on
• Permission denied writing the file → sudo chown -R $(id -u):$(id -g) /mnt/myvault, once
• target is busy → cd ~ everywhere, close file manager windows. Never unplug to escape this
• you have lost track of your names → run the three read-only commands in Lost? Find out exactly where you are — they show every name in use at once
Go: your desktop. The terminal and the desktop unlock by different routes — a card can work in one and fail in the other.
Do: unplug the drive, wait five seconds, plug it back in. Click it when it appears, and type the passphrase.
You should see: your label in the sidebar, a passphrase box that finishes in a second or two, then a window with lost+found and proof.txt in it.
Confirm from the terminal rather than trusting the window:
lsblk -f | grep -A2 myvaultsdb crypto_LUKS 2 myvault f36fca8f-... └─luks-f36fca8f- ext4 1.0 myvault 62d21b22-... /media/you/myvault ^^^^^^^^^^^^^^^^ an indented second line = unlocked and mounted
When finished, use the file manager's eject button — it unmounts and re-locks in one click.
If not: • box spins then fails, but step 8 worked in the terminal → not your drive and not your passphrase — a memory limit on the background service. Reference, Failure A. The terminal route keeps working meanwhile
• An operation is already pending → sudo systemctl restart udisks2, then unplug and replug
• nothing happens on plug-in → your desktop does not auto-prompt. Open the Disks app, or stay in the terminal. Nothing is wrong
Go: same terminal, drive plugged in and sealed.
Do: save a copy of the drive's header to a file in your home folder.
sudo cryptsetup luksHeaderBackup /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 --header-backup-file ~/myvault-luks-header.img✏️ Change:
usb-Generic_STORAGE_DEVICE-0:0 → your drive name. ~ means your home folder; change only the myvault part of the filename if you renamed it.The backup command prints nothing at all when it works. So prove the copy is real by reading the identity back out of the file:
sudo cryptsetup luksDump ~/myvault-luks-header.img | grep -E 'UUID|Label|Memory'You should see: no output at all from the backup itself — that is success — and then three lines from the file that must match step 7 exactly:
UUID: f36fca8f-dbcb-4e2a-8811-c6578d65f2ce
Label: myvault
Memory: 65536
^^^^^^^^^^^^^^^^^ must match step 7 exactly, or you backed up the wrong device
You ran that command with sudo, so the file it made belongs to root and is readable by nobody else:
ls -l ~/myvault-luks-header.img-r-------- 1 root root 16777216 Sep 19 11:26 /home/you/myvault-luks-header.img ^^^^^^^^^^ ^^^^ ^^^^ owner root, mode 0400 -- your own account cannot open it
Try to attach it to KeePassXC or any other program running as you, and you get Permission denied. That is not a fault; it is the file's ownership. Hand it to yourself:
sudo chown $(id -u):$(id -g) ~/myvault-luks-header.imgLeave $(id -u):$(id -g) exactly as written — your shell fills in your own numbers. Run ls -l ~/myvault-luks-header.img again and the owner should now be your username. It will attach normally after that.
It does not help if you forget the passphrase. It is not a recovery key and it cannot open anything on its own. Holding it without the passphrase gets you nothing at all.
What it protects against is the header being damaged. The master key that decrypts your files lives in the first few megabytes of the card. Overwrite that — a mistyped dd, a camera or phone that “initialises” the card, a Windows machine you clicked the wrong button on, or simply a bad sector — and the key is gone. Every byte of your data is then unrecoverable even though your passphrase is perfectly correct, because there is nothing left to unlock. Restoring this file puts the key back and the data reappears.
So: a spare lock, not a spare key. You will never need it in normal use, and if you ever do need it, nothing else will do. That is why it is worth the two minutes now.
Keeping it in KeePassXC is a good choice — it travels with your passwords, it is encrypted at rest, and it is off the card it protects. Just never store it on the encrypted card itself.
The passphrase, the UUID from step 7, and where this file is. A password manager is ideal; paper in a drawer beats remembering. The file is a spare lock, not a spare key — it is useless without the passphrase, and it must never live on the encrypted drive itself.
If not: • already exists → it will not overwrite a backup. Use a different filename until you know which drive the old one belongs to
• the UUID does not match step 7 → you backed up a different device. Check the path and redo it
Go: a different machine — another laptop, a friend's, a Pi, a live USB. Nothing on this computer can answer this question.
Do: run the command below.
✏️ Change: /dev/sdX → whatever lsblk shows on that machine. A letter is fine here: unlocking only reads, so a wrong one gives an error, not a destroyed disk.
sudo cryptsetup open /dev/sdX myvault && sudo mkdir -p /mnt/myvault && sudo mount /dev/mapper/myvault /mnt/myvaultYou should see: an unlock in about a second, and your file readable:
Key slot 0 unlocked. Command successful. ^^^^^^^^^^^^^^^^^^ this is the goal of the whole page, demonstrated
If not: • No key available with this passphrase, but it opens on your own machine → exactly the problem this page prevents. Check step 7: Memory must read 65536. If it is larger, redo steps 5–10
• cryptsetup: command not found → install it there as in step 1. The drive is fine; the tool is missing
A friend's laptop says No key available with this passphrase. Your own machine opens the same card in a second. What is wrong, and which command proves it? Answer: the passphrase is fine. The header is asking that laptop for more memory or time than it can give, and the failure is reported with the wrong message. Run sudo cryptsetup luksDump and read Memory:. Above 65536 means the card was built with machine-chosen defaults. Reformatting because you think you forgot the passphrase is the mistake this page exists to prevent.
Now do it without the page: encrypt a second stick with no page open: lsblk → ls /dev/disk/by-id/ → dd → luksFormat with the two KDF options → open → mkfs.ext4 → mount. Then luksDump and confirm Memory: 65536. Produce that line unaided and you have the skill, not the recipe.
Changing the Passphrase Later
Your card is finished and working. This is the maintenance job you are most likely to need next — someone watched you type it, you want a longer one, or you simply want a fresh one. It does not touch your files. Nothing is re-encrypted, nothing is copied, and the drive can stay exactly as it is.
Your passphrase never encrypted your files. It unlocks a randomly generated master key stored in the header, and that key encrypts the data. Changing your passphrase only re-wraps that small key — a second's work — while the master key and every byte on the card stay exactly as they were.
The safe route: add the new one, prove it works, then remove the old one
Six commands. The order matters: you never destroy the passphrase that works until you have proved the replacement does. Do it the other way round and one typo locks you out of a perfectly healthy card, permanently.
The card can be plugged in and sealed; it does not need to be unlocked or mounted for any of this.
1 — see what you have now. Read-only.
sudo cryptsetup luksDump /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 | grep -E 'Keyslots|^ [0-9]+: luks2'Keyslots: 0: luks2 ^ one slot, numbered 0. That is your current passphrase.
2 — add the new passphrase as a second slot. It asks for any existing passphrase first (so type the OLD one), then the NEW one twice.
sudo cryptsetup luksAddKey --pbkdf argon2id --pbkdf-memory 65536 --iter-time 1000 --verbose /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0Enter any existing passphrase: <-- the OLD one Enter new passphrase for key slot: <-- the NEW one Verify passphrase: <-- the NEW one again Key slot 0 unlocked. <-- it accepted your old passphrase Key slot 1 created. <-- the new one now lives in slot 1 Command successful.
Keep those two KDF options. A slot added without them is tuned to this machine and reintroduces exactly the portability problem the whole page is built to avoid — on the same card, in the new slot only.
3 — confirm both slots exist.
sudo cryptsetup luksDump /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 | grep -E '^ [0-9]+: luks2'0: luks2 <-- old passphrase 1: luks2 <-- new passphrase
4 — prove the NEW passphrase works, on its own slot. This is the step that makes the whole thing safe. Read-only: it tests the key and exits without unlocking anything.
sudo cryptsetup open --test-passphrase --key-slot 1 --verbose /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0Key slot 1 unlocked. Command successful. ^^^^^^^^^^^^^^^^^^ the new passphrase is real. ONLY NOW is it safe to continue.
Key slot 1 unlocked., stop here
You mistyped the new passphrase, twice, the same way — usually Caps Lock or a keyboard layout. Do not run step 5. Your old passphrase still works and nothing is lost. Remove the bad slot with sudo cryptsetup luksKillSlot /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 1, authenticating with the old passphrase, then start again from step 2.
5 — remove the old slot. It asks for a passphrase: give the NEW one, to prove once more that it works.
sudo cryptsetup luksKillSlot --verbose /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 0Key slot 1 unlocked. <-- authenticated with the NEW passphrase Key slot 0 removed. <-- the old one is gone Command successful.
6 — final check. The old passphrase must now fail and the new one must work.
sudo cryptsetup luksDump /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 | grep -E '^ [0-9]+: luks2' 1: luks2
^ ONE slot, and it is numbered 1, not 0. That is correct and normal --
slot numbers are just addresses, they do not renumber when one is freed.
sudo cryptsetup open --test-passphrase --verbose /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0Key slot 1 unlocked.
Command successful.
-- and typing the OLD passphrase now gives:
No usable token is available.
Command failed with code -2 (no permission or bad passphrase).
^^^^^^^^^^^^^^^^^^^^^^^^^ exactly what you want to see. The old one is dead.
This is the part people miss, and it quietly undoes everything you just did. A header backup contains the keyslots as they were when it was taken. Restore the old one and the old passphrase starts working again — so anyone holding that file plus your old passphrase still gets in.
Make a fresh backup now, using a new filename so it cannot overwrite the old one:
sudo cryptsetup luksHeaderBackup /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 --header-backup-file ~/myvault-luks-header-new.imgThen verify it the same way step 12 did, update your password manager with the new passphrase, and destroy the old backup file rather than merely filing it away.
The one-shot alternative, and its honest trade-off
What it is for: replacing your passphrase in one command instead of six. It swaps the new passphrase into the same keyslot, so you never end up with two slots and never have to remove one. Use it instead of steps 1–6 above, not as well as them.
What it asks you, in this order: your login password for sudo (only if not cached), then Enter passphrase to be changed: — type the OLD one — then Enter new passphrase: and Verify passphrase: — the NEW one, twice. Nothing appears while you type any of them.
✏️ Change: the highlighted device name to your own. Keep the two KDF options exactly as printed, for the same reason as everywhere else on this page.
sudo cryptsetup luksChangeKey --pbkdf argon2id --pbkdf-memory 65536 --iter-time 1000 --verbose /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0What you should see: three lines. The middle one says created, not removed, because the slot was rewritten rather than freed:
Key slot 0 unlocked. <-- it accepted your OLD passphrase Key slot 0 created. <-- the NEW one now occupies that same slot Command successful. <-- done. Your old passphrase no longer works.
If it fails: No key available with this passphrase. at the first prompt means the OLD passphrase was wrong — nothing changed, just run it again. If it fails after the new passphrase, nothing changed either; your old one still works.
It is shorter, and on LUKS2 it is not dangerous in the way older guides claim: the manual states LUKS2 never overwrites an existing keyslot area while there is room for one more, so a media failure part-way cannot strand you the way it could with LUKS1.
So why does this page still recommend the six-step route? Because the risk it protects against is not media failure — it is you. luksChangeKey destroys the old passphrase in the same breath as accepting the new one, so if you type the new one wrong twice the same way, you find out afterwards. The six-step route makes you prove the new passphrase before anything is destroyed. That is a real difference, and typing mistakes are far more common than disk failures.
Use luksChangeKey when you are confident and in a hurry. Use the six steps when the card holds something you would hate to lose.
Related things you may actually want instead
luksKillSlot and its number. The other slots are untouched — and then make a fresh header backup, or the old one hands their access straight back.
The Whole Session, Start to Finish
The same job again, this time as one unbroken terminal session with notes written into it — the way it looks over someone's shoulder. Useful as a final review before you start, and as a sanity check if you lose your place halfway through.
Lines beginning # are notes, not commands. Everything else is typed.
# --- do I even need to install anything? ---------------------------------
cryptsetup --version
cryptsetup 2.7.0 flags: UDEV BLKID KEYRING FIPS KERNEL_CAPI HW_OPAL
# a version = already installed.
# 'command not found' would mean:
# sudo apt install cryptsetup
# --- find it -------------------------------------------------------------
# drive UNPLUGGED first, so I can see what changes
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS
sda 931,5G disk
└─sda2 931,0G part /
# now plug it in, wait 5 seconds, run the same thing again
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS
sda 931,5G disk
└─sda2 931,0G part /
sdb 7,5G disk # new. 7.5G. that's my card.
└─sdb1 7,5G part /media/you/SD32G # and the desktop already mounted it
# turn 'sdb' into a name that won't be 'sdc' tomorrow
ls -l /dev/disk/by-id/ | grep sdb
usb-Generic_STORAGE_DEVICE-0:0 -> ../../sdb # take this
usb-Generic_STORAGE_DEVICE-0:0-part1 -> ../../sdb1 # NOT this (-part1)
# --- free it -------------------------------------------------------------
sudo umount /media/you/SD32G
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0
sdb 7,5G disk
└─sdb1 7,5G part exfat # MOUNTPOINTS empty now. good.
# --- destroy and rebuild -------------------------------------------------
# everything below this line is irreversible
sudo dd if=/dev/zero of=/dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 bs=1M count=16 oflag=direct conv=fsync status=progress
16777216 bytes (17 MB, 16 MiB) copied, 3,3396 s, 5,0 MB/s # 16777216. good.
sudo cryptsetup --verbose luksFormat --type luks2 --label myvault --cipher aes-xts-plain64 --key-size 512 --pbkdf argon2id --pbkdf-memory 65536 --iter-time 1000 /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0
Are you sure? (Type 'yes' in capital letters): YES # capitals or it cancels
Enter passphrase for /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0:
Verify passphrase:
Key slot 0 created.
Command successful.
# --- check the header BEFORE putting anything on it ----------------------
sudo cryptsetup luksDump /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 | grep -E 'UUID|Memory'
UUID: f36fca8f-dbcb-4e2a-8811-c6578d65f2ce # write this down
Memory: 65536 # MUST be 65536
# --- fill it -------------------------------------------------------------
sudo cryptsetup --verbose open /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 myvault
Key slot 0 unlocked.
Command successful.
sudo mkfs.ext4 -L myvault -E root_owner=$(id -u):$(id -g) /dev/mapper/myvault
Creating journal (16384 blocks): done # pauses here ~15s. not stuck.
Writing superblocks and filesystem accounting information: done
sudo mkdir -p /mnt/myvault
sudo mount /dev/mapper/myvault /mnt/myvault
echo "it works" > /mnt/myvault/proof.txt && cat /mnt/myvault/proof.txt
it works # no sudo needed. root_owner did that.
# --- seal it -------------------------------------------------------------
cd ~
sudo umount /mnt/myvault
sudo cryptsetup close myvault
lsblk -f /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0
sdb crypto_LUKS 2 myvault f36fca8f-... # nothing indented under it = sealed
# --- back up the spare lock ----------------------------------------------
sudo cryptsetup luksHeaderBackup /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 --header-backup-file ~/myvault-luks-header.img
# silence = success
sudo cryptsetup luksDump ~/myvault-luks-header.img | grep -E 'UUID|Memory'
UUID: f36fca8f-dbcb-4e2a-8811-c6578d65f2ce # same UUID = right drive
Memory: 65536
# --- the two proofs people skip ------------------------------------------
# 1. unplug, replug, unlock it by CLICKING it in the file manager
# 2. carry it to another computer and open it there
# until both work, you do not know that it works.
Open: sudo cryptsetup open DEV myvault then sudo mount /dev/mapper/myvault /mnt/myvault.
Close: cd ~, sudo umount /mnt/myvault, sudo cryptsetup close myvault.
Or simply click it in the file manager and use the eject button, which does both halves for you.
Reference
Everything below is here when you need it and ignorable when you do not. The walkthrough above is complete on its own; this is the why, the awkward hardware, the full list of things that can go wrong, and how to get back in when something breaks.
Why 64 MiB, and What It Trades Away
Nearly every LUKS guide tells you to run cryptsetup luksFormat with no options. That works, and it produces a drive that opens perfectly — on the machine you made it on. Take it to a smaller computer, or try to open it through your file manager rather than the terminal, and it can simply refuse.
Here is why. When you create a LUKS drive, cryptsetup runs a benchmark on the machine in front of it and picks Argon2id settings that take roughly the target time on that hardware. On a fast desktop it will happily choose a large amount of memory and a high iteration count. Those numbers are then written into the header and they never change. Every future unlock, on every future machine, must pay them.
Read your own system's defaults rather than trusting a number printed on a web page — they differ between versions and distributions, and this is the habit that keeps you right for good:
cryptsetup --help | tail -n 12Near the bottom it prints its compiled-in defaults, including a line for LUKS2's Argon2id and the memory it will ask for. On an ordinary desktop that figure is commonly measured in hundreds of megabytes to a gigabyte. Now compare that against where the drive will actually be opened:
- A single-board computer such as a Raspberry Pi may have less free RAM than the unlock alone demands. The unlock fails.
- A live USB or rescue environment is running entirely in RAM and has far less to spare than the installed system does.
- Your own file manager unlocks the drive inside the
udisksbackground service, not in your login session. Many hardened or resource-limited systems cap how much memory a background service may use — and if that cap is below what your header demands, the service is killed mid-unlock while the same passphrase works fine in a terminal. - An older or slower machine may need thirty to sixty seconds for a KDF that took four seconds to benchmark on your desktop. Graphical passphrase dialogs give up long before that and report failure.
When an unlock fails for any of the reasons above, cryptsetup does not say “not enough memory” or “this took too long”. It prints exactly this:
No key available with this passphrase.
That is the same message you get when the passphrase is genuinely wrong. So the drive looks like it has forgotten your passphrase, on a passphrase you typed correctly, and the obvious next move — reformat it and start again — destroys data that was never in danger. Before you ever conclude that you have forgotten a LUKS passphrase, try it in a terminal on the machine that created the drive. If it opens there, your passphrase is fine and the problem is the header's KDF settings.
The fix is to choose the settings yourself instead of letting a benchmark choose them. This procedure uses --pbkdf-memory 65536 (64 MiB) and --iter-time 1000 (one second). Sixty-four mebibytes is small enough that every device worth plugging a memory card into can afford it, and one second is quick enough that no graphical dialog gives up.
You have not thrown your security away by doing this. Argon2id at 64 MiB is still memory-hard, which is the property that makes large-scale guessing expensive; you have moved cost off the honest unlock and onto the attacker's scale. What now carries your security is passphrase length. Use five or more random words. A five-word passphrase from a large wordlist is beyond brute force regardless of the KDF setting, and a short passphrase is guessable regardless of it too — so this is where the effort belongs.
Start Here: Which Route Are You On?
Four questions decide everything that follows. Answer them now, in order, and you will never have to undo a step later. If you are unsure about any of them, take the answer marked recommended — it is right for the large majority of people, and the reasons are given so you can tell when you are the exception.
Yes. Stop here: LUKS will not help you. Windows and macOS cannot read a LUKS drive at all, and Windows will offer to format it, which destroys it. Use VeraCrypt instead, which runs on all three systems.
A partition. Choose this if the drive will regularly be plugged into Windows machines, because a drive with a partition table makes Windows offer to format the partition rather than initialise the disk — a slightly less destructive mistake for someone else to make. It also lets you keep a small plain-text partition holding a README. The commands are identical except that you target
...-part1 instead of the whole drive; a short section near the end covers the difference.
exFAT inside the container. Only if you also use the drive with software that insists on it. It brings nothing here, because the encryption layer already blocks Windows and macOS.
Yes — genuinely old systems. Very old distributions only understand LUKS1. Add
--type luks1 instead of --type luks2 and drop the --pbkdf and --pbkdf-memory options, because LUKS1 has no Argon2 and uses PBKDF2. You lose Argon2id's memory-hardness, so make the passphrase longer to compensate. Everything else on this page is unchanged.
Steps 1 to 3 are read-only and can be repeated as often as you like. Step 4 is the first one that changes the drive, and from there to step 9 you should work through without a long break, because a half-built drive is confusing to come back to. Steps 10 to 12 are the proofs and can be done later the same day.
If you have to stop part-way, you can always start the whole thing again from step 3 — nothing accumulates, and re-running the procedure on a half-finished drive is safe. There is no state to clean up except an unlocked container, which step 3 closes.
What LUKS Actually Is
LUKS stands for Linux Unified Key Setup. It is the standard way Linux encrypts a whole drive, and it is built into the kernel rather than bolted on. A LUKS drive has two parts: a header at the very front, and the rest of the drive holding your data as ciphertext.
The header is the part most people misunderstand, and misunderstanding it is how data gets lost. Your passphrase does not decrypt your data. Your passphrase decrypts a randomly generated master key that lives in the header, and that key decrypts the data. This indirection buys you something useful: you can change your passphrase in a second, without re-encrypting a single byte, because only the small encrypted copy of the key changes.
It also carries a consequence that surprises people. If the header is overwritten, the master key inside it is gone and the data is unrecoverable — even though your passphrase is still perfectly correct and the ciphertext is still sitting there untouched. That is why this procedure backs the header up while the drive is still empty, rather than mentioning it at the end.
There is a third piece, and it is the one this page exists for. Between your passphrase and that master key sits a deliberately slow function called a key derivation function, or KDF. Its whole job is to be expensive, so that someone guessing passphrases has to pay that cost on every single guess. Modern LUKS uses a KDF called Argon2id, which is expensive in memory as well as time — and the amount of memory it demands is baked into your drive's header at the moment you create it. Choose it badly and your drive will not open on other machines. That is the single most common way this goes wrong, and almost no guide mentions it.
The Words You Need
/dev/sdb. Naming the wrong one is the single mistake that costs people their data.
myvault creates /dev/mapper/myvault, which is the readable version. Nothing about the name is stored on the drive; you may choose a different one next time.
Check the Hardware Before You Trust It
Encryption cannot rescue a drive that was never going to hold your data. Three hardware problems are common enough to check for, and all three are invisible until the moment they cost you something. None of these checks changes the drive.
Read-only file system or Operation not permitted for no apparent reason. If anything at all reports read-only, eject the card, look at the switch, slide it up, and reinsert. Check this before you believe any other diagnosis — software cannot override it.
The capacity test, and it is worth the time on any card you did not buy from a shop you trust. Install the tool and run the write half; it fills the drive with a known pattern and then verifies it reads back.
lsblk -o NAME,SIZE,LABEL,MOUNTPOINTSRead the MOUNTPOINTS column for your drive — it will be a path like /media/yourname/SD32G. Then install the tool and run both halves against that exact path:
First check whether you already have it:
f3write --helpbash: f3write: command not found
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not installed -- run the install below.
Usage text instead means you already have it; skip the install.
sudo apt install f3f3write /media/$USER/SD32G && f3read /media/$USER/SD32GSD32G is this page's example label; use whatever lsblk printed for your own drive. The drive must be mounted and writable for this, so run it before you encrypt anything, on the drive as it came. On a genuine card f3read reports all sectors good and zero corrupted. Anything else — corrupted sectors, changed sectors, overwritten sectors — means the card is not what it claims, and no amount of encryption makes it safe. Throw it away rather than trusting it with the only copy of anything. The test takes as long as writing the whole card, so on a large slow card expect to leave it running.
Finding Your Device: Every Case
Naming the wrong device is the one mistake on this page that cannot be undone, so this section covers every shape the answer takes rather than assuming yours looks like the example.
The universal method, which works in every case: list the drives with the device unplugged, plug it in, wait five seconds, list again, and read the difference.
lsblk -o NAME,SIZE,TYPE,TRAN,MOUNTPOINTSThe TRAN column tells you how the device is attached, which is often the quickest way to spot it: usb for a stick or an external reader, and blank for an internal card slot. What appears depends on how your machine reads cards:
sdb, sdc and so on, with TRAN reading usb. This is the case the steps below are written for. Its stable name lives in /dev/disk/by-id/ and usually begins usb-.
mmcblk0 — a completely different naming scheme — and its partitions are mmcblk0p1, with a p, not mmcblk01. Everywhere this page writes /dev/sdb you would write /dev/mmcblk0. Built-in readers often have no usb- entry in by-id; look for an entry beginning mmc- instead, and if there is none, use the by-path form described below.
nvme0n1. If you are looking at one of these, stop. This page is about removable media. The RM column in lsblk -o NAME,SIZE,RM,TYPE reads 1 for removable and 0 for fixed; if it reads 0, you are about to erase a disk that lives inside the computer.
Turning the letter into a name that cannot drift. Try these three in order and use the first that produces an entry pointing at your device:
ls -l /dev/disk/by-id/ | grep -E 'sdb|mmcblk0'ls -l /dev/disk/by-path/ | grep -E 'sdb|mmcblk0'ls -l /dev/disk/by-diskseq/ | grep -E 'sdb|mmcblk0'by-id is best because it is derived from the hardware itself and follows the device between ports and between reboots. by-path describes the socket rather than the device, so it is stable only while you keep using the same physical port — acceptable for a single session, and the right fallback for built-in readers that expose nothing else. by-diskseq is a counter that changes on every plug-in; use it only to double-check, never in a command you save.
Ignore anything ending -part1, -part2 and so on. Those are partitions inside the drive. You want the entry with no part suffix, which is the whole drive.
Two identical sticks produce two nearly identical names. Cheap drives often report the same model string, so the by-id entries differ only by a serial number or not at all. If you cannot tell them apart with certainty, unplug one. Working with only the target device connected costs you thirty seconds and removes the entire class of mistake.
Never reuse a device path from an earlier session or from a web page. Re-derive it every time you sit down. The whole reason this section exists is that the short names are positions in a queue, not identities.
Final confirmation before anything destructive. Whatever path you settled on, print what is actually there and read it back to yourself. Size and model must match the object in your hand.
lsblk -o NAME,SIZE,RM,TYPE,FSTYPE,LABEL,MOUNTPOINTS /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0If the size is wrong, or RM reads 0, or you see partitions you recognise from your own computer, you have the wrong device. Go back and repeat the unplug-and-compare method. There is no penalty for checking again, and no recovery from getting it wrong.
Opening the Drive on Other Computers
This is what the drive is for, and it is where the last surprises live. Four things differ between machines, and only the first one is about encryption at all.
Memory: in the header. This is the reason for --pbkdf-memory 65536.
cryptsetup
Minimal installs and some live images omit it. Install it with that system's package manager. Nothing about your drive needs changing — the tool is missing, not the support, because the decryption itself lives in the kernel.
/media/ followed by your username, but the folder is named from the filesystem label — which is why step 5's --label and step 8's -L are worth setting. With no label you get a folder named after a long identifier, and on a drive full of them you will not know which is which.
The ownership fix. First find out who you are on this machine:
id -u; id -gIf those numbers differ from the ones the drive was built with, take ownership of the mounted drive once. It is instant on a mostly-empty drive and it sticks.
sudo chown -R $(id -u):$(id -g) /mnt/myvaultIf you routinely move the drive between machines where your user number differs, there are two better answers than repeating that. Either keep the drive's contents inside a folder whose permissions are open to everyone on the machines you control, or put exFAT inside the container instead of ext4 — exFAT has no concept of ownership, so every file simply belongs to whoever mounted it. The encryption is unaffected either way; only the layer inside changes. Choose exFAT only for this reason, since it also loses journalling and Linux permissions.
If You Chose a Partition Instead of the Whole Drive
Everything above works identically; only the target changes. Create the partition table first, then aim every subsequent command at the partition rather than the disk.
sudo parted /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 --script mklabel gpt mkpart primary 1MiB 100%Then wait a moment for the system to notice the new partition, and confirm it exists:
sudo partprobe /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0; lsblk -o NAME,SIZE,TYPE /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0You should see a part line indented under the disk line. From then on, every command that named the drive now names the partition: append -part1 to the by-id path. The blanking step in the main procedure is still worth doing on the whole drive before you create the partition table, for exactly the reason given there.
Using the Drive Day to Day
The twelve steps were the one-time setup. From now on the drive takes two commands to open and three to close — or a click and a passphrase, if you proved the file-manager route in step 10. Both routes are equally correct; use whichever is in front of you.
Open it:
sudo cryptsetup open /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 myvaultthen, once it has unlocked:
sudo mount /dev/mapper/myvault /mnt/myvaultClose it. Do these in order and never skip the last one — unmounting without closing leaves the decrypted container exposed on the machine until reboot.
cd ~sudo umount /mnt/myvaultsudo cryptsetup close myvaultConfirm it is sealed before you pull the drive out. You want the crypto_LUKS line with nothing indented under it:
lsblk -f /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0If you used the file manager to open it, use the file manager's eject or safely-remove button to close it — that does the unmount and the close together. Pulling the drive out without either is the one habit that eventually costs you a filesystem check, and occasionally a file.
Inspect any drive at any time with sudo cryptsetup luksDump followed by its path. It prints the format version, cipher, KDF settings and which keyslots are occupied. It reveals nothing secret — the salts it shows are stored in the clear by design, and the encrypted keyslot material is never printed — and it changes nothing, so it is always safe when you are unsure what a drive contains.
/etc/crypttab?
You can make a machine unlock this drive automatically at boot, and for a removable drive you almost certainly should not. Automatic unlock means the key is stored on the computer, so anyone who has the computer has the drive — which removes the entire benefit of encrypting something you carry around. Worse, an entry for a drive that is not plugged in can delay or block boot on some systems.
Automate it only for a drive that lives permanently inside one machine, and even then understand that you are protecting against theft of the drive, not theft of the machine. For anything you carry, type the passphrase.
When It Goes Wrong: The Complete Reference
This section is written to be jumped into, not read through. Find the thing that happened to you, do what it says, and if the first answer does not fix it the entry tells you what to try next. Every symptom here ends in a resolution — there is no point at which the right answer is to give up or to guess.
Almost every irreversible loss in LUKS happens during an attempt to fix something. Before you reformat, restore a header, or kill a keyslot, ask one question: have I proved the drive is actually broken, or am I assuming it from an error message? The single most misleading message in this whole system tells you your passphrase is wrong when it is not. Prove it with --test-passphrase on the machine that created the drive before you accept any diagnosis that ends in erasing something.
A. The unlock is refused
Symptom: No key available with this passphrase.
Work through these in order. Stop at the first one that applies.
- 1. Is this the machine that created the drive? If no, go to point 4 — this is very likely not a passphrase problem at all. If yes, continue.
- 2. Prove the passphrase itself, away from the desktop and away from any other variable:
sudo cryptsetup open --test-passphrase --verbose /dev/disk/by-id/YOUR-DEVICE. Silence and a return to the prompt means the passphrase is correct and the problem is elsewhere — go to point 4. An error here means the passphrase really was rejected; continue. - 3. Check the keyboard, not the memory. Caps Lock; a keyboard layout that silently changed at login; a passphrase typed originally on a different layout so that a symbol key produced a different character; a trailing space copied in from a password manager; a leading space; the number row versus the numeric keypad. Type the passphrase into a plain text editor first and look at it. If you set the passphrase only minutes ago and it is already refused, the layout is the most likely culprit by a wide margin.
- 4. Compare what the header demands against what this machine can give. Run
sudo cryptsetup luksDumpon the drive and readMemory:under the keyslot. Then runfree -mon the machine that is refusing. If the header wants more than that machine has free, you have found it: the unlock is being killed and the failure is reported as a wrong passphrase. The fix is to rebuild the drive with--pbkdf-memory 65536 --iter-time 1000, or, if the data is already on the drive and you can open it somewhere, to add a new keyslot with those settings and remove the old one. - 5. If it fails only in the file manager and works in a terminal, that is the same cause seen through a different door — the desktop unlocks inside a background service, which may be capped below what your login session gets. Use the terminal route meanwhile; it is not a workaround, it is the same operation. Fix the header when convenient.
- 6. If it fails only on a slow or old machine, the KDF may be taking so long that the graphical dialog times out. Try the same unlock in a terminal on that machine and wait a full minute before concluding anything. If the terminal eventually succeeds, the header is too slow rather than too large; the same rebuild fixes it.
- 7. If every one of the above is ruled out, the keyslot may be damaged. Restore your header backup — see Recovery below. If you have no header backup and no working passphrase, the data is unrecoverable; that is the design, and no tool or service can undo it.
B. The format or wipe step fails
Device wipe error, offset 0together withCannot wipe header on device, and nothing in any log. The drive still carried an old signature, soluksFormaterased it first; that closes and reopens the device, the desktop's device monitor re-reads the drive to see what changed, and the re-read collides with the header write happening in the same instant. The write returns zero bytes with no error recorded in the kernel log, the audit log or the journal, which is why this one feels like a ghost. Fix: blank the first 16 MiB withdd ... oflag=directas in step 4, then format again. There is now no signature to erase and nothing for the monitor to react to.Device ... is in use.The desktop mounted the drive on insertion, or a container on it is still unlocked. Unmount every mountpoint shown bylsblk, then runls /dev/mapper/and close anything belonging to this drive withsudo cryptsetup close NAME. Ejecting the drive in the file manager and replugging it also clears both.wipefs: error: ...: probing initialization failed: Device or resource busy. Same cause as above, usually an unlocked mapping rather than a mount. The entry calledcontrolin/dev/mapper/is part of the kernel and is always there — it is not yours and must be left alone.- It returned to the prompt without ever asking for a passphrase. You answered the confirmation with something other than capital
YES. It writes'yes'in lowercase and accepts onlyYES, and anything else aborts silently. Nothing was changed. Run it again. Read-only file system, or every write fails for no reason. Check the physical write-protect switch on the card or adapter first. If there is none or it is already off, the card's controller may have failed into read-only mode, which flash does at end of life to preserve what is there. Copy anything you still want off it and replace the card — this is not fixable in software.No space left on devicewhile writing only 16 MiB. The card is a counterfeit reporting a capacity it does not have. Run thef3test described earlier. Do not encrypt it.
C. The device cannot be found
Device /dev/sdb does not exist or access denied.The letter moved, which is normal — letters are handed out in plug-in order, so unplugging something else can renumber your drive. Re-derive the path:lsblk, thenls -l /dev/disk/by-id/. Use theby-idpath from then on so it cannot recur.Device ... does not existwhen you used aby-idpath. The drive is unplugged, the reader is empty, or the card is not seated. Reseat it, try another port, and look for it withlsblkbefore doing anything else.- Nothing new appears in
lsblkat all. In order: try a different USB port, preferably one directly on the machine rather than on a hub; try a different cable; try the card in a different reader. If the card is a microSD in an adapter, reseat it in the adapter — a partly-inserted microSD is extremely common and looks exactly like a dead card. If nothing works and the card is unreadable on two machines, it has failed. - The device appears as
mmcblk0rather thansdb. Not a fault: that is what a built-in SD slot produces. Use that name, and remember its partitions carry ap—mmcblk0p1. - You see two almost identical entries in
by-id. Two drives of the same model. Unplug one and repeat. Do not guess between them.
D. The desktop and the file manager misbehave
An operation is already pending.A previous unlock crashed and left a job in the service's queue. Clear it withsudo systemctl restart udisks2, then unplug and replug the drive. If it comes back on the next attempt, stop clearing it — the stuck job is the after-effect, and the cause is the unlock crashing, which sends you to section A point 4.Message recipient disconnected from message bus without replying.The dialog asked the background service to unlock the drive and the service died before answering. Same cause, seen from the other end. Treat it as strong evidence of a resource limit rather than as a mystery.- The passphrase dialog spins forever and then fails, while the terminal works. The cleanest possible signature of a per-service resource cap. Your login session has the whole machine's memory; the background service may not. Fix the header rather than the machine, so the drive works everywhere rather than only here.
- The drive mounts but shows as read-only in the file manager. Either the physical switch, or the filesystem was not cleanly unmounted last time and has been mounted read-only for safety. For the second case, close everything, then run
sudo fsck.ext4 -f /dev/mapper/myvaulton the unlocked mapper device with the drive open but not mounted, and answer yes to repairs. - The drive shows as
crypto_LUKSwith nothing indented beneath it. Not a fault at all — that is exactly what a healthy, closed container looks like. Open it. - Nothing happens at all when you plug it in. Some desktops do not auto-prompt for encrypted volumes. Open the Disks application, or just use the terminal route. Nothing is wrong.
E. Mounting, permissions and unmounting
target is busywhen unmounting. Something is inside the folder. Runcd ~in every terminal you have open and close any file manager window showing the drive. If it persists, find the culprit withlsof +f -- /mnt/myvaultorsudo fuser -vm /mnt/myvault, which name the process holding it. Never unplug the drive to escape this message — that is how filesystems get damaged, and it is entirely avoidable.Permission deniedwriting to your own encrypted drive. The filesystem's top folder belongs torootbecauseroot_ownerwas omitted or did not apply. Fix it once withsudo chown -R $(id -u):$(id -g) /mnt/myvaultrather than usingsudoforever.- Files appear to belong to a stranger on another machine. Your user number differs there. Same
chownfix, or see the cross-machine section for the permanent answers. special device /dev/mapper/myvault does not exist. The container is not open. Open it first; opening and mounting are two separate operations and this message means you skipped the first.mount: unknown filesystem type 'crypto_LUKS'. You aimedmountat the drive instead of at the unlocked mapper device. Mount/dev/mapper/NAME, never theby-idpath.
F. Messages that look alarming and are not
Error reading passphrase from terminal.This is not a wrong-passphrase message. It means cryptsetup could not read from the terminal at all — usually because the command was pasted with something after it, run from a script, or run where no keyboard is attached. Re-run it on its own, typed into a normal terminal, and type the passphrase by hand.Command failed with code -1 (wrong or missing parameters).A typo in the command itself, not a problem with the drive. The commonest cause is a long line that broke when it was pasted, so part of it arrived as a second line. Paste it again as one line.WARNING: Device … already contains a 'crypto_LUKS' superblock signature.Expected when you are re-encrypting a drive that was already encrypted. It is a warning, not a refusal — you will still be asked to confirm. If you did not expect it, stop and check you have the right device.sudo: a password is required, on a command you expected to just run. Yoursudosession expired — they last a few minutes. Run the command again and type your login password when asked.- The passphrase prompt gives up after three tries.
cryptsetupallows three attempts and then exits. Nothing is locked, nothing is damaged, and there is no penalty or counter — simply run the command again. A LUKS drive cannot be “locked out” by wrong guesses. No usable token is available.Printed before the passphrase prompt on every unlock. It means you have no hardware key or keyring entry set up, which is normal and correct. Ignore it.- The device is called something different from last time. Not a fault. Kernel letters are handed out in plug-in order. This is the entire reason the walkthrough uses
/dev/disk/by-id/.
Recovery: Getting Back In
What is recoverable depends entirely on which piece you still have. Find your row before you do anything.
Restoring a header. This overwrites the drive's current header with the one in your backup file. Read the warning under the command before running it.
sudo cryptsetup luksHeaderRestore /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 --header-backup-file /path/to/myvault-luks-header.imgThe master key lives in the header. Put a different drive's header on this drive and the key that decrypts this data is gone — the ciphertext is intact and permanently unreadable. Always confirm the backup belongs to this drive first, by comparing the UUID in the file against the UUID on the drive:
sudo cryptsetup luksDump /path/to/myvault-luks-header.img | grep UUIDIf the drive's own header is too damaged to print a UUID, match on size and label instead, and if you cannot establish which drive the file belongs to, do not restore it. Also remember that a restored header brings back the keyslots it contained: a passphrase you deliberately removed will start working again, and a passphrase you added since will stop.
Checking a filesystem inside the container. If the drive opens but the files look wrong, or it mounts read-only after a bad unplug, unlock it without mounting and check the filesystem:
sudo cryptsetup open /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 myvault; sudo fsck.ext4 -f /dev/mapper/myvaultRun this on the mapper device and never on the drive itself. Aiming a filesystem tool at the encrypted drive damages the header, which turns a recoverable problem into a header restore.
If you deliberately want the data gone, you do not need to overwrite the whole drive. Destroying the header destroys the master key, and without it the ciphertext is noise forever. Blanking the first 16 MiB as in step 4 is sufficient and takes seconds rather than hours — provided no header backup survives anywhere, which is exactly why you should know where all your backups are.
Where the Passphrase and the Header Live
An encrypted drive is only as recoverable as the two things that open it. Decide where both live now, while the drive is empty and a mistake costs nothing.
- The passphrase is the whole of your security and there is no reset. Put it in a password manager, and record the drive's UUID from step 6 alongside it so you can tell which entry belongs to which drive once you own several. Recording the KDF settings there too takes five seconds and answers a future question you will otherwise have to rediscover.
- The header backup from step 11 is a spare lock, not a spare key. Anyone holding that file and your passphrase can open the drive; anyone holding it without the passphrase has nothing. Store it where you store passwords, and never on the encrypted drive itself — that is locking your only spare inside the safe.
- An old header backup keeps working. Restoring one restores the keyslots it contained, so a passphrase you removed starts opening the drive again and one you added stops. Whenever you change the keyslots, make a fresh backup and clearly retire the old one — move it into a folder named for what it is rather than deleting it, because you may one day need to prove which drive it belonged to.
- Keep at least one copy off the machine. A header backup that lives only on the computer you use the drive with dies with that computer. The drive itself is then still encrypted and still needs its passphrase, so this is about surviving a damaged header, not about surviving a lost passphrase.
The commonest failure in a well-organised setup is a loop: the drive's passphrase lives in a password database, the database lives on an encrypted disk, and that disk's passphrase lives in the database. Every link is sensible. The set is unopenable the moment the machine holding it is gone.
Trace your own chain outward and find the two or three secrets that must sit outside every container you own. Those belong somewhere physical — written down, stored where you would keep a passport. Everything else can safely live inside. Do this once, on paper, and the whole structure becomes survivable.
Test it honestly with one question: if this computer died tonight, what would I still be able to open tomorrow? If the answer is “nothing”, you have found a circle.
What This Protects You From, and What It Does Not
- It protects a lost or stolen drive. Sealed, the drive is random noise to anyone who picks it up. This is the threat disk encryption genuinely solves, and it solves it completely.
- It does not protect an open drive. While the container is unlocked and mounted, the data is ordinary readable data to anything running on that computer, including anything malicious. Encryption protects a drive at rest, never a machine in use. Close the drive when you are not using it, rather than leaving it mounted all day.
- It does not protect against a forgotten passphrase. There is no reset link and nobody to ask. A forgotten passphrase and a stolen drive have the same outcome — which is exactly why the diagnosis in section A matters before you conclude that you have forgotten one.
- It does not hide that encryption is in use. Anyone examining the drive sees a LUKS header and knows it is encrypted. LUKS makes data unreadable, not invisible. If you need the existence of the data to be deniable, that is a different tool and a much harder problem.
- It does not protect the copies you already made. Encrypting a drive does nothing about the same files sitting in your Downloads folder, in a cloud sync folder, or in a backup. Think about where else the data is.
- A backup is still a separate job. Encryption protects a drive from being read, not from failing. An encrypted drive that dies takes your only copy with it, and flash memory in particular does die. Two encrypted drives are the answer, not one.
Quick Reference
Everything on one screen, once you know what you are doing. The device path shown is this page's worked example — substitute the one ls -l /dev/disk/by-id/ printed for your own drive, and your own name in place of myvault.
Find the drive:
lsblk -o NAME,SIZE,RM,TYPE,TRAN,FSTYPE,LABEL,MOUNTPOINTSls -l /dev/disk/by-id/ | grep -E 'sdb|mmcblk0'Create it (destroys the drive; blank first, then format, then build):
sudo dd if=/dev/zero of=/dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 bs=1M count=16 oflag=direct conv=fsync status=progresssudo cryptsetup --verbose luksFormat --type luks2 --label myvault --cipher aes-xts-plain64 --key-size 512 --pbkdf argon2id --pbkdf-memory 65536 --iter-time 1000 /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0sudo cryptsetup open /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 myvaultsudo mkfs.ext4 -L myvault -E root_owner=$(id -u):$(id -g) /dev/mapper/myvaultUse it:
sudo cryptsetup open /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 myvaultsudo mkdir -p /mnt/myvaultsudo mount /dev/mapper/myvault /mnt/myvaultPut it away:
cd ~sudo umount /mnt/myvaultsudo cryptsetup close myvaultCheck and maintain it:
sudo cryptsetup luksDump /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0sudo cryptsetup open --test-passphrase --verbose /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0sudo cryptsetup luksAddKey --pbkdf argon2id --pbkdf-memory 65536 --iter-time 1000 /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0sudo cryptsetup luksHeaderBackup /dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 --header-backup-file ~/myvault-luks-header.imgThe one number to remember: Memory: 65536 in luksDump. If it reads much larger, the drive was built with benchmarked defaults and will eventually refuse to open somewhere that matters.
Do It Without This Page
Once you have done it once, the whole procedure is six moves and one habit:
lsblkbefore and after plugging the drive in, thenls -l /dev/disk/by-id/to turn the letter into a name that cannot drift. This is the habit, and it is the one that matters.umountanything the desktop mounted for you, andcryptsetup closeanything still unlocked.ddzeros over the first 16 MiB, so the format has nothing to race against.cryptsetup luksFormatwith--pbkdf-memory 65536 --iter-time 1000, confirmed with capitalYES.cryptsetup open, thenmkfs.ext4withroot_owneron the mapper path, thenmount.luksDumpto confirmMemory: 65536,luksHeaderBackupto save the spare lock, and an unlock on a second machine to prove it travelled.
The same procedure works on every Linux distribution, because LUKS is part of the kernel rather than of any one system. If you also need storage that opens on Windows and macOS, the trade-off is a cross-platform tool instead of the native one, and our guide to VeraCrypt for beginners covers that route. Whichever you choose, the passphrase remains the whole of your security — it deserves the same care as the credentials covered in Linux file permissions.