Remove a dm-crypt Mapping with cryptsetup close

The job is done and you want the encrypted volume shut, but yanking it from under a running service ends in I/O errors. cryptsetup close removes an existing mapping, and you will confirm 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.

• Time: about ten minutes.
• You need: a shell and sudo access to the host that owns the mapping.
• What it does: removes the active mapping and wipes its key from kernel memory.
• What it leaves alone: it does not erase the encrypted data or remove a LUKS header.

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 a device path. If a volume was opened as vault, the mapped device is usually /dev/mapper/vault. Check that it is active before you close it:

$ 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 from 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

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 handy 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, so substitute the name you confirmed in step 1. A successful test only says the arguments are acceptable. It does not prove 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 need elevated privileges. Once the checkpoint is clear, close the mapping:

$ sudo cryptsetup close MAPPING_NAME

The command normally prints nothing on success. Removal is the state-changing, service-disrupting step.

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 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 check that counts. Do not check only the path, because 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. Then check the mapping status and consumers again:

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

The mapping may stay present while an open reference exists. That is the 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:

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

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 the associated key is wiped from kernel memory, which is why closing an unused mapping is a sensible end to a maintenance session.

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 and is valid only for LUKS2. The installed manpage warns against it unless locking is impossible in a restricted environment where /run cannot be used. It does not fix 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.