Check a cryptsetup Mapping Without Changing It

You will inspect an existing device-mapper mapping with cryptsetup status, confirm whether it is active, and recognise the fields that matter before troubleshooting storage or encryption. Allow about five minutes. You need the cryptsetup-bin package and a mapping name, normally the name shown below /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 on the reference system. The status action is invoked through the main cryptsetup program, so check the binary you are about to run:

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

Your feature flags and version can differ. That matters when comparing diagnostic output with another machine. The status subcommand itself 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 commands show nothing, there may be no active device-mapper 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 status query as the account that owns the storage workflow. On many systems, access to device-mapper information requires elevated privileges, so 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 main result. An active mapping has a device-mapper target and can be used through its mapped path. The type, cipher, key location, device number, sector size, offset, size and mode describe how that active mapping is arranged. Treat these details as observations, not as values to copy into an activation command.

Checkpoint: confirm the result

After a successful query, check that the mapped block device exists and record its kernel-visible type:

$ 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 that the filesystem is healthy. If the status 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. The error is useful evidence: it means there is no matching active mapping for that name at the time of the query. Check spelling and enumerate the directory again before assuming that the encrypted device is damaged.

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

On the reference machine, the deliberately invalid test was run without sudo, so the privilege error appeared before the name could 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 is meant to be active, check the service or boot unit that should have opened it, then inspect 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 the device or file 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. If the mapping is already active, the device-mapper mapping remains the thing being inspected; the header option supplies the metadata location cryptsetup needs for this query.

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. Do not add it merely because a command is inconvenient:

$ sudo cryptsetup --disable-locks status vault

The option is ignored for formats other than LUKS2. It is also security-sensitive because it removes protection intended to coordinate metadata access. Prefer fixing the restricted runtime or its /run setup. If you must use the option for a controlled diagnostic, record that fact beside the result and avoid running concurrent cryptsetup operations against the same metadata.

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 #. 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.