How to Resize a LUKS Partition (Extend or Shrink) in Linux

You encrypted a data partition with LUKS and now the volume is too small—or you reclaimed space and need to shrink it. LUKS does not bake the partition size into the header, so resizing is possible when you follow the right order:

• Extend (outside → inside): partition/disk → LUKS mapper → filesystem
• Shrink (inside → outside): filesystem → LUKS mapper → partition

This walkthrough uses LUKS2 with ext4:

• Inspect a real secondary disk (/dev/sdc1, mapper secure_data) to read the stack
• Run extend and shrink on a loop-file lab where growing and shrinking are safe to repeat

Related guides:

• Encrypt a disk partition with LUKS — create a new volume
• Mount LUKS with crypttab — unlock at boot
• Open LUKS on another Linux machine — rescue or migration host

Tested on: Ubuntu 26.04 LTS (Resolute Raccoon); kernel 7.0.0-27-generic; cryptsetup 2.8.4.

Quick reference: extend vs shrink order

LUKS sits between the partition and the filesystem. Wrong order causes:

• Filesystem larger than the encrypted area (extend mistakes)
• Truncated data (shrink mistakes)

What you need

• Root or sudo on the host
• cryptsetup, e2fsprogs, and parted (or growpart from cloud-guest-utils on Ubuntu)
• A current data backup and a LUKS header backup before any shrink
• The LUKS volume unmounted for shrink; extend can grow ext4 online only after the mapper and LUKS payload are already larger
• Free unallocated space after the partition when you extend a physical disk (or a larger loop/image file in a lab)

On Fedora and other distributions:

• Install the same packages locally
• The cryptsetup resize workflow is not Ubuntu-specific

Inspect the LUKS stack before you resize

Before you resize, confirm:

• Which block device is the LUKS container
• Which mapper name is open
• The size: field in 512-byte sectors

On the lab host, /dev/sdc1 holds the cluster demo volume secure_data. Open it and print the block layout:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT /dev/sdc
sudo cryptsetup open /dev/sdc1 secure_data

Then read the LUKS payload size in 512-byte sectors:

sudo cryptsetup status secure_data

Sample output:

NAME                  SIZE TYPE  FSTYPE      MOUNTPOINT
sdc                     5G disk
└─sdc1                  5G part  crypto_LUKS
  └─secure_data         5G crypt ext4

/dev/mapper/secure_data is active.
  type:       LUKS2
  cipher:     aes-xts-plain64
  keysize:    512 bits
  device:     /dev/sdc1
  sector size: 512
  offset:     32768 sectors
  size:       10448896 sectors
  mode:       read/write

From cryptsetup status:

• device: — LUKS container (/dev/sdc1)
• offset: — payload offset inside the LUKS container, shown in sectors/512-byte units in cryptsetup status; add this to the partition start when calculating the absolute disk end sector
• size: — encrypted payload in 512-byte sectors (use with cryptsetup resize --size when shrinking)
• For parted resizepart, the end sector is absolute on the disk: partition_start + offset + size - 1

Close the mapper when you finish inspecting: sudo cryptsetup close secure_data.

If LUKS sits on an LVM logical volume inside the mapper, see LVM on LUKS — the order includes pvresize, not just lvextend / lvreduce.

Extend a LUKS partition

Extending needs free space after the partition on the same disk (or a larger backing image).

• Loop lab: 2 GiB image → 3 GiB (safe to repeat)
• Physical disk: sudo growpart /dev/sdc 1 when unallocated space follows sdc1

Step 1: Grow the partition or backing image

For a loop-file lab, grow the file, refresh the kernel’s view of the loop size, fix the GPT if needed, then grow partition 1:

IMG=/var/tmp/luks-resize-lab.img
LOOP=/dev/loop24

truncate -s 3G "$IMG"
sudo losetup -c "$LOOP"
sudo sgdisk -e "$LOOP"
sudo partprobe "$LOOP"
sudo parted -s "$LOOP" resizepart 1 100%

Loop-file gotchas after truncate:

• losetup -c — refresh kernel loop size (without it, cryptsetup resize has nothing to grow into)
• sgdisk -e — move backup GPT to the end of a grown image file
• partprobe — pick up the resized partition table

On a real disk with space after partition 1:

sudo growpart /dev/sdc 1

Check that the partition picked up the new space:

lsblk -o NAME,SIZE,TYPE,FSTYPE "$LOOP"

Sample output:

NAME            SIZE TYPE  FSTYPE
loop24            3G loop
└─loop24p1        3G part  crypto_LUKS
  └─resize_demo   2G crypt ext4

loop24p1 is 3 G but the mapper is still 2 G—the next step grows the LUKS payload.

Step 2: Resize the LUKS mapper

With the mapper already open (resize_demo in the lab), grow the LUKS encrypted area to fill the partition. Omit --size so cryptsetup uses the maximum allowed by the backing device:

sudo cryptsetup resize resize_demo

A successful grow prints nothing. Confirm the new sector count:

sudo cryptsetup status resize_demo | grep -E 'size:|offset:'

Sample output:

offset:  32768 [512-byte units] (16777216 [bytes])
  size:    6256607 [512-byte units] (3203382784 [bytes])

6256607 sectors × 512 bytes ≈ 2.98 GiB — the LUKS payload now matches the grown 3 G partition (minus header offset).

Step 3: Grow ext4 on the mapper

With the mapper still open, grow the filesystem. ext4 can expand online while mounted:

sudo resize2fs /dev/mapper/resize_demo

Sample output:

resize2fs 1.47.2 (1-Jan-2025)
Filesystem at /dev/mapper/resize_demo is mounted on /mnt/resize-demo; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/mapper/resize_demo is now 782075 (4k) blocks long.

Check usable space at the mount point:

df -h /mnt/resize-demo

Sample output:

Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/resize_demo  2.9G  532K  2.8G   1% /mnt/resize-demo

Extend order in one line: partition → cryptsetup resize → resize2fs. For related flags and operations, see the cryptsetup command cheatsheet.

Shrink a LUKS partition

Shrinking is offline work:

1. umount
2. Shrink filesystem (resize2fs)
3. Shrink LUKS payload (cryptsetup resize --size)
4. Shrink partition (parted resizepart)

Target sizes:

• Loop lab: 1800 M on the ~2.9 G filesystem after the extend demo
• 5 G secure_data: pick a target smaller than the current filesystem size, but larger than the data currently used, with a safety margin

Step 1: Unmount and run a full fsck

Take the filesystem offline, then force a full check before shrinking. On production disks, answer repair prompts yourself:

sudo umount /mnt/resize-demo
sudo e2fsck -f /dev/mapper/resize_demo

In a disposable lab (or a script where you accept automatic repairs), add -y:

sudo e2fsck -fy /dev/mapper/resize_demo

Sample output:

e2fsck 1.47.2 (1-Jan-2025)
Pass 1: Checking inodes, blocks, and sizes
...
/dev/mapper/resize_demo: 13/195072 files (0.0% non-contiguous), 22095/782075 blocks

Do not use -y on real data unless you are sure every automatic repair is acceptable.

Step 2: Shrink ext4 to the target size

Shrink the filesystem offline to 1800 M (smaller than the current ~2.9 G lab size):

sudo resize2fs /dev/mapper/resize_demo 1800M

Sample output:

resize2fs 1.47.2 (1-Jan-2025)
Resizing the filesystem on /dev/mapper/resize_demo to 460800 (4k) blocks.
The filesystem on /dev/mapper/resize_demo is now 460800 (4k) blocks long.

If the filesystem is still mounted, ext4 stops you. Remount and try shrinking again to see the error:

sudo mount /dev/mapper/resize_demo /mnt/resize-demo
sudo resize2fs /dev/mapper/resize_demo 1500M

Sample output:

resize2fs 1.47.2 (1-Jan-2025)
resize2fs: On-line shrinking not supported
Filesystem at /dev/mapper/resize_demo is mounted on /mnt/resize-demo; on-line resizing required

Unmount first, then rerun resize2fs.

Step 3: Shrink the LUKS mapper with --size in sectors

Pass a sector count slightly larger than the shrunk filesystem:

• Lab value: 3775000 sectors (512-byte units)
• Read cryptsetup status after resize2fs if you are unsure

Unmount (if needed), then shrink the LUKS payload:

sudo umount /mnt/resize-demo
sudo cryptsetup resize resize_demo --size 3775000

Suffixes like 512M are not valid for --size. This fails immediately:

sudo cryptsetup resize resize_demo --size 512M

Sample output:

cryptsetup: invalid numeric value

Always use a plain integer sector count with --size. Verify the LUKS payload shrank:

sudo cryptsetup status resize_demo | grep 'size:'

Sample output:

size:    3775000 [512-byte units] (1932800000 [bytes])

Step 4: Shrink the partition

parted resizepart expects an absolute end sector on the disk—not a value relative to the partition start. Read the partition start sector first:

sudo parted /dev/loop24 unit s print

Sample output:

Number  Start   End       Size      File system  Name
 1      2048s   6291422s  6289375s               primary

Calculate the new absolute end sector:

new_partition_end = partition_start + LUKS_offset + LUKS_size - 1

For this lab (partition_start 2048, LUKS_offset 32768, LUKS_size 3775000):

2048 + 32768 + 3775000 - 1 = 3809815

Shrink partition 1 to that absolute sector:

sudo parted /dev/loop24 unit s resizepart 1 3809815s

parted asks Yes/No? when shrinking — answer Yes. Then verify the partition is still large enough for the LUKS header and payload:

lsblk -o NAME,SIZE,TYPE,FSTYPE /dev/loop24
sudo cryptsetup status resize_demo | grep -E 'size:|offset:'

Check:

• partition_length (in sectors) ≥ LUKS_offset + LUKS_size
• Equivalently, the partition end sector you passed is ≥ partition_start + LUKS_offset + LUKS_size - 1

LVM on LUKS extend and shrink order

Stack: partition → LUKS → LVM → filesystem

The LUKS mapper is the LVM physical volume. You must resize the PV with pvresize whenever the mapper size changes.

LVM cautions:

• Shrink the filesystem before lvreduce — reducing the LV first can destroy data
• If pvresize --setphysicalvolumesize refuses because extents sit near the end of the PV, move or remove those extents first; do not force the LUKS or partition layer smaller until LVM reports the PV fits the target size
• On another host, open and unlock LUKS before resizing LVM or the filesystem

Order-of-operations pitfalls

btrfs and XFS notes

This guide focuses on ext4 (offline shrink is supported). Other filesystems:

Non-ext4 notes:

• XFS on LUKS — no in-place shrink; migrate data, recreate smaller LUKS, restore
• btrfs on LUKS — shrink btrfs first, then cryptsetup resize --size, then the partition

Troubleshooting

References

• pvresize(8) man page
• cryptsetup FAQ — resizing (official)
• cryptsetup(8) man page
• resize2fs(8) man page

Summary

• Extend (plain partition): grow partition/image → cryptsetup resize → resize2fs /dev/mapper/name
• Shrink (plain partition): umount → e2fsck -f → resize2fs TARGET → cryptsetup resize --size SECTORS → parted resizepart with absolute end partition_start + LUKS_offset + LUKS_size - 1
• LVM inside LUKS: add pvresize on extend and lvreduce + pvresize --setphysicalvolumesize before shrinking LUKS
• Back up data and the LUKS header before any shrink; wrong ordering causes permanent loss