Resize an Active LUKS Mapping Safely with cryptsetup resize

You will finish with an active device-mapper mapping whose visible size matches the backing device or an explicitly chosen limit. cryptsetup resize changes the mapping only. It does not enlarge a partition, a logical volume, a virtual disk or any other raw device.

Allow about 15 minutes for the command and checks. You need cryptsetup 2.7.0 from the Ubuntu cryptsetup-bin package, an already active mapping, and a backing device that has genuinely changed size. You also need root privileges for the resize and for most device inspection commands.

1. Confirm what will be resized

Identify the mapped name and its backing device before changing anything. The name is the final component of the mapped path, such as vault in /dev/mapper/vault:

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

Replace EXAMPLE_NAME with the real mapping name. The status command should describe an active device. Check the storage layer that you expanded as well, for example the logical volume, partition or virtual disk. A successful resize cannot repair a backing device that is still the old size.

Checkpoint: write down the exact mapping name and the device that supplies its sectors. If the mapping is not active, stop here. This command is for an existing active mapping, not for opening a LUKS device or creating a new one.

2. Inspect the current mapped size

Read the size in 512-byte sectors from the device-mapper view:

$ sudo blockdev --getsz /dev/mapper/EXAMPLE_NAME
CURRENT_SECTORS

The output is a sector count, not a byte count. The manpage describes --size in 512-byte sectors, so do not paste a value such as 100G into that option. If you prefer units, use --device-size instead.

Now compare the backing device size with the mapped size. Use the real backing path identified in the previous step:

$ sudo blockdev --getsize64 /dev/EXAMPLE_BACKING_DEVICE
BACKING_BYTES

Do not assume the two numbers should match for LUKS. A LUKS mapping excludes the space occupied by its header and metadata. The available data size is therefore normally smaller than the complete backing device.

3. Choose automatic or explicit sizing

For the normal case, let cryptsetup calculate the size from the underlying device:

$ sudo cryptsetup resize EXAMPLE_NAME

With no size option, cryptsetup uses the real underlying device size. For LUKS, it subtracts the area reserved for the LUKS header. For a plain crypt device, it uses the whole underlying device. This is usually the least error-prone choice after the backing storage has been enlarged.

Use --device-size when the backing device is larger than the portion you want exposed. An unsuffixed value is bytes; S means 512-byte sectors; MiB and GiB use powers of 1024, while MB and GB use powers of 1000:

$ sudo cryptsetup resize --device-size 900GiB EXAMPLE_NAME

Use --size when you have already calculated an exact number of 512-byte sectors:

$ sudo cryptsetup resize --size 1887436800 EXAMPLE_NAME

Do not confuse these options. --device-size 1887436800 means 1,887,436,800 bytes, whereas --size 1887436800 means that many 512-byte sectors. The latter represents a much larger mapping.

4. Treat an explicit size as a boundary

Before using either explicit form, check that the requested end lies within the backing device and leaves room for the LUKS data offset. An oversized request can fail, while an undersized request leaves capacity unused. This command does not move data or alter the raw device geometry.

Changing a live mapping can affect applications using it. Schedule the operation according to the storage stack above it, and keep writes under control while you inspect the result. Do not use a guessed size merely because a disk-management tool reports a rounded capacity.

There is no ordinary undo command that restores a previous mapping size by itself. If you selected a smaller boundary, rerun cryptsetup resize with the correct larger size after confirming that the backing device and filesystem can safely use it. Keep the old sector count until verification is complete.

5. Verify the new mapping

Run the same size check after the command:

$ sudo blockdev --getsz /dev/mapper/EXAMPLE_NAME
NEW_SECTORS
$ sudo cryptsetup status EXAMPLE_NAME

NEW_SECTORS should reflect the selected boundary. The status output should still identify the expected active mapping. If the number did not change, check that the backing layer was expanded first and that you used the right mapped name. If the command failed, read its error before retrying with a different size.

The mapping size is only one layer. A filesystem or a volume manager inside it may still need its own expansion command, and those operations have filesystem-specific safety rules. Do not run a filesystem resize solely because the cryptsetup command succeeded. Inspect the next layer first and follow its documentation.

6. Validate command syntax without changing state

When preparing a scripted invocation, cryptsetup 2.7.0 provides --test-args. It validates the command-line arguments and reports that no action was taken:

$ cryptsetup --test-args resize EXAMPLE_NAME
No action taken. Invoked with --test-args option.

This is a syntax check, not proof that the mapping exists, that the device has enough sectors, or that an authentication request would succeed. Run the real command only after the name, backing size and requested boundary have been checked. If a passphrase is needed, cryptsetup may retrieve an available LUKS2 key from the kernel keyring or ask for a passphrase. Keep key files and passphrases out of shell history.

Common traps

• Expecting raw storage to grow: resize changes how many backing sectors the active mapping represents. Expand the partition, logical volume or virtual disk separately first.
• Mixing bytes and sectors: --device-size accepts units and defaults to bytes; --size is always a count of 512-byte sectors.
• Comparing a LUKS mapping with the whole disk: the LUKS header area is not data payload, so the values will not normally be equal.
• Assuming the filesystem grew: cryptsetup exposes capacity to the next layer. It does not enlarge a filesystem.
• Disabling locks to make a failure disappear: --disable-locks is for restricted environments where locking is impossible and is not a general repair option. Avoid it unless that constraint is understood.