Check a Mapping's State with cryptsetup status

cryptsetup status tells you whether a device-mapper mapping is active and how it is arranged, without touching it. Allow about five minutes. You need the cryptsetup-bin package and a mapping name, normally whatever is shown under /dev/mapper/. The command reports state; it does not open, close, resize or otherwise change the mapping.

1. Check the installed version

This guide uses cryptsetup 2.7.0, installed from Ubuntu's cryptsetup-bin package. The status action runs through the main cryptsetup program, so check the binary first:

$ cryptsetup --version
cryptsetup 2.7.0 flags: UDEV BLKID KEYRING FIPS KERNEL_CAPI HW_OPAL

Your feature flags and version can differ, which matters when comparing diagnostic output with another machine. The status subcommand takes a mapping name, not a LUKS device path.

2. Find the mapping name

Use an ordinary, unprivileged shell to list device-mapper links:

$ ls -l /dev/mapper/

If the mapping is called vault, its name is vault, not /dev/mapper/vault. You can also ask the kernel's device-mapper view for active names:

$ ls /sys/class/block/dm-*/dm/name 2>/dev/null | while read -r f; do
>   printf '%s: ' "${f%/dm/name}"
>   cat "$f"
> done

The first command is usually easier to read. If both show nothing, there may be no active mapping to inspect. Do not turn an absent mapping into a repair exercise by running an activation command unless that is a separate, deliberate task.

3. Run status against the name

Run the read-only query as the account that owns the storage workflow. Use sudo only when the unprivileged command is rejected:

$ sudo cryptsetup status vault
/dev/mapper/vault is active and is in use.
  type:    LUKS2
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: keyring
  device:  253:2
  sector size:  512
  offset:  32768 sectors
  size:    104857600 sectors
  mode:    read/write

The exact lines depend on the mapping, cryptsetup build and kernel. Read the first line as the headline result. An active mapping has a device-mapper target and can be used through its mapped path. Everything below it, type, cipher, key location, device number, sector size, offset, size and mode, describes how that mapping is arranged. Treat these as observations, not values to copy into an activation command.

$ test -b /dev/mapper/vault && echo "mapped block device exists"
mapped block device exists
$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS /dev/mapper/vault

cryptsetup status does not mount a filesystem and does not prove one is healthy. If the query succeeds but a mount or read fails, investigate the filesystem and its mount configuration separately.

4. Handle an inactive or missing mapping

Replace vault with the actual name. A name that is not currently active normally produces an error rather than a status block, which is useful evidence: it means there is no matching active mapping for that name right now. Check spelling and enumerate the directory again before assuming the encrypted device is damaged:

$ sudo cryptsetup status does-not-exist
Cannot initialize device-mapper, running as non-root user.

On the reference machine, that deliberately invalid test ran without sudo, so the privilege error appeared before the name could even be evaluated. Your system may instead report that the mapping does not exist. Either way, do not infer a LUKS header failure from this command alone. If the mapping should be active, check the service or boot unit that should have opened it, then read the relevant journal entries.

5. Use a detached header only when the mapping was created that way

The status action accepts --header for a detached LUKS header. It identifies where the header is stored; it does not move the header, recreate the mapping or repair metadata:

$ sudo cryptsetup --header /secure/headers/vault.luks status vault

Use the exact header path from the system's existing configuration. Do not guess a header file, and do not create one as part of a status check: a wrong detached-header path can make a valid setup look broken.

6. Treat lock bypass as an exception

For LUKS2, cryptsetup protects on-disk metadata with locks. The manual permits --disable-locks for status, but warns against it unless locking is impossible in a restricted environment where /run cannot be used:

$ sudo cryptsetup --disable-locks status vault

7. Capture diagnostics without mistaking them for status

If the normal command fails and you need evidence for a bug report, add --debug and keep the output. Debug lines begin with a #. The --debug-json variant adds LUKS2 JSON structures, which can expose more metadata than you want in a shared ticket:

$ sudo cryptsetup --debug status vault 2>cryptsetup-status.debug
$ sed -n '1,80p' cryptsetup-status.debug

Review the file before sending it: it can contain host paths, device details and other operational information. Do not paste passphrases or key material into a report. The debug option does not make an inactive mapping active, and it does not replace the normal status result.

Done means

• Version and name confirmed: you checked the installed cryptsetup version and used the correct mapping name.
• State understood: the status output confirms whether the mapping is active and shows its relevant parameters.
• Block device checked separately: without claiming this proves filesystem health.
• Detached header handled correctly: --header used only with a known path.
• Locks respected: --disable-locks avoided unless the runtime genuinely cannot use locking, and debug output treated as sensitive.