Resize a Live LUKS Mapping with cryptsetup resize

cryptsetup resize changes how many sectors an active mapping exposes, and it will not grow the partition underneath it for you. You will finish with a mapping whose visible size matches the backing device or an explicitly chosen limit. 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. Root privileges are needed for the resize and for most 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 you expanded too, whether that is a logical volume, partition or virtual disk: a successful resize cannot repair a backing device that is still the old size.

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

That 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; use --device-size instead if you prefer units.

Now compare the backing device size with the mapped size, using the real backing path from the previous step:

$ sudo blockdev --getsize64 /dev/EXAMPLE_BACKING_DEVICE
BACKING_BYTES

Do not expect the two numbers to match for LUKS. A LUKS mapping excludes the space its header and metadata occupy, so the available data size is normally smaller than the full 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, subtracting the LUKS header area for LUKS or using the whole device for plain crypt. This is usually the least error-prone choice once 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

4. Treat an explicit size as a boundary

Before using either explicit form, check the requested end lies within the backing device and leaves room for the LUKS data offset. An oversized request can fail; an undersized one 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 against the storage stack above it, and keep writes under control while you inspect the result. Do not use a guessed size because a disk-management tool reports a rounded capacity.

There is no ordinary undo for a mapping size change. If you selected a smaller boundary, rerun cryptsetup resize with the correct larger size once you have confirmed 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, and the status output should still show the expected active mapping. If the number did not change, check the backing layer was actually expanded and that you used the right mapped name. Read the error before retrying with a different size if the command failed.

The mapping size is only one layer. A filesystem or volume manager inside it may still need its own expansion command, with its own 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 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.

That is a syntax check, nothing more. It does not prove 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. 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 match.
• 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, not a general repair option.

Done means

• Mapping confirmed: the mapping name and backing device were checked before the change.
• Boundary calculated: the backing storage was expanded, or an explicit safe boundary was worked out.
• Sizing method correct: automatic sizing, a correctly unit-labelled --device-size, or a verified 512-byte sector count with --size.
• Mapping verified: blockdev --getsz and cryptsetup status confirm the expected active mapping.
• Next layer checked: a filesystem or similar has been checked separately before any further resize.