How to Securely Delete Files on Linux (So They Stay Gone)

You deleted the file. But is it really gone?

On Linux, pressing Delete or running rm does not erase your data. It just removes the pointer to it. The actual bytes stay on your disk, sometimes for days, sometimes forever, until something else overwrites them.

That matters if you are trying to remove a sensitive photo, a private document, a password file, or anything you never want anyone to recover.

In this detailed guide, we'll explain how file deletion works on Linux and why "deleted" doesn't always mean "gone." You'll then learn the different ways to securely delete files from both hard disk drives (HDDs) and solid state drives (SSDs) in Linux.

Quick Summary

• To remove files permanently on an HDD with ext4 or xfs, use shred -uzn 3 /path/to/file or the secure-delete toolkit (srm, sfill, sswap, smem) for a more thorough cleanup.
• Delete files permanently on an SSD (any file system): Use rm to delete, then run sudo fstrim -av to tell the drive to erase the freed blocks.
• On btrfs: Use rm, then delete any Snapper or Timeshift snapshots that captured the file, then run sudo fstrim -av.
• For everything: Clear thumbnail caches, check cloud sync, and wipe swap if your system used it while the file was open.
• For the strongest protection: Set up full-disk encryption with LUKS before you ever store sensitive data.

Not sure which applies to you? Run lsblk -f to see your file system and cat /sys/block/sda/queue/rotational to check your disk drive type (0 = SSD, 1 = HDD). The full guide below explains each method step by step.

1. Why "Deleting" a File Is Not Enough

Most people assume that once they delete a file, it vanishes. On Linux, that is simply not true, at least not immediately.

Think of your hard drive like a library. When you "delete" a book, the library just removes its entry from the catalog. The book is still on the shelf. Anyone who knows where to look can still read it.

Tools like rm, the Trash bin in GNOME or KDE, and even unlink() in code - they all do the same thing. They remove the directory entry that points to the file's inode, but leave the raw data sitting on disk until the OS decides to write something else there.

For casual files, that is fine. For sensitive data, it is a serious problem.

2. What Actually Happens When You Delete a File

Here is what Linux does step by step when you run rm:

1. It removes the directory entry that links the filename to its inode.
2. It decrements the inode's link count by one.
3. If the link count reaches zero and no process has the file open, the inode is marked free.
4. The data blocks the file occupied are returned to the free pool, but not wiped.

So the data sits there, intact, waiting to be overwritten. On a lightly used system, that wait can be very long.

A basic recovery tool like testdisk or photorec can pull that data back in minutes.

3. Know Your Setup Before You Start

The right deletion method depends on two things: your file system and your storage type. The wrong method can give you false confidence that the data is gone when it is not. So before you run any commands, take a moment to understand how your hardware actually stores data.

Traditional Hard Drives (HDDs)

Mechanical hard drives write data to spinning magnetic platters. When you delete a file normally, Linux just removes the directory entry pointing to that file's data, like tearing the label off a box without emptying it.

The actual data sits on the platter until something new overwrites it. That means secure deletion on an HDD is straightforward: you overwrite the data with random garbage, and it is gone.

Modern Solid State Drives (SSDs)

SSDs use flash memory chips instead of spinning platters. Because of the way SSD controllers spread writes across cells to manage wear and tear - a process called wear leveling - you cannot reliably target and overwrite one specific file.

The controller decides where data physically lands, and you have no say in that from the OS level.

Standard file shredding tools do not work on SSDs, and running them repeatedly can even shorten your drive's lifespan by burning through unnecessary write cycles.

Instead, the right approach is a hardware-level command called TRIM, which signals the SSD to erase blocks that the OS has marked as free.

That distinction drives every method in this guide. Now let us find out exactly what you are working with.

First, find your file system type:

df -T /home
# or
lsblk -f

Then, check your disk drive type:

cat /sys/block/sda/queue/rotational

Replace "sda" with your actual device (nvme0n1, sdb, etc.).

If the above command returns 0, it is SSD. If the output is 1, then it is HDD.

Here is a quick decision table:

Enough said. Now, let's look at the methods you can use to securely delete files on Linux and make them practically unrecoverable.

4. Method 1: HDDs with ext4 - Use shred or secure-delete

If you have a spinning hard drive with ext4 or xfs, you have two solid options: the built-in shred command, or the more feature-rich secure-delete toolkit. Both overwrite your file's data blocks multiple times before deleting them, which makes recovery extremely difficult.

Important Note: These tools only work reliably on file systems that write data in place. On copy-on-write file systems like btrfs, both shred and secure-delete are ineffective. Jump to Method 3 if you use btrfs. And on SSDs, skip to Method 2, neither tool works as expected there.

Option A: shred (Built-in, No Installation Needed)

shred ships with every Linux distro as part of GNU coreutils. You do not need to install anything.

Delete a single file:

shred -uzn 3 /path/to/file

Here is what each flag does:

• -u : Remove the file after overwriting (like rm)
• -z : Add a final pass of zeros to hide the shredding
• -n 3 : Overwrite 3 times (3 is the default; you can drop this to -n 1 since a single pass is enough for most modern HDDs)

Heads up for ext4 users: If your ext4 partition is mounted in data=journal mode, shred is less effective because the journal records file data writes. Most systems use the default data=ordered mode, where shred works fine. To check your mount mode, run findmnt -o TARGET,OPTIONS / and look for a data= value in the options column.

Delete an entire directory:

find /path/to/folder -type f -exec shred -uzn 3 {} \;
rmdir /path/to/folder

Related Read:

• How To Find And Delete Files Older Than X Days In Linux

Option B: secure-delete Toolkit (More Thorough, Covers Free Space and Swap)

secure-delete is a dedicated package that gives you four separate tools: one for files, one for free disk space, one for swap, and one for RAM. Together, they cover every surface where your data might linger.

Install secure-delete first:

# Debian, Ubuntu, Linux Mint, Pop!_OS
sudo apt install secure-delete

# Fedora
sudo dnf install secure-delete

srm - Securely Remove Files and Folders

srm works like rm but overwrites the data before deleting it.

Usage:

# Delete a single file
sudo srm /path/to/file

# Delete a folder and everything inside it
sudo srm -r /path/to/folder

Useful flags:

• -r : Recursive (for directories)
• -v : Verbose (shows progress)
• -z : Final pass with zeros instead of random data
• -l : Faster but less secure mode (use only if speed matters more than thoroughness)

sfill - Wipe the Free Space on Your Drive

This is a step that shred simply cannot do. After you delete files normally, their data blocks sit in the free space pool waiting to be overwritten. sfill fills all of that free space with random data, wiping any traces of previously deleted files.

Usage:

# Wipe free space on the partition that holds /home
sudo sfill /home

# Or target any mount point
sudo sfill /

Note: sfill can take a long time on large drives. Run it overnight if you need to wipe a big partition. Avoid running it on a partition that is actively in heavy use, as it will impact system performance.

sswap - Securely Wipe Your Swap Partition

If Linux swapped parts of a sensitive file to disk while your system was under memory pressure, that data stays in the swap partition even after you delete the file. sswap wipes it out properly.

First, find your swap partition:

cat /proc/swaps

Sample output of the above command in my system is:

Filename Type Size Used Priority
/dev/sda3 partition 2097148 25144 -1

As you see above, my swap partition is /dev/sda3.

Then disable swap, wipe it, and re-enable it:

sudo swapoff /dev/sda3        # replace with your swap partition
sudo sswap /dev/sda3
sudo swapon /dev/sda3

smem - Clear Sensitive Data from RAM

smem overwrites the unused portions of RAM that could hold fragments of recently opened files or decrypted data.

By default, it runs 38 passes, so it can take several minutes on systems with a lot of RAM and will temporarily reduce system performance while it runs. Run it when your system is otherwise idle.

sudo smem

After using either option, also empty your Trash:

rm -rf ~/.local/share/Trash/files/*
rm -rf ~/.local/share/Trash/info/*

5. Method 2: SSDs - Why shred Fails and What to Do Instead

On a solid state drive, shred does not work as advertised. Because, SSDs use a technique called wear leveling. The SSD controller deliberately spreads writes across many cells to extend the drive's lifespan.

When shred tries to overwrite a block, the controller often writes the "overwrite" to a completely different physical cell, leaving the original data untouched.

So instead of shredding, you can securely and permanently delete files from SSDs like this:

Step 1: Delete the file and empty Trash:

rm /path/to/file
rm -rf ~/.local/share/Trash/files/*
rm -rf ~/.local/share/Trash/info/*

Step 2: Make sure no process still holds the file open:

sudo lsof | grep deleted

If any process shows up, note its PID and close the application. Then run:

sudo kill <PID>

Step 3: Run TRIM to tell the SSD to wipe the freed blocks:

sudo fstrim -av

For those wondering, TRIM is a command that tells the SSD: "These blocks are free now, you can erase them."

Most modern SSDs run TRIM automatically on a weekly schedule via fstrim.timer, but running it manually ensures it happens right away.

Step 4: Verify TRIM is enabled on your system:

sudo systemctl status fstrim.timer

If it is inactive, enable it:

sudo systemctl enable --now fstrim.timer

6. Method 3: BTRFS (Copy-on-Write) - The Trickiest Case

BTRFS is a modern, feature-rich file system that many Arch Linux and Fedora users prefer. However, it uses copy-on-write (CoW), which makes secure deletion more complex than on ext4.

Here is the core problem: btrfs never overwrites data in place. Every time you modify a file, btrfs writes the new version to a fresh location and marks the old blocks as free, but does not wipe them.

When shred tries to overwrite a file, CoW kicks in again and writes shred's passes to yet more new locations, leaving the original data blocks completely untouched in the free pool.

That is why shred is ineffective on btrfs. It never touches the original data, no matter how many passes you run.

If you use btrfs, follow these steps instead:

Step 1: Delete the file and Trash:

rm /path/to/file
rm -rf ~/.local/share/Trash/files/*
rm -rf ~/.local/share/Trash/info/*

Step 2: Check and delete snapshots (this is the critical step most people miss):

If you use Snapper or Timeshift, your file may still exist inside an old snapshot. These snapshots are independent copies of your subvolume at a point in time.

# List all snapshots (Snapper)
sudo snapper list

# Delete a specific snapshot
sudo snapper delete <snapshot-number>

# Or list btrfs subvolumes manually
sudo btrfs subvolume list /

# Delete a specific subvolume snapshot
sudo btrfs subvolume delete /.snapshots/<number>/snapshot

Delete every snapshot that was taken after the file was created. Any snapshot from before the file existed is safe to keep.

Step 3: Confirm no process holds the file:

sudo lsof | grep deleted

Step 4: Run TRIM:

sudo fstrim -av

7. Don't Forget to Clear Snapshots, Thumbnails, and the Cloud

Even after you wipe the file from your main storage, copies can hide in unexpected places. Here are the most common ones to check.

Thumbnail Caches

Your file manager or image viewer probably generated a small thumbnail of the file and saved it separately. Delete those caches:

# GNOME / most desktops
rm -rf ~/.cache/thumbnails/

# Shotwell
rm -rf ~/.cache/shotwell/

# gThumb
rm -rf ~/.cache/gthumb/

Cloud Sync Services

If you use Nextcloud, Syncthing, rclone, or any other sync tool, the file may have already uploaded. Log into those services directly and delete the file there too. Check their trash or version history as well.

Application Caches

Some apps like GIMP, Darktable, and Shotwell keep their own copy or edit history of images. Check each app's cache folder under ~/.cache/<appname>/ and ~/.local/share/<appname>/.

Swap Space

If your system was under memory pressure when you had the file open, Linux may have swapped parts of it to disk. The quickest way to clear it is:

# Check you have enough free RAM first
free -h

# Then disable and re-enable swap to flush it
sudo swapoff -a && sudo swapon -a

If you are on an HDD and already have secure-delete installed, use sswap instead. It is more thorough. See the secure-delete section above for the exact steps.

8. How to Verify the File Is Gone

After you complete the steps above, verify your work. Do not just assume it worked.

Check the file no longer exists:

ls -la /path/to/file
# Expected: "No such file or directory"

Check no process still holds it open:

sudo lsof | grep deleted
# Expected: no output

Check no snapshot contains it:

sudo btrfs subvolume list /
# Expected: no relevant snapshot entries remain

Confirm TRIM ran successfully:

sudo journalctl -u fstrim --since "1 hour ago"
# Expected: entries showing successful trim of your device

Try to recover the file yourself:

# Debian, Ubuntu, Linux Mint, Pop!_OS
sudo apt install testdisk

# Fedora
sudo dnf install testdisk

# Arch Linux
sudo pacman -S testdisk

# openSUSE
sudo zypper install testdisk

sudo photorec

Point photorec at your partition and let it scan. If it cannot find the file, a casual attacker with standard tools cannot either. This is your best practical confirmation.

If you don't know how to use testdisk or phtorec to recover delete files, read the following guide:

• A Comprehensive Guide To Recover Data In Linux After Accidentally Deleting Your OS

9. Full-Disk Encryption

On SSDs and CoW file systems, secure deletion is always a best effort, but not a guarantee. The SSD controller has full control over where your data physically lives, and you cannot override that from the OS level.

The only way to have true, unbreakable data protection is to encrypt your drive from the start with LUKS (Linux Unified Key Setup). When your entire drive is encrypted:

• Even if someone pulls the physical drive, they see only encrypted noise.
• "Deleting" a file means the key to decrypt it is gone. Recovery becomes computationally infeasible with current technology.

To set up LUKS encryption on a new partition:

sudo cryptsetup luksFormat /dev/sdX
sudo cryptsetup open /dev/sdX my_encrypted_drive
sudo mkfs.ext4 /dev/mapper/my_encrypted_drive

This is an advanced setup and works best when planned from the moment you install Linux, not as an afterthought. However, if you handle sensitive data regularly, it is worth doing.

10. Quick Reference Cheat Sheet: Secure File Deletion on Linux

HDD + ext4 (using shred)

shred -uzn 3 /path/to/file
rm -rf ~/.local/share/Trash/{files,info}/*
rm -rf ~/.cache/thumbnails/

HDD + ext4 (using secure-delete - more thorough)

sudo srm /path/to/file              # securely delete a single file
sudo srm -r /path/to/folder        # or a folder
sudo sfill /home                    # wipe leftover traces in free space
sudo swapoff /dev/sdaX && sudo sswap /dev/sdaX && sudo swapon /dev/sdaX
sudo smem                           # clear RAM fragments (run when system is idle)
rm -rf ~/.local/share/Trash/{files,info}/*
rm -rf ~/.cache/thumbnails/

SSD (any file system except btrfs)

rm /path/to/file
rm -rf ~/.local/share/Trash/{files,info}/*
rm -rf ~/.cache/thumbnails/
sudo lsof | grep deleted
sudo fstrim -av

SSD + btrfs (Arch, Fedora, openSUSE, Ubuntu 24.04+)

rm /path/to/file
rm -rf ~/.local/share/Trash/{files,info}/*
rm -rf ~/.cache/thumbnails/
sudo snapper list                          # check for snapshots
sudo snapper delete <number>              # delete relevant ones
sudo lsof | grep deleted
sudo fstrim -av

Verify it worked

ls -la /path/to/file          # should not exist
sudo lsof | grep deleted      # should return nothing
sudo photorec                 # try to recover — expect to find nothing

Final Thoughts

Deleting a file on Linux is not the same as destroying it. However, by following the right method for your storage device and file system, you can make deleted data as difficult to recover as current hardware allows.

Modern Linux systems also require a different approach than older systems. The once-common advice to use shred no longer fits many real-world setups. SSDs, Btrfs, and other copy-on-write file systems handle data very differently from traditional hard disk drives.

Instead of trying to overwrite a file, focus on removing every copy of it. Delete the original file, empty the Trash, remove snapshots, check your backups, close any open file handles, and run TRIM on SSDs.

Most importantly, plan for privacy before you need it. If you regularly work with sensitive files, enable full-disk encryption when you install Linux. It provides much stronger protection than trying to securely delete individual files after the fact.

Key Takeaways:

• On HDDs, use shred for quick jobs or the full secure-delete toolkit for thorough cleanup, including free space, swap, and RAM.
• On SSDs, use rm and follow it up with fstrim.
• On btrfs, always check and remove snapshots. They are the biggest trap.
• For everything, clear thumbnail caches and check cloud sync.
• For maximum security, start with full-disk encryption using LUKS.

You do not need to be a security expert to handle this correctly. You just need to know which steps apply to your setup.

Recommended Read:

• Prevent Files And Folders From Accidental Deletion Or Modification In Linux
• An Easy Way to Protect Files From Accidental Deletion In Linux
• Clean Up Junk Files In Ubuntu Using Ubuntu Cleaner
• How To Recover Data From Synology NAS With Stellar Data Recovery Toolkit
• How To Recover Data From QNAP NAS With A Failed RAID 6 Array Using Stellar Toolkit