Erase Every LUKS Keyslot with cryptsetup

Decommissioning a drive for good is exactly what cryptsetup erase is built for: it strips every LUKS keyslot in one irreversible pass. This is a disposal operation, not a repair tool, and it is not equivalent to removing one passphrase with luksRemoveKey. The build covered here is cryptsetup 2.7.0 from cryptsetup-bin 2:2.7.0-1ubuntu4.2.

Budget about fifteen minutes, most of it spent identifying the right device rather than running the command. You need a shell, the cryptsetup-bin package, and root access, since writing encryption metadata normally needs sudo. Everything up to the actual erase can be done read-only.

1. Know exactly what this destroys

• Every keyslot goes at once. cryptsetup erase removes all LUKS keyslots, not one passphrase the way luksRemoveKey does.
• The container becomes permanently inaccessible. Without a keyslot there is no way to recover the volume key through the LUKS header. The operation is irreversible.
• It does not touch visible file data. The bytes stay put; only the ability to decrypt them disappears.

Stop here if you might still need the data, any existing passphrase, or a future recovery path. A LUKS header backup does not make this safely reversible: restoring one only helps if you still have the backup and understand the consequences, and the backup itself is sensitive encryption metadata. Make a verified backup before an operation meant to preserve access, not as a last-second rescue for a deliberate erase.

2. Confirm the installed syntax

This read-only check confirms the version and shows both command names. The old luksErase spelling is an alias for the same operation:

$ cryptsetup --version
cryptsetup 2.7.0 flags: UDEV BLKID KEYRING FIPS KERNEL_CAPI HW_OPAL
$ cryptsetup erase --help
Usage: cryptsetup erase <device>
$ cryptsetup luksErase --help
Usage: cryptsetup luksErase <device>

The full help output can include more global options than shown here. The relevant positional argument is the encrypted device, such as /dev/nvme0n1p3 or a stable path under /dev/disk/by-id/. Prefer the stable path when hardware enumeration could change.

3. Check the target without erasing it

Inspect the target and its neighbours first. Neither command below alters storage:

$ lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,LABEL,MOUNTPOINTS /dev/nvme0n1
$ readlink -f /dev/disk/by-id/REPLACE_WITH_THE_DEVICE_ID

Replace both placeholders with values from your machine. Confirm the path resolves to the intended whole encrypted device or partition, not an active mapper path such as /dev/mapper/secure-data. Stop and close or unmount any active use according to your normal maintenance procedure: erasing metadata under a live workload can disrupt that workload and leaves the running mapping in an unsafe state.

For a non-destructive command-line check, cryptsetup 2.7.0 accepts --test-args:

$ cryptsetup --test-args erase /dev/nvme0n1p3
No action taken. Invoked with --test-args option.

This checks argument handling only. It does not prove the path is the right LUKS device, and it does not simulate the erase.

4. Erase all keyslots

Once the target and change decision are confirmed, run the operation with elevated privileges, replacing the example path exactly:

$ sudo cryptsetup erase /dev/nvme0n1p3

On a normal, non-HW-OPAL LUKS device the installed manual says no password is required. A quiet return to the shell is the usual successful result, so check the exit status immediately:

$ printf 'exit status: %s\n' "$?"
exit status: 0

Do not add --batch-mode casually. It suppresses confirmation questions, which makes it especially risky in a copied command or script. If you do use it for a controlled, reviewed automation job, treat the device path as a separately validated input.

5. Handle detached headers and HW OPAL

• Detached header. A LUKS2 header stored separately from the data device. For an HW OPAL-enabled data device, point --header HEADER_DEVICE_OR_FILE at it, confirmed from your documented layout and a LUKS inspection done before the change, never guessed from a file name.
• HW OPAL factory reset moves the safety boundary. --hw-opal-factory-reset performs a whole-device OPAL factory reset. The local manpage warns that all data on the device can be lost regardless of partition, that a LUKS2 header backup does not protect it, and that a valid LUKS2 header is not even required for the reset to run. Never add this option to an ordinary LUKS erase as a troubleshooting step.
• OPAL credentials come from a key file. --key-file FILE reads the Admin PIN, or the PSID when paired with the factory-reset option. A value of - reads from standard input without stopping at newline characters. Keep credentials out of shell history.

If you are not deliberately administering HW OPAL, leave both OPAL-specific options out and stop if the device's encryption design is unclear.

6. Know the failure modes

A non-zero exit status means the operation failed, not a reason to repeat the command blindly. Record the error, confirm the path, check whether the device is busy, and follow your storage change procedure. For diagnostics to share with the cryptsetup project, add --debug, remembering that debug output may disclose device and metadata details:

$ sudo cryptsetup --debug erase /dev/nvme0n1p3

If the command reports that locking cannot be used, do not jump to --disable-locks. That option disables protection for on-disk metadata and exists only for restricted environments where the /run directory cannot be used. Fix the environment or get an explicit, reviewed exception first.