You need a computer running Linux Mint, your own user password (the one you type when a command asks for sudo), and a drive you are willing to erase completely — a USB stick or a spare internal disk. Nothing here costs money and nothing is downloaded except one package that Mint may already have.
🔴 Everything on that drive will be destroyed. Not moved, not hidden — destroyed. Copy anything you want to keep off it first, then check the drive 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 ten minutes for this page.
What you will be able to do: turn a spare drive into an encrypted volume that is unreadable to anyone who does not have your passphrase — and prove at every single step that it worked, instead of hoping.
These commands encrypt a spare drive. They cannot encrypt the system disk your Mint is currently running from, for the same reason you cannot rebuild a floor while standing on it. Mint's installer offers 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.
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 Mint 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 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 of the drive, because only the small encrypted copy of the key changes.
It also carries a consequence that surprises people. If the header is overwritten, the 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 step 5 of this procedure backs the header up before you put anything on the drive, and why we put it that early rather than mentioning it at the end.
The Words You Need
/dev/sdb. Naming the wrong one is the single mistake that costs people their data.
/dev/sdb as 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.
Encrypt the Drive in Nine Commands
Every command below is written out in full. The only thing you substitute is the device name, which step 2 tells you how to find. Run them one at a time and read what comes back before moving on — each step tells you exactly what a success looks like.
Go: open a terminal. On Linux Mint press Ctrl+Alt+T, or click the menu and type terminal.
Do: type this and press Enter, then type your own user password when it asks. Nothing appears on screen while you type a password — not even dots. That is normal, and it is not frozen.
sudo apt install cryptsetupYou should see: either apt downloading and installing it, or a line telling you cryptsetup is already the newest version. Both outcomes are success — you are ready either way.
If not: E: Unable to locate package cryptsetup means Mint's package list is stale rather than the tool being missing. Run sudo apt update, wait for it to finish, then run the install command again.
Go: the same terminal, with your USB drive unplugged. Unplug it now if it is in.
Do: run this command and read the list. Then plug the drive in, wait about five seconds, and run the exact same command a second time.
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTSYou should see: one new line in the second listing that was not in the first, with disk in the TYPE column and a SIZE close to the capacity printed on the drive. Its NAME is something like sdb or sdc, and your device path is /dev/ followed by that name. Do not guess it — read it.
If not: if no new line appears, the drive, the cable or the port is at fault; try a different USB port before assuming the drive is dead. If two new lines appear, something else was plugged in at the same time — remove it and repeat the step from the beginning.
Step 4 destroys everything on whatever device you name, and it asks for confirmation exactly once. There is no undo, no recycle bin, and no second chance. Three habits make this safe: run lsblk again whenever you are unsure — it changes nothing and costs nothing; name the whole disk (/dev/sdb) and not a partition on it (/dev/sdb1); and never carry a device name over from a previous session, because the letters are assigned in the order things are plugged in and today's sdb is tomorrow's sdc.
Go: the same terminal. Mint mounts USB drives automatically the moment you plug them in, so this step is almost never skippable.
Do: list just your drive, substituting the name you found in step 2. If anything at all appears in the MOUNTPOINTS column, unmount that line with sudo umount followed by the path shown beside it, then run this command again to confirm.
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS /dev/sdbYou should see: your drive listed with the MOUNTPOINTS column completely empty on every line. That empty column is the proof that nothing is holding the drive open.
If not: if umount replies that the target is busy, something still has the drive open. Close any file manager window showing it, and make sure your terminal is not sitting inside the drive itself — type cd ~ and try the unmount again.
Go: the same terminal. This is the step that erases the drive, so read the confirmation it prints rather than answering it from memory.
Do: run the command below with your device name. It will ask you to confirm, then ask for a new passphrase twice. Choose something long that you will still know in a year — there is nobody to reset it.
sudo cryptsetup luksFormat /dev/sdbYou should see: this exact warning, naming your device, followed by two passphrase prompts. When it finishes it simply returns you to the prompt with no success message — silence here means it worked.
WARNING!
========
This will overwrite data on /dev/sdb irrevocably.
Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sdb:
Verify passphrase:If not: if it returned to the prompt immediately without ever asking for a passphrase, you answered the confirmation wrongly. The prompt writes 'yes' in lowercase but accepts only capital YES, and anything else aborts silently rather than complaining — run the command again and type YES. If instead it refused because the device is in use, go back to step 3.
Go: the same terminal. Do this now rather than later, while the drive is still empty and the cost of a mistake is zero.
Do: write a copy of the header to your home folder.
sudo cryptsetup luksHeaderBackup /dev/sdb --header-backup-file ~/luks-header-backup.imgYou should see: no output whatsoever. Confirm it exists with ls -l ~/luks-header-backup.img, which lists a file of roughly 16 MB whose permissions read -r-------- — readable by its owner and nobody else, which cryptsetup sets deliberately.
If not: if it refuses because the file already exists, it will not overwrite an existing backup. Choose a different filename rather than deleting the old one — an old header backup is still a working key to whatever drive it came from.
Anyone holding that file and your passphrase can open the drive. Store it where you store passwords — and never on the encrypted drive itself, which is like locking your only key inside the safe. One more thing worth knowing before you need it: restoring an old header restores the keyslots it contained, so a passphrase you later removed starts working again. If you ever change or remove a passphrase, make a fresh backup and destroy the old one.
Go: the same terminal.
Do: unlock the drive and give it a name. myvault is your choice of label, not a fixed word — whatever you write becomes the last part of the path in the next step.
sudo cryptsetup open /dev/sdb myvaultYou should see: nothing at all after you type the passphrase. A successful open prints no message. Prove it worked with ls -l /dev/mapper/myvault, which now lists an entry that did not exist a moment ago.
If not: No key available with this passphrase. means the passphrase was rejected. Check Caps Lock and your keyboard layout — and bear in mind that whatever you typed twice in step 4 is the passphrase now, exactly as typed, including a trailing space or a character produced by a different layout.
Go: the same terminal. An opened container is a blank disk with no structure yet, so nothing can be saved to it until this step.
Do: format the mapper device. Read the path twice before pressing Enter: it must be /dev/mapper/myvault and never /dev/sdb.
sudo mkfs.ext4 /dev/mapper/myvaultYou should see: a line beginning mke2fs with a version number, then Creating filesystem with and a block count, then progress lines for the inode tables and the journal, finishing with Writing superblocks and filesystem accounting information: done.
If not: No such file or directory means step 6 did not actually open the container — run it again and watch for the passphrase error. If you aimed this command at /dev/sdb by mistake you have overwritten the LUKS header; that is exactly what step 5 was for, and sudo cryptsetup luksHeaderRestore puts it back.
Go: the same terminal.
Do: run these four commands one at a time, pressing Enter after each and waiting for the prompt to come back. The third line hands you ownership so that you can save files without sudo; the fourth proves the whole thing works.
sudo mkdir -p /mnt/myvault
sudo mount /dev/mapper/myvault /mnt/myvault
sudo chown $USER:$USER /mnt/myvault
echo "it works" > /mnt/myvault/proof.txt && cat /mnt/myvault/proof.txtYou should see: the words it works printed back at you. Now run lsblk -f /dev/sdb: your drive appears as crypto_LUKS, with a second line indented underneath it whose FSTYPE is ext4 and whose mountpoint is /mnt/myvault. That nesting is what an open, working encrypted drive looks like.
If not: Permission denied when writing the file means the chown line was skipped or was pointed at a different folder. Re-run it exactly as written, then try the echo line again.
Go: the same terminal. Nothing may be sitting inside the folder — not a file manager window, not another terminal.
Do: step out of the folder, detach it, then lock the container. Three commands, one at a time.
cd ~
sudo umount /mnt/myvault
sudo cryptsetup close myvaultYou should see: no output from either of the last two commands. Run lsblk -f /dev/sdb once more: the drive still shows as crypto_LUKS, but there is now nothing indented underneath it. The data is sealed and the drive is safe to unplug.
If not: target is busy means something still holds the folder open. Close file manager windows, run cd ~ in every terminal you have open, then try the unmount again. Never unplug a drive to escape this message — that is how filesystems get damaged.
Using the Drive Tomorrow
The nine steps above were the one-time setup. From now on the drive takes two commands to open and three to close. Check the device name with lsblk first every time, because the letter can change between one plug-in and the next.
sudo cryptsetup open /dev/sdb myvault
sudo mount /dev/mapper/myvault /mnt/myvaultcd ~
sudo umount /mnt/myvault
sudo cryptsetup close myvaultYou can also confirm what a drive is at any time with sudo cryptsetup luksDump /dev/sdb, which prints the header in readable form: the format version, the cipher in use, and which keyslots are occupied. It reveals nothing secret and it changes nothing, so it is always safe to run when you are unsure what a drive contains.
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 that disk encryption genuinely solves, and it solves it completely.
- It does not protect an open drive. While the container is open and mounted, the data is ordinary readable data to anything running on that computer. Encryption is protection for a drive at rest, never for a machine in use.
- It does not protect against a forgotten passphrase. There is no reset link, no recovery email and nobody to ask. A forgotten passphrase and a stolen drive have exactly the same outcome.
- 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.
- Windows will not read it, and will usually offer to format the drive when you plug it in. Say no. That offer is Windows failing to recognise the format, not the drive being broken.
- A backup is still a separate job. Encrypting a drive protects it from being read, not from failing. An encrypted drive that dies takes your only copy with it.
When It Goes Wrong
- The confirmation never asked for a passphrase. You typed something other than capital
YES. Nothing was changed; run step 4 again. No key available with this passphrase.The passphrase is wrong. Check Caps Lock, then your keyboard layout — a layout switch can silently change which characters your keys produce.Device /dev/sdb is in useor similar. Mint auto-mounted it. Return to step 3 and unmount every mounted partition on the drive.target is busywhen unmounting. A terminal or file manager is inside the folder.cd ~in each terminal, close the windows, and retry.- The drive letter changed. Normal, and expected. Letters are handed out in plug-in order. Run
lsblkand use what it says today. - The drive shows as
crypto_LUKSwith nothing under it. Not a fault — that is a correctly closed container. Open it with step 6.
Your Turn
You plug the drive into your Mint machine, run lsblk -f, and see your drive listed with crypto_LUKS in the FSTYPE column and no indented line beneath it. A colleague looking over your shoulder says the drive is broken because the file manager shows no files.
Are they right — and which single command changes what you are both looking at?
They are wrong: that is exactly what a healthy, closed container looks like. Nothing indented underneath means the encryption is sealed, which is the state you want whenever you are not actively using the drive. The command that changes it is sudo cryptsetup open /dev/sdb myvault, which asks for the passphrase and makes the indented line appear. Note what it does not do: the files are still not browsable until you mount it as well. Opening and mounting are two steps, and confusing them is the most common reason people think an encrypted drive has failed.
Do It Without This Page
Once you have done it once, the whole procedure is six moves and a habit:
lsblkbefore and after plugging the drive in. The line that appears is your device. This is the habit, and it is the one that matters.umountanything Mint mounted for you.cryptsetup luksFormatthe whole disk, confirm with capitalYES, set a passphrase.cryptsetup luksHeaderBackupstraight away, and store the file like a key.cryptsetup open, thenmkfs.ext4on the mapper path, thenmount.umount, thencryptsetup close. Confirm withlsblk -fthat nothing is indented underneath.
The same procedure works on any Linux system, not only Mint — LUKS is part of the kernel rather than of any one distribution. If you also need encrypted storage that opens on Windows and macOS, the trade-off is a cross-platform tool instead of the native one; our guide to VeraCrypt for beginners covers that route. And whichever you choose, the passphrase remains the whole of your security: it deserves the same care as the ones covered in Linux file permissions and every other credential you hold.