Is there a command to recover/undelete deleted files by rm?

$ rm -rf /path/to/myfile

How can I recover myfile? If there is such a tool how can I use it?


13 Answers 13


The link someone provided in the comments is likely your best chance.

Linux debugfs Hack: Undelete Files

That write-up though looking a little intimidating is actually fairly straight forward to follow. In general the steps are as follows:

  1. Use debugfs to view a filesystems log

    $ debugfs -w /dev/mapper/wks01-root
  2. At the debugfs prompt

    debugfs: lsdel
  3. Sample output

    Inode  Owner  Mode    Size    Blocks   Time deleted
    23601299      0 120777      3    1/   1 Tue Mar 13 16:17:30 2012
    7536655      0 120777      3    1/   1 Tue May  1 06:21:22 2012
    2 deleted inodes found.
  4. Run the command in debugfs

    debugfs: logdump -i <7536655>
  5. Determine files inode

    output truncated
        Fast_link_dest: bin
        Blocks:  (0+1): 7235938
      FS block 7536642 logged at sequence 38402086, journal block 26711
        (inode block for inode 7536655):
        Inode: 7536655   Type: symlink        Mode:  0777   Flags: 0x0   Generation: 3532221116
        User:     0   Group:     0   Size: 3
        File ACL: 0    Directory ACL: 0
        Links: 0   Blockcount: 0
        Fragment:  Address: 0    Number: 0    Size: 0
        ctime: 0x4f9fc732 -- Tue May  1 06:21:22 2012
        atime: 0x4f9fc730 -- Tue May  1 06:21:20 2012
        mtime: 0x4f9fc72f -- Tue May  1 06:21:19 2012
        dtime: 0x4f9fc732 -- Tue May  1 06:21:22 2012
        Fast_link_dest: bin
        Blocks:  (0+1): 7235938
    No magic number at block 28053: end of journal.
  6. With the above inode info run the following commands

    # dd if=/dev/mapper/wks01-root of=recovered.file.001 bs=4096 count=1 skip=7235938
    # file recovered.file.001
    file: ASCII text, with very long lines

Files been recovered to recovered.file.001.

Other options

If the above isn't for you I've used tools such as photorec to recover files in the past, but it's geared for image files only. I've written about this method extensively on my blog in this article titled:

How to Recover Corrupt jpeg and mov Files from a Digital Camera's SDD Card on Fedora/CentOS/RHEL.

  • 24
    I tried with debugfs -w /dev/sdb2 but lsdel sais: 0 deleted inodes found.
    – rubo77
    Sep 11, 2013 at 7:54
  • 7
    using extundelete is easier for ext3/4 and would probably lead to the same results.
    – eadmaster
    Jun 16, 2015 at 19:54
  • 6
    lsdel: Filesystem not open,how to resolve it?
    – 王奕然
    Oct 22, 2015 at 9:38
  • 7
    I get /dev/mapper/wks01-root: No such file or directory while opening filesystem Where did you get this /dev/mapper/wks01-root from? May 2, 2017 at 12:04
  • 3
    This does NOT work on ext3 or ext4, so it’s unfortunately quite useless. The debugfs manual states that: "This command was useful for recovering from accidental file deletions for ext2 file systems. Unfortunately, it is not useful for this purpose if the files were deleted using ext3 or ext4, since the inode's data blocks are no longer available after the inode is released."
    – Arcturus B
    Nov 19, 2021 at 9:59

With a bit of chances, sometimes I can recover deleted files with this script or next solution in the answer :


if [[ ! $1 ]]; then
    echo -e "Usage:\n\n\t$0 'file name'"
    exit 1

f=$(file 2>/dev/null /proc/*/fd/* | awk '$NF == "(deleted)"{print $(NF-1)}')

if [[ $f ]]; then
    echo "fd $f found..."
    cp -v "$f" "$1"
    echo >&2 "No fd found..."
    exit 2

There's another useful trick: if you know a pattern in your deleted files, type alt+sys+resuo to reboot+remount in read-only, then with a live-cd, use grep to search in the hard-drive :

grep -a -C 500 'known pattern' /dev/sda | tee /tmp/recover

then edit /tmp/recover to keep only what were your file(s) before.

Hey, if with unix philosophy all is files, it's time to take advantage of this, no ?

  • 11
    Your grep based solution is very clever and worked for me, even with the file system still mounted. Thanks!
    – wchargin
    Nov 27, 2014 at 20:16
  • I don't understand how the grep solution worked for you, it outputs only binary data. How is that useful?
    – w00t
    Aug 15, 2016 at 0:33
  • 2
    @w00t Sure, it "only" spits out binary data. But sometimes that binary data happens to contain the ASCII bits corresponding to the file I'm looking for. I guess I don't understand the question?
    – wchargin
    Sep 5, 2016 at 2:17
  • 1
    @w00t the trick is to use a search pattern that is very specific to that file. The grep command will take the 500 lines before and after each matching line, so it will still spit out a lot of irrelevant data, but with a text editor that can cope with that (e.g. Vim), it's easy to sort out the good from the bad stuff. You could also filter out all lines with nonprintable characters by piping it through another grep command: grep -av "[^[:print:]]" Mar 28, 2017 at 19:12
  • 1
    The grep solution worked for me with a modification: I did sudo grep --line-buffered -ab "$PATTERN" /dev/sda1 | tee lines and got byte offsets (like 123123123:line\n456456456:another\n...), then did n=1000; sudo dd of=before if=/dev/sda1 ibs=1 skip=$[123123123-$n] count=$n and n=1000; sudo dd of=after if=/dev/sda1 ibs=1 skip=123123123 count=$n with different n values. Oct 5, 2017 at 11:38

What worked for me was given by arch (only applies to text files):

grep -a -C 200 -F 'Unique string in text file' /dev/sdXN

where /dev/sdXN is the partition containing the lost file (check with mount if unsure).

Takes a little while, but worked when I accidentally deleted some source code I hadn't commited yet!

  • 7
    Very useful for programmers!. usually, we always lost our own codes.
    – pylover
    Jun 28, 2017 at 11:30
  • 3
    tell me about it, I accidentally ran rm data/*.json python myFile.py instead of rm data/*.json && python myFile.py Jun 30, 2017 at 9:03
  • 3
    Thanks mate, you just helped me recover a text file I spent 2 hours writing at night. P.S. /dev/sdXN is for the file system, right? I found mine with df -T | awk '{print $1,$2,$NF}' | grep "^/dev"
    – Alex
    Apr 15, 2018 at 16:31
  • I see just the binary of the file. Is there a way to convert it to normal format?
    – silgon
    Sep 21, 2018 at 7:25
  • grep: conflicting matchers specified
    – felwithe
    Sep 25, 2019 at 12:49

Recovery Tools - Command Line:

Recovery Tools - GUI:


In my personal experience, I get my data back using ufs-explorer and photorec

(1) = Not open source, not free

(2) = Not open source, free

(3) = Open source and free

(4) = Have NTFS support

(5) = Have directory structure feature

Sources: Linuxhacks.org
Disclosure: I am the owner of Linuxhacks.org

  • 1
    R-Linux got me the deleted files back, thx!
    – lowtechsun
    May 17, 2021 at 19:14
  • testdisk works well on exfat partition
    – rodvlopes
    Feb 12 at 23:07
  • testdisk worked like a charm. My only problem was picking which of the many copies of the target files was the most recent. A little scary running a program like this, as root but desperate times.. May 23 at 19:04

Although this Question is solved and a few years old, I want to mention the testdisk utility.

How to recover files with testdisk is explained well in this tutorial. To recover files run testdisk /dev/sdX and select your partition table type. After this, select [ Advanced ] Filesystem Utils, then choose your partition and select [Undelete]. Now you can browse and select deleted files and copy them to another location in your filesystem.

  • This seems to only apply to FAT partitions, though, which are uncommon on *nix.
    – Aurelius
    Sep 10, 2021 at 11:58
  • Yes, the tutorial applies to FAT filesystems. Testdisk itself should also work with filesystems which are more common on *nix, like Ext2 or Ext3. At least that's what the testdisk man page says. I didn't try it though. (@Aurelius Sorry for the late response btw.) Oct 26, 2021 at 18:00

An alternative may be using del instead of rm for deleting:


del has an undelete function and works with any file system.

Of course it is not a solution if you have already deleted your files with "take no prisoners" rm :-}

  • 4
    Not an answer as you have already said, but thanks for introducing the del command.
    – pylover
    Feb 12, 2016 at 8:26
  • I would also mention trash-cli by Andrea Francia ( github.com/andreafrancia/trash-cli ), perhaps a more "modern" tool. It integrates with the FreeDesktop.org Trash, it's a completely CLI tool and it can be found in most Linux distributions. Oct 30, 2021 at 21:35

I had the same problem last week and I tried a lot of programs, like debugfs, photorec, ext3grep and extundelete. ext3grep was the best program to recover files. The syntax is very easy:

ext3grep image.img --restore-all


ext3grep /dev/sda3 --restore-all --after `date -d '2015-01-01 00:00:00' '+%s'` --before `date -d '2015-01-02 00:00:00' '+%s'`

This video is a mini tutorial that can help you.

  • Didn't work on my ext4 drive, and I don't think there's an ext4grep. Aug 8, 2020 at 3:33

connect drive through external interface

  1. mount
  2. umount /dev/{sd*}
  3. extundelete --restore-all /dev/{sd*}
  4. results go to home folder on boot drive
  5. bonus points: write a GUI for this

See this link for more info: undelete a just deleted file on ext4 with extundelete.

  • 3
    Nice! Thanks for posting. extundelete is a new tool for me. I used this today and found it extremely helpful. Much more helpful IMO than the accepted answer. The only things I would add to this answer to improve it slightly are (1) to reiterate the instructions in some other answers that one should power down the affected computer as soon as one realizes that the files were mistakenly deleted, and (2) to boot from a liveCD or liveUSB OS like Kali Linux which includes the extundelete utility (I found that many other liveCDs like Debian Jessie do not include this utility on their install media). Mar 13, 2017 at 16:22

Recover deleted files with ext4magic

sources to read: https://wiki.archlinux.org/title/File_recovery#TestDisk_and_PhotoRec

Ext4magic is another recovery tool for the ext3 and ext4 file system.

Be very careful:

  • you must be in a different location, not in the HDD you are trying to recover. The best way is to make a clone of the HDD you are trying to recover, so you can try with different methods.
  • You should not write anymore in the disc that you want to recover.
  • This method works only for ext3 and ext4 file-systems, so please check what file system you are using before starting.

Example without cloning the HDD:

Before beginning, check what file system you have with the above command:

$ df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
dev            devtmpfs  3,9G     0  3,9G   0% /dev
run            tmpfs     3,9G  1,8M  3,9G   1% /run
/dev/sda2      ext4      458G  151G  284G  35% /
tmpfs          tmpfs     3,9G  4,3M  3,9G   1% /dev/shm
tmpfs          tmpfs     3,9G   56M  3,8G   2% /tmp

After you determine that you are using ext3 or ext4, go on and plug an external HDD drive and open the terminal from the external HDD

To recover all files, deleted in the last 24 hours:

ext4magic /dev/sdXY -r

To recover a directory or file:

ext4magic /dev/sda2 -f path/to/lost/file -r

The small R flag -r will only recover complete files, that were not overwritten. To also recover broken files, that were partially overwritten, use the big R flag -R. This will also restore not-deleted files and empty directories.

The default destination is ./RECOVERDIR which can be changed by adding the option -d path/to/dest/dir.

If a file exists in the destination directory, the new file is renamed with a trailing hash sign #.

To recover files deleted after 'five days ago':

ext4magic /dev/sdXY -f path/to/lost/file -a $(date -d -5days +%s) -r

ext4magic just successfully restored my deleted files (including the correct filenames!), after several other methods were not successful.


When you delete a file, the link count in the inode table for that file is decreased by one. In Unix, when the link count drops down to 0, the data blocks for that file are marked as free and typically, references to those data blocks are lost. I just discovered from @fedorqui's comment that there may be some way to access those blocks but that is only applicable to ext3 filesystem.

One way to preserve the files will be to write a function that will allow you to move the files to a trash area (let us say $HOME/.trash) and recover the needed files from there. This function can be aliased to rm. You can schedule a cron job to delete the files that have been in the trash area for a certain number of days.


This might save the trouble for some of you.
If you ever used gedit to edit that file, by default a copy of that file will be created.
For example let's suppose we have accidentaly deleted 'myfile.txt'.
In the folder that used to contain the file you have just deleted use these commands and you'll recover the copy from there:
ls | grep 'myfile.txt~'
With a bit of luck you'll find it and then:
cp 'myfile.txt~' 'myfile.txt'
I have recovered a file just now using this method. Best of luck!


Is this just outdated or have I misunderstood something?

When I have deleted a file, I can find it back in


It is a normal waste bin like in Windows.

Not the answer you're looking for? Browse other questions tagged or ask your own question.