Why an External LUKS-Encrypted Drive Doesn't Show Free Space After Deleting Files

When files vanish from a LUKS-encrypted drive but df still shows the volume as full, the space is usually trapped at one of two layers: something is still holding references to the deleted data at the filesystem level, or the freed blocks were never returned to the underlying device because the LUKS layer was opened without discard support. Both are fixable, and the fix involves cleanly remounting the drive and enabling TRIM/discard passthrough on the encrypted container.

Understanding the Two Layers of Your Encrypted Drive

A LUKS drive is actually two stacked devices. The raw disk holds an encrypted container; inside that container is a virtual block device (something like /dev/mapper/yourdrive), and on top of that lives a normal filesystem such as ext4. When you delete a file, the filesystem marks its blocks as free. However, unless the filesystem is told to explicitly notify lower layers about freed blocks, the underlying encrypted device has no idea those sectors are now unused.

Normally you never notice this on an internal SSD because the kernel handles discard automatically. But with external drives opened through LUKS, discard support is often disabled by default, and certain space-reclamation steps have to be done manually. Meanwhile, if the filesystem itself has not yet released the blocks, df will not budge either.

Rule Out the Usual Suspects First

Before touching the encryption layer, confirm that the filesystem itself really has not freed the blocks:

• Hidden trash directories. Desktop environments do not always put deleted files in a visible .Trash folder on the drive root. Look for a directory named .Trash-1000 (the number is your UID) in the mount point, and also check the trash in your home directory if the files were deleted via a file manager.
• Open file handles. You already ran lsof +L1, which is the right check — it lists unlinked files still held open by a process. A backup agent, media indexer, or sync client can silently pin deleted data.
• df vs du mismatch. Compare df -h /mountpoint with du -sh /mountpoint. If du shows far less data than df reports, the blocks are held by something invisible to ordinary directory listings — open handles, reserved blocks, or pending journal activity.
• Wrong device. Make sure you are reading df for the mounted filesystem, not the raw partition or the mapper device, which report sizes differently.

Fix Step 1: Cleanly Unmount and Remount

The fastest way to release any lingering references is a full unmount/remount cycle. Close your applications, unmount the filesystem, and unmap the LUKS container:

sudo umount /media/youruser/drive
sudo cryptsetup close yourdrive

Then reopen it — this time with discard support enabled — and mount it again:

sudo cryptsetup open --allow-discards /dev/sdXN yourdrive
sudo mount /dev/mapper/yourdrive /media/youruser/drive

The --allow-discards flag is the key addition. It permits discard/TRIM commands issued by the filesystem to pass through the encryption layer down to the physical device.

After remounting, run df -h again. If the space now appears, something was holding the blocks and the remount resolved it. If it still shows full, proceed to the trim step.

Fix Step 2: Force a Manual Trim

With the drive mounted and discards allowed, explicitly tell the filesystem to report its free blocks downward:

sudo fstrim -v /media/youruser/drive

The -v flag prints how many bytes were trimmed, which is a useful confirmation. Once the freed sectors have been discarded through the LUKS layer, df and other tools should reflect the newly available space.

If fstrim reports an error about discard support, verify that your device is opened with --allow-discards and that the filesystem itself supports trim (ext4, for example, does; it just needs the kernel to allow the pass-through).

Making Discards Permanent

Opening the drive manually with --allow-discards only lasts for that session. To avoid repeating this every time, either add the option to /etc/crypttab if the drive is mounted by the system:

yourdrive UUID=your-luks-uuid none luks,discard

Or, for removable drives unlocked through the desktop, configure the discard option in your disk-mounting tool of choice so the flag is applied automatically on unlock. Note that on some older flash-based drives, frequent trims through encryption can slightly affect performance; for a spinning external hard disk, discard has essentially no downside and simply keeps the mapping clean.

Prevention and Habits

• Always eject the drive properly rather than yanking it, so handles are closed and the filesystem gets a chance to finalize deletions.
• Run fstrim -av periodically if you use several encrypted volumes; it trims every mounted filesystem that supports it.
• Check the trash directory with a hidden-file view enabled whenever deletions appear to "not count."
• Remember that on encrypted media, space accounting happens in two places — the filesystem and the container — and troubleshooting means checking both.

Frequently Asked Questions

Is my data lost if df shows the volume as full after deletion?

No. The files' blocks have either been marked free internally but not yet reported downward, or are still referenced by a running process. Once the references are released and a trim is performed, the space becomes available again.

Why does deleting files inside a LUKS container behave differently from a normal drive?

The filesystem's free-block bookkeeping is invisible to the encrypted layer unless discard commands are passed through. Without allow-discards, the container never learns which sectors are no longer in use, and space accounting tools can appear out of sync.

Does --allow-discards weaken encryption?

It can leak coarse metadata — namely, which sectors have been trimmed and are therefore known to be unused. That is generally considered an acceptable trade-off for removable media, but on high-security setups some administrators deliberately leave it off and rely on manual fstrim runs instead.

Can I run fstrim while the drive is in use?

Yes, fstrim is designed to run on mounted filesystems. Just avoid running it while a write-heavy operation is in progress, and make sure the mount point is the filesystem, not the raw mapper device.

How do I find the trash folder on an external drive?

Enable hidden files in your file manager and look for .Trash-<UID> at the root of the mount point — for example .Trash-1000. Deleted files moved to trash via the desktop live there, not in a folder named simply .Trash.