Safely Remove a dm-crypt Mapping with cryptsetup close

You will remove an existing cryptsetup mapping, confirm that it has gone, and know when deferred removal is safer than an immediate close. The examples match cryptsetup 2.7.0 from cryptsetup-bin version 2:2.7.0-1ubuntu4.2 on this machine.

Allow about ten minutes. You need a shell and sudo access to the host that owns the mapping. Closing a mapping is service-disrupting: processes using its device can fail, and the mapped device will no longer be available. This command does not erase the encrypted data or remove a LUKS header, but it does remove the active mapping and wipes its associated key from kernel memory.

1. Confirm the command and identify the mapping

First check the installed version. This is read-only and does not need elevated privileges:

$ cryptsetup --version
cryptsetup 2.7.0

The argument to close is the mapping name, not the backing disk and not normally the path to a device. If a volume was opened as vault, the mapped device is usually /dev/mapper/vault, and the close command is:

$ sudo cryptsetup status vault
/dev/mapper/vault is active and is in use.

Your status output will contain host-specific details. If you do not know the name, list mapper entries and inspect candidates:

$ ls -l /dev/mapper
$ sudo cryptsetup status MAPPING_NAME

Replace MAPPING_NAME with the exact name. Do not guess based on a mount-point name. Check the mounted filesystems and services using it before continuing:

$ findmnt /dev/mapper/MAPPING_NAME
$ sudo fuser -vm /dev/mapper/MAPPING_NAME

Checkpoint: stop here if the mapping is mounted, has open users, or belongs to a service that you have not put into a safe maintenance state. Closing it underneath active users can produce I/O errors or interrupt a running service.

2. Test the arguments without changing state

Cryptsetup 2.7.0 provides --test-args, which validates the command line and performs no action. It is useful for checking a copied command before the real, privileged operation:

$ cryptsetup close --test-args MAPPING_NAME
No action taken. Invoked with --test-args option.
$ printf 'exit status: %s\n' "$?"
exit status: 0

The placeholder is deliberately not a real mapping name. Substitute the name you confirmed in step 1. A successful test only says that the arguments are acceptable. It does not prove that the mapping exists or that it is safe to remove.

3. Close the mapping immediately

Unmount the filesystem and stop its consumers first. Those actions depend on your system and may require elevated privileges. Once the checkpoint is clear, close the mapping:

$ sudo cryptsetup close MAPPING_NAME

The command normally produces no output on success. The removal is the state-changing and service-disrupting step, so do not add --batch-mode casually. The manpage describes -q and --batch-mode as suppressing confirmation questions, with the warning to use them with care.

Verify both the command status and the device state:

$ printf 'close exit status: %s\n' "$?"
close exit status: 0
$ sudo cryptsetup status MAPPING_NAME
Device MAPPING_NAME is not active.

The exact inactive message can vary with the installed build. A non-zero status from cryptsetup status, together with the absence of /dev/mapper/MAPPING_NAME, is the useful check. Avoid checking only the path: device nodes and udev events can be briefly out of step.

4. Use deferred removal when users may still be attached

Immediate removal is not always the right timing. With --deferred, cryptsetup asks the device-mapper layer to remove the mapping after the last user closes it:

$ sudo cryptsetup close --deferred MAPPING_NAME

This is still a change to live storage. It does not make new I/O safe, and it does not forcibly detach processes. Stop services and unmount normally as soon as practical. Check the mapping status and consumers again:

$ sudo cryptsetup status MAPPING_NAME
$ sudo fuser -vm /dev/mapper/MAPPING_NAME

The mapping may remain present while an open reference exists. That is the expected point of deferred removal. Once the last reference closes, verify that the mapper entry has disappeared.

If you configured deferred removal but need to keep the mapping active, cancel it with:

$ sudo cryptsetup close --cancel-deferred MAPPING_NAME

Use this only while the mapping is still present and the deferred removal is pending. Then confirm with cryptsetup status. If it has already disappeared, there is no active mapping to restore: reopen the volume using the original device, header and key material instead.

5. Keep close separate from erase

cryptsetup close removes an active mapping. It does not wipe the encrypted sectors, remove keyslots, or destroy the LUKS header. The manpage also says that the associated key is wiped from kernel memory, which is why closing an unused mapping is a sensible end to a maintenance session.

Do not substitute luksErase, luksKillSlot, or a disk-wiping command when the requirement is merely to stop using a mapped device. Those operations affect persistent encryption metadata or data and are not an undoable form of close. If you closed the wrong mapping, the recovery action is to reopen the correct volume with its original backing device and required key or token, after confirming that doing so is safe.

6. Diagnose a failed close

If close fails, do not repeat it with --disable-locks as a first response. That option disables metadata lock protection, is valid only for LUKS2, and the installed manpage warns against using it unless locking is impossible in a restricted environment where /run cannot be used. It does not solve busy filesystems or unknown consumers.

Start with read-only checks:

$ sudo cryptsetup status MAPPING_NAME
$ findmnt /dev/mapper/MAPPING_NAME
$ sudo fuser -vm /dev/mapper/MAPPING_NAME
$ lsblk -f

Look for a mounted filesystem, a process with the device open, a nested mount, or a service that has not stopped. If you need more diagnostics, rerun the failed operation in a controlled maintenance window with --debug. Debug lines are prefixed with #; treat the output as potentially sensitive because it describes storage and cryptsetup state.