Resume a Suspended LUKS Mapping with cryptsetup

cryptsetup luksResume puts the encryption key back into a suspended device-mapper mapping so applications can use it again. This is a short operation, usually a few minutes, but it needs the correct LUKS credential and root access.

Before you start

A suspended mapping is deliberately disruptive: I/O waits while it is suspended, and the encryption key has been removed from kernel memory. Do not suspend or resume a mapping casually on a busy service. If the suspended filesystem contains the system or the tools needed to recover it, use an out-of-band console and plan for blocked I/O.

1. Identify the mapping

Set a shell variable to the mapper name. Replace the example value with the name shown by the operator who suspended the device, or with the directory entry under /dev/mapper.

MAPPING=vault
ls -l "/dev/mapper/$MAPPING"
sudo cryptsetup status "$MAPPING"

Checkpoint: before resuming, cryptsetup status should identify the mapping as suspended or otherwise show that it is not usable. A missing path means the name is wrong or the mapping has already been closed. Do not substitute /dev/sdb2, a UUID, or the filesystem mount point for the mapper name.

2. Resume with an interactive passphrase

For the normal case, let cryptsetup ask on the terminal:

sudo cryptsetup luksResume "$MAPPING"

On success, the command normally returns to the shell without a success message. It reinstates the key and unblocks the suspended mapping. Verify the state immediately:

sudo cryptsetup status "$MAPPING"

Checkpoint: check that the status identifies the expected active mapping, device and encryption details. If a filesystem was already mounted, a small read such as ls /path/to/mount can confirm that normal access has returned. Use a real mount path only after checking that it belongs to this mapping.

3. Use a key file when automation requires it

Pass a key file with --key-file (or -d). The file contains the passphrase input, so protect it with suitable ownership and permissions and avoid leaving it in a shared temporary directory.

sudo cryptsetup luksResume \
  --key-file /root/secure/luks-passphrase \
  "$MAPPING"
sudo cryptsetup status "$MAPPING"

Cryptsetup reads the whole key file up to its compiled-in maximum unless --keyfile-size limits the read. This can remove a trailing newline when the file was made by a script:

sudo cryptsetup luksResume \
  --key-file /root/secure/luks-passphrase \
  --keyfile-size 64 \
  "$MAPPING"

Choose the size for the actual file, not this example. The local 2.7.0 build reports an 8192 kB maximum key file size in cryptsetup --help. If --key-file - is used, input comes from standard input and reading does not stop at newline characters. That makes pipelines easy to get wrong and can expose credentials in process supervision or logs, so prefer a protected file or an interactive prompt.

4. Handle tokens, detached headers and retries

LUKS2 tokens can be selected with --token-id or restricted with --token-type. Without a token selection, cryptsetup checks available tokens that do not need a PIN before asking for a passphrase. Add --token-only when a token failure must not fall back to an interactive passphrase prompt. Test token selection during a maintenance window, because a PIN prompt or token plugin can require hardware that is not present on a recovery console.

If the LUKS metadata is detached, supply the same header device or file used when the mapping was opened:

sudo cryptsetup luksResume \
  --header /root/secure/vault-header.img \
  "$MAPPING"

Do not invent a header path. A detached header is part of the volume's configuration, and using the wrong one will not repair the suspended mapping.

A wrong passphrase, unavailable token, wrong header, or wrong mapping name causes the operation to fail rather than silently recover the device. Check the error, correct one input, and retry. The default is three passphrase attempts; --tries can change that, while --timeout controls how long an interactive prompt waits. The timeout default is zero, meaning wait forever.

Common traps and recovery

If you cannot provide the right credential, leave the mapping suspended while you recover the documented secret or token. If the mapping should be abandoned instead, and you have confirmed that no required process depends on it, remove it with:

sudo cryptsetup close "$MAPPING"

Recovery: that removes the mapping rather than restoring it. Reopening it later requires the backing device, its correct header configuration and a valid key. Treat this as a service-impacting change and check mounts and dependent processes first.

Done means