The OS is Ubuntu 17.10 and I've been trying to recover(undelete) with extundelete. (The File System is ext4.) This didn't work. So, I tried with extundelete /dev/mapper/ubuntu--vg-root --restore-file /home/chan/origol/routes/user.js And It worked. However, I got another problem. Loading filesystem metadata ... extundelete: Block bitmap checksum does not match bitmap when trying to examine filesystem I couldn't find any information about it. How can I solve this problem?

Is there a simple option on extundelete how I can try to undelete a file called /var/tmp/test.iso that I just deleted? (it is not so important that I would start to remount the drive read-only or such things. I can also just re-download that file again) I am looking for a simple command with that I could try if I manage to fast-recover it. I know, it is possible with remounting the drive **in read-only**: (see https://unix.stackexchange.com/questions/90186/how-do-i-simply-recover-the-only-file-on-an-empty-disk-just-deleted?rq=1) But is this also possible somehow **on the still mounted disk?** --- For info: if the deleted file is on an NTFS partition it is easy with ntfsundelete e.g. if you know the size was about 250MB use sudo ntfsundelete -S 240m-260m -p 100 /dev/hda2 and then undelete the file by **inode** e.g. with sudo ntfsundelete /dev/hda2 --undelete --inodes 8270

I've googled and searched for the answer, but non of the software mentioned on the answers can search for yaml file?. I've changed the config of Foremost duplicating the txt line, changing the txt into yaml format, and tried that, but it seems like it cannot find anything, there's the only yaml folder inside of the output folder so the configs at least reads correctly and in the terminal I get only

foremost
Processing: stdin
|

for hours. But the file it self is less than a kb I guess or so, and I specified the exact folder where it was... But having no luck with it. What are some other ways? the file is on the VPS contabo server, so I don't have a physical access to the hardware Thank you PS also tried undelete but it says

extundelete: "/root/massa/massa-client/wallets/" is a directory. You need to use the raw filesystem device (or a copy thereof).
extundelete: Operation not permitted when trying to open filesystem /root/massa/massa-client/wallets/

Some rescue operations and similar need to be done with the the drive or volume unmounted. Previously I have downloaded an .iso of GParted which I put on a USB stick and booted up from it into a basic gui from which it was possible to rearrange the partitions on the disk. Now I just deleted a single file I've been working on for days with rm (I know..) and need to really try to get it back. ext4magic should be able to do it, I have the command ready to go. extundelete maybe but that one is unmaintained. I just put my debian-11.3.0-amd64-DVD-1.iso onto the USB from a dd command and booted from it. There was a 'rescue mode' option. That provided a semi-useless terminal with almost no commands or otherwise it allowed the root partition of the PC to be brought to life in a terminal. So I did that but the partition with the file I wanted to recover being /home was also mounted but I needed it unmounted. There are a few rescue things out there such as - https://www.supergrubdisk.org/ https://www.system-rescue.org/ ...which don't look like they have it. I just tested https://www.finnix.org/ - dd'd it to the USB and booted it into its terminal. It had a lot of commands but none to recover ext4 Does anyone know where can I find a bootable CD .iso image to put on the USB-stick which will boot into some kind of live system, not insist on partitioning the drive or installing itself, and have available the command ext4magic or otherwise extundelete ?

I am trying to restore a directory I accidentally deleted which contained many files. Ironically this was a fat finger error while trying to set up a backup! I am following the instructions here : The ext4magic command to generate a histogram is successful: [root] /mnt/reos-storage-2 $ ext4magic /dev/sda2 -H -a $(date -d "-70minutes" +%s) Filesystem in use: /dev/sda2 |-----------c_time Histogram----------------- after -------------------- Wed Jun 23 10:42:35 2021 1624441775 : 0 | | Wed Jun 23 10:49:35 2021 1624442195 : 43 |**************************************************| Wed Jun 23 10:56:35 2021 1624442615 : 0 | | Wed Jun 23 11:03:35 2021 1624443035 : 1 |** | Wed Jun 23 11:10:35 2021 1624443455 : 0 | | Wed Jun 23 11:17:35 2021 1624443875 : 3 |**** | Wed Jun 23 11:24:35 2021 1624444295 : 0 | | Wed Jun 23 11:31:35 2021 1624444715 : 0 | | Wed Jun 23 11:38:35 2021 1624445135 : 0 | | Wed Jun 23 11:45:35 2021 1624445555 : 0 | | Wed Jun 23 11:52:35 2021 |-----------d_time Histogram----------------- after -------------------- Wed Jun 23 10:42:35 2021 1624441775 : 0 | | Wed Jun 23 10:49:35 2021 1624442195 : 0 | | Wed Jun 23 10:56:35 2021 1624442615 : 1 |* | Wed Jun 23 11:03:35 2021 1624443035 : 9380 |**************************************************| Wed Jun 23 11:10:35 2021 1624443455 : 0 | | Wed Jun 23 11:17:35 2021 1624443875 : 0 | | Wed Jun 23 11:24:35 2021 1624444295 : 1 |* | Wed Jun 23 11:31:35 2021 1624444715 : 0 | | Wed Jun 23 11:38:35 2021 1624445135 : 0 | | Wed Jun 23 11:45:35 2021 1624445555 : 0 | | Wed Jun 23 11:52:35 2021 |-----------cr_time Histogram----------------- after -------------------- Wed Jun 23 10:42:35 2021 1624441775 : 0 | | Wed Jun 23 10:49:35 2021 1624442195 : 33 |**************************************************| Wed Jun 23 10:56:35 2021 1624442615 : 1 |** | Wed Jun 23 11:03:35 2021 1624443035 : 0 | | Wed Jun 23 11:10:35 2021 1624443455 : 0 | | Wed Jun 23 11:17:35 2021 1624443875 : 0 | | Wed Jun 23 11:24:35 2021 1624444295 : 0 | | Wed Jun 23 11:31:35 2021 1624444715 : 0 | | Wed Jun 23 11:38:35 2021 1624445135 : 0 | | Wed Jun 23 11:45:35 2021 1624445555 : 0 | | Wed Jun 23 11:52:35 2021 ext4magic : EXIT_SUCCESS However, any further commands essentially end in a segfault [root] /mnt/reos-storage-2 $ ext4magic /dev/sda2 -a 1624442615 -f r sftp_data -l Filesystem in use: /dev/sda2 Using internal Journal at Inode 8 Activ Time after : Wed Jun 23 11:03:35 2021 Activ Time before : Wed Jun 23 11:56:09 2021 Segmentation fault Is there anything I can do? ---------- **More Background** As background, I got to this point with roughly the following steps. I unmounted the file system as quickly as I could after frantic googling. Initially I did this with umount -l /mnt/reos-storage-1 I used the -l option because umount could not unmount the partition which was still in use. Next I did fuser -cuk /mnt/reos-storage-1/ Next I ran fsck /dev/sda2 which is not recommended by ext4magic actually. Next I tried to recover the files with extundelete which failed [root] /mnt/reos-storage-2 $ extundelete --restore-directory /mnt/reos-storage-1/sftp_data /dev/sda2 NOTICE: Extended attributes are not restored. Loading filesystem metadata ... 29027 groups loaded. Loading journal descriptors ... 0 descriptors loaded. extundelete: Extent block checksum does not match extent block while finding inode for mnt extundelete: Extent block checksum does not match extent block while finding inode for mnt Failed to restore file /mnt/reos-storage-1/sftp_data Could not find correct inode number past inode 2. Try altering the filename to one of the entries listed below. File name | Inode number | Deleted status extundelete: Operation not permitted while restoring directory. extundelete: Operation not permitted when trying to examine filesystem [root] /mnt/reos-storage-2 $ man umount [root] /mnt/reos-storage-2 $ extundelete --restore-all /dev/sda2 NOTICE: Extended attributes are not restored. Loading filesystem metadata ... 29027 groups loaded. Loading journal descriptors ... 0 descriptors loaded. Searching for recoverable inodes in directory / ... 0 recoverable inodes found. Looking through the directory structure for deleted files ... 0 recoverable inodes still lost. No files were undeleted. I then installed ext4magic using apt and ran the following command as in the instructions to make a backup of the journal debugfs -R "dump /tmp/sda2.journal" /dev/sda2

I'm trying to restore 2 important tar.gz files I know their directory but extundelete not restoring them although it's giving me the inode number. Loading filesystem metadata ... 2127 groups loaded. Loading journal descriptors ... 26473 descriptors loaded. Unable to restore inode 3538958 (file.tar.gz): No data found. Unable to restore file file.tar.gz extundelete: Operation not permitted when trying to examine filesystem extundelete: Operation not permitted when trying to examine filesystem And Loading filesystem metadata ... 2127 groups loaded. Loading journal descriptors ... 26473 descriptors loaded. Unable to restore inode 3538958 (file.tar.gz): No data found. Unable to restore file file2.tar.gz extundelete: Operation not permitted when trying to examine filesystem extundelete: Operation not permitted when trying to examine filesystem Is there a way to repair the inode or get the file? Do you advice to use other recovering software for CentOS 6 64bit

A folder with backup files was accidentally deleted from the /home partition on a Ubuntu 20.04 machine. All files in the folder were backups (zip) of the same thing (a Minecraft world) but from different dates. As it would be enough to get back only one of the 30 newest files a saw a good chance to recover at least one of them. I removed /home (which is a separate mount) from fstab, enabled root login, rebooted the machine and logged in as root. I first tried to recover the file using

, and it seemed to find the file but was not able to recover it. I tried several of the lost files and got the same output:

root@arne:~# extundelete /dev/sdb1 --restore-file 'TBS_world-2021-10-09.zip'
NOTICE: Extended attributes are not restored.
Loading filesystem metadata ... 4456 groups loaded.
Loading journal descriptors ... 0 descriptors loaded.
extundelete: Extent block checksum does not match extent block while finding inode for TBS_world-2021-10-09.zip
extundelete: Extent block checksum does not match extent block while finding inode for TBS_world-2021-10-09.zip
Failed to restore file TBS_world-2021-10-09.zip
Could not find correct inode number past inode 2.
Try altering the filename to one of the entries listed below.
File name                                       | Inode number | Deleted status
extundelete: Operation not permitted while restoring file.
extundelete: Operation not permitted when trying to examine filesystem

Next I tried

, which clearly detected the 423 deleted files:

root@arne:~# ext4magic /dev/sdb1 -H -a 1640202942 -b 1640203868
Filesystem in use: /dev/sdb1

|-----------d_time  Histogram-----------------  after  --------------------  Wed Dec 22 20:55:42 2021
1640203034 :        0 |                                                  |   Wed Dec 22 20:57:14 2021
1640203126 :        0 |                                                  |   Wed Dec 22 20:58:46 2021
1640203218 :        0 |                                                  |   Wed Dec 22 21:00:18 2021
1640203310 :        0 |                                                  |   Wed Dec 22 21:01:50 2021
1640203402 :        0 |                                                  |   Wed Dec 22 21:03:22 2021
1640203494 :        0 |                                                  |   Wed Dec 22 21:04:54 2021
1640203586 :        0 |                                                  |   Wed Dec 22 21:06:26 2021
1640203678 :      423 |**************************************************|   Wed Dec 22 21:07:58 2021
1640203770 :        0 |                                                  |   Wed Dec 22 21:09:30 2021
1640203862 :        0 |                                                  |   Wed Dec 22 21:11:02 2021

ext4magic : EXIT_SUCCESS

Trying to look for any of the files gives promising output, but actually recovering the file says it can't be found:

root@arne:~# ext4magic /dev/sdb1 -f albin/Backups/TBS_world-2021-10-10.zip -l
Filesystem in use: /dev/sdb1

Using  internal Journal at Inode 8
Inode found "albin/Backups/TBS_world-2021-10-10.zip"   18350376
Inode 18350376 is a directory but not found after 1640359705 and before 1640446105
ext4magic : EXIT_SUCCESS

root@arne:~# ext4magic /dev/sdb1 -f albin/Backups/TBS_world-2021-10-10.zip
Filesystem in use: /dev/sdb1

Error: Filename "albin/Backups/TBS_world-2021-10-10.zip" not found in Filesystem
if "albin/Backups/TBS_world-2021-10-10.zip" deleted, use InodeNr or try Journaling options

Running

shows the deleted directory, but the contents can't be accessed. It says the file system may be damaged.

TestDisk 7.1, Data Recovery Utility, July 2019                                                                                                                
Christophe GRENIER                                                                                                                    
https://www.cgsecurity.org                                                                                                                                     
 1 P Linux filesys. data         2048 1167943679 1167941632                                                                                                   
Directory /albin/Backups                                                                                                                                      
                                                                                                                                                              
No file found, filesystem may be damaged.

Any idea why these errors occur? It looks so promising with all tools, but it fails in the end. It seems plausible that at least one of the lost files should still be there without corruption. I don't understand why I get the errors I get.

## The problem I erroneously removed several files from my /home/username with rm. I realized the mistake as soon as I hit enter, but the damage was done. I immediately created a full disk image with sudo dd if=/dev/sda of=/media/username/external_drive/image.iso and copied it to another PC and prepared to follow a very long path towards data recovery. And then realized I had no idea about where to start from. ## What I did I read some guides online and eventually extundelete /dev/partition_to_recover_from --restore-directory /path/to/restore came up as the most promising solution, so I tried it. The first problem I encountered was that I had encrypted my drive with LUKS (during OS install) and had to decrypt it. After some more research, I prepared the partition with the following commands (here I changed the real volume group name from the real value of -vg to pc-vg).

$ sudo kpartx -a -v image.iso # map the disk image partitions
add map loop0p1 (254:0): 0 997376 linear 7:0 2048
add map loop0p2 (254:1): 0 2 linear 7:0 1001470
add map loop0p5 (254:2): 0 975769600 linear 7:0 1001472

$ sudo cryptsetup luksOpen /dev/mapper/loop0p5 img # unlock the partition with my data
Enter passhprase for /dev/mapper/loop0p5:

$ lsblk
NAME                  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
loop0                   7:0    0 465,8G  0 loop
├─loop0p1             254:0    0   487M  0 part
├─loop0p2             254:1    0     1K  0 part
└─loop0p5             254:2    0 465,3G  0 part
  └─img               254:3    0 465,3G  0 crypt
    ├─pc--vg-root   254:4    0 464,3G  0 lvm
    └─pc--vg-swap_1 254:5    0   980M  0 lvm

[...omitting other lsblk output...]

$ sudo vgchange -a y pc-vg
  2 logical volume(s) in volume group "pc-vg" now active

and then tried to recover with

$ sudo extundelete /dev/mapper/pc--vg-root --restore-directory /home/username/path/to/restore
NOTICE: Extended attributes are not restored.
WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set.
The partition should be unmounted to undelete any files without further data loss.
If the partition is not currently mounted, this message indicates 
it was improperly unmounted, and you should run fsck before continuing.
If you decide to continue, extundelete may overwrite some of the deleted
files and make recovering those files impossible.  You should unmount the
file system and check it with fsck before using extundelete.
Would you like to continue? (y/n)

However, the partition was not mounted and df confirmed that. Also, sudo fsck -N only wanted to operate on /dev/sdaX. In doubt, I rebooted the system and repeated the above steps. I received exactly the same output, and considering that I was working on a copy of the original disk image (so I had a backup to use in case of data loss) this time I answered y. The result was:

$ sudo extundelete /dev/mapper/pc--vg-root --restore-directory /home/username/path/to/restore
NOTICE: Extended attributes are not restored.
WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set.
The partition should be unmounted to undelete any files without further data loss.
If the partition is not currently mounted, this message indicates 
it was improperly unmounted, and you should run fsck before continuing.
If you decide to continue, extundelete may overwrite some of the deleted
files and make recovering those files impossible.  You should unmount the
file system and check it with fsck before using extundelete.
Would you like to continue? (y/n) 
y
Loading filesystem metadata ... extundelete: Extended attribute has an invalid value length when trying to examine filesystem

I did do other research, but I couldn't understand what that means. ## The questions I'll try to avoid the [XY problem](https://meta.stackexchange.com/a/66378/613169) . Is the method I used to try to recover my data corect? If so, what is extundelete complaining about and how can I resolve it? If not, how can I (try to) restore my data from the LUKS-encrypted disk in Debian? If any additional info is required, please ask for it. **P. S.:** «Restore from your recent backup you *obviously* have» is the correct answer, I know =). I do have a full backup of my home taken a couple of days before the data loss (not *such* a n00b), but I lost the product of more than twenty hours of work and I would like to have it back. --- ## Update I tried running fsck on the partition with my data, and the result was

$ sudo fsck -r /dev/mapper/pc--vg-root
fsck from util-linux 2.36.1
e2fsck 1.46.2 (28-Feb-2021)
/dev/mapper/pc--vg-root: recovering journal
Clearing orphaned inode 7077927 (uid=1000, gid=1000, mode=0100600, size=0)
Clearing orphaned inode 7077925 (uid=1000, gid=1000, mode=0100600, size=65536)
Clearing orphaned inode 19794062 (uid=1000, gid=1000, mode=040775, size=4096)
Clearing orphaned inode 18366502 (uid=1000, gid=1000, mode=040755, size=4096)
Clearing orphaned inode 18366515 (uid=1000, gid=1000, mode=040755, size=4096)
Clearing orphaned inode 18366503 (uid=1000, gid=1000, mode=040755, size=4096)
Clearing orphaned inode 18366504 (uid=1000, gid=1000, mode=040755, size=4096)
Clearing orphaned inode 18366511 (uid=1000, gid=1000, mode=040755, size=4096)
Clearing orphaned inode 18366512 (uid=1000, gid=1000, mode=040755, size=4096)
Clearing orphaned inode 18351755 (uid=1000, gid=1000, mode=0100444, size=15383322)
Clearing orphaned inode 18351757 (uid=1000, gid=1000, mode=0100444, size=12832)
Clearing orphaned inode 18366521 (uid=1000, gid=1000, mode=040755, size=4096)
Clearing orphaned inode 7078039 (uid=1000, gid=1000, mode=0100600, size=0)
Clearing orphaned inode 7077945 (uid=1000, gid=1000, mode=0100600, size=65536)
Clearing orphaned inode 11927591 (uid=0, gid=0, mode=0100644, size=147932)
Clearing orphaned inode 18096551 (uid=0, gid=0, mode=0100644, size=2456)
Clearing orphaned inode 11535970 (uid=0, gid=0, mode=0100644, size=335240)
Setting free inodes count to 29879660 (was 29737485)
Setting free blocks count to 41417686 (was 20072881)
/dev/mapper/pc--vg-root: clean, 553620/30433280 files, 80298026/121715712 blocks
/dev/mapper/pc--vg-root: status 0, rss 6876, real 38.344677, user 0.482391, sys 0.290328

I don't know how filesystems work, but to my understanding of what I read in the last hours, it looks like fsck just removed the data I was trying to restore? Now extundelete runs without complaints, but

$ sudo extundelete /dev/mapper/pc--vg-root --restore-directory /home/username/path/to/restore
NOTICE: Extended attributes are not restored.
Loading filesystem metadata ... 3715 groups loaded.
Loading journal descriptors ... 0 descriptors loaded.
Searching for recoverable inodes in directory /home/username/path/to/restore...
0 recoverable inodes found.
Looking through the directory structure for deleted files ... 
0 recoverable inodes still lost.
No files were undeleted.

I know I can not restore overwritten data, but I erroneously removed more than 100GB, I don't think they can have been all overwritten before I created the disk image with dd...

When looking up a way to uninstall minecraft using console commands, the very first result on google told me to use the command: rm -vr ~/ .minecraft/*. I thought, oh well, I'm specifying the directory so this should work fine. The command proceeded to start deleting every folder in my home directory. Luckily I caught on to what was happening, but not before my aseprite folder got obliterated. I know for a fact that the folder directory was /home/kaiser/aseprite/ and I haven't installed or deleted anything in the home directory since. I'm afraid to change anything or restart my computer because I don't want that partition space to be overwritten. That folder had lots of works in progress that were very important to me, none of it was backed up yet. I am not touching anything until I can get it back. I am running **Linux Mint XFCE 20.2** on a **1TB HDD**. My motherboard is a Gigabyte H310M H 2.0. If there is any way to recover these files please leave your suggestions. As of writing this post they were deleted about 1 hour ago. **EDIT**: my partition is EXT4 (ver 1.0). I also have a **saved session** from a few days ago, not sure if that can be used as a restore point though, since I don't think that saved sessions count as backups.

ext4, extundelete needs fs umounted right? and would restore to another fs, that wont work for me. The deleted are big files, if umounting and restoring on another filesystem I would have to copy back to the original fs. So, I wonder if there is some way to just restore on the mounted filesystem, and to the mounted fs. I read there could have a way to "re-link" the deleted files, but we would need to know the deleted inode, and nothing is listed by debugfs -w. Any other idea? Actually I dont really need to keep it mounted, just that the files are restored direcly on the same FS, if it could be done umounted would work too. Edit: by what I read here https://unix.stackexchange.com/a/266107/30352 it is impossible with ext4!

I had a folder deleted from a SMB share from a windows machine. Thanks to zero confirmation a whole folder was deleted. First ran *photorec* that pulled most of the files except 1, the very last file copied. Further testing with *extundelete* was able to pull the whole folder minus 4-5 files. However the single most important file again was not recovered. Looking at the inodes I can see the files recovered have sequential inodes. So i was able to narrow down the exact inode. However I get the following trying to recover that specific inode. Loading filesystem metadata ... 59613 groups loaded. Loading journal descriptors ... 29932 descriptors loaded. Unable to restore inode 60596808 (file.60596808): No undeleted copies found in the journal. However when I search for that inode I do get data: Loading filesystem metadata ... 59613 groups loaded. Group: 14794 Contents of inode 60596809: 0000 | e4 81 e8 03 dd df b2 1b 43 2d 08 5d 53 2d 08 5d | ........C-.]S-.] 0010 | fd 97 05 5d 53 2d 08 5d e8 03 00 00 00 00 00 00 | ...]S-.]........ 0020 | 00 00 08 00 01 00 00 00 0a f3 00 00 04 00 00 00 | ................ 0030 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 0040 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 0050 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 0060 | 00 00 00 00 70 57 ff 3f 00 00 00 00 00 00 00 00 | ....pW.?........ 0070 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 0080 | 20 00 00 00 ec e9 88 2a b0 16 cf 0f 1c 76 bb a2 | ......*.....v.. 0090 | 3c 2d 08 5d d4 64 6c a9 00 00 00 00 00 00 00 00 | <-.].dl......... 00a0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00b0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00c0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00d0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00e0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00f0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ Inode is Unallocated File mode: 33252 Low 16 bits of Owner Uid: 1000 Size in bytes: 464707549 Access time: 1560816963 Creation time: 1560816979 Modification time: 1560647677 Deletion Time: 1560816979 Low 16 bits of Group Id: 1000 Links count: 0 Blocks count: 0 File flags: 524288 File version (for NFS): 1073698672 File ACL: 0 Directory ACL: 0 Fragment address: 0 Direct blocks: 62218, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 Indirect block: 0 Double indirect block: 0 Triple indirect block: 0 Using *debugfs* I tried to dump the inode however all I got was a file the correct size but zero'd. The size in bytes, dates, I am 99% sure this is the exact inode file I need. Is this data basically a stub missing a pointer to the exact locations on the disk? Is there anyway to use this inode data to recover the actual data?

I have a luks encrypted SD Card and I want to recover all deleted files from it. I have been truing with extundelete using the following commands: extundelete --restore-directory RecoverDir/ /media/user/Cardname/ extundelete: "/media/user/Cardname/" is a directory. You need to use the raw filesystem device (or a copy thereof). extundelete: Operation not permitted when trying to open filesystem /media/user/Cardname/ so I tried using using the device with: extundelete --restore-directory RecoverDir/ /dev/dm-0 extundelete: Permission denied when trying to open filesystem /dev/dm-0 ok, this way I do not call the decrypted device, so I tried: extundelete --restore-directory RecoverDir/ /dev/mapper/luks-63728377-654f-7ad0-8fa7-aa890ab098b7 extundelete: Permission denied when trying to open filesystem /dev/mapper/luks-63728377-654f-7ad0-8fa7-aa890ab098b7 > I changed the numbers of the filename. when I try as root I get extundelete: Superblock checksum does not match superblock when trying to open filesystem Is there a way to get this going, or does extundelete not go with encrypted luks devices?

## summary How to (relatively painlessly and reliably) {restore, undelete} a file from an ext4 filesystem inside a LVM volume inside a LUKS container, given one knows the fully-qualified path to the file before it was deleted? (Apologies in advance if I'm using incorrect terms--please correct where necessary.) ## details The good news is, it's been years since I accidentally deleted a file that I couldn't easily restore (e.g., from backup). Define some terms for exactness: * call the file I {deleted, seek to restore} the target file * call the directory/folder in which the target file formerly resided the target dir * call the partition {on which the target file formerly resided, to which I seek to restore the target file} the target partition The bad news is, * The last time, the target partition was "simple ext4": i.e., no encryption or other management. * This time, the target partition is the one with name=LVM2_crypt-home from the following lsblk table: NAME MAJ:MIN SIZE TYPE MOUNTPOINT sda 8:0 465.8G disk ├─sda1 8:1 16.6G part ├─sda2 8:2 97.7G part ├─sda3 8:3 500M part /boot ├─sda4 8:4 1K part └─sda5 8:5 351G part └─LVM2_crypt 254:0 351G crypt ├─LVM2_crypt-swap 254:1 3.9G lvm ├─LVM2_crypt-root 254:2 20G lvm / └─LVM2_crypt-home 254:3 327.1G lvm /home I believe I recall how to recover a file from a simple partition using [extundelete](http://extundelete.sourceforge.net/) : see procedure below. What I'd like to know is 1. Will the same or similar procedure work for a managed+encrypted partition? If not same, what needs added, modified, or deleted? 1. Is there a more reliable tool (than extundelete) for this usecase? If so, what is its procedure for this usecase? ### simple-partition procedure My procedure last time--for the "simple" ext4 partition--used extundelete like the following (bash) example: 1. Read info extundelete and (the all-too-meager) [extundelete doc](http://extundelete.sourceforge.net/) (scroll down to heading=Documentation). Note that it can handle usecases other than that illustrated here, e.g., restore *all* deleted files from a partition. 1. Specify the target file: 1. define its fully-qualified path TARGET_FQP, remembering **not** to use ~: # CHANGE FOR YOUR USECASE! TARGET_FQP="${HOME}/video/greatest_movie_ever.mp4" echo "TARGET_FQP='${TARGET_FQP}'" 1. define its directory/folder (which we'll assume is on the same (target) partition as the target file): TARGET_DIR="$(dirname "${TARGET_FQP}")" echo "TARGET_DIR='${TARGET_DIR}'" 1. define its filename (for use below) TARGET_FN="$(basename "${TARGET_FQP}")" echo "TARGET_FN='${TARGET_FN}'" 1. Identify the target partition TARGET_PART and its mount point TARGET_MP from your target dir: TARGET_PART="$(df --output=source "${TARGET_FQP}" | tail -1)" echo "TARGET_PART='${TARGET_PART}'" TARGET_MP="$(df --output=target "${TARGET_FQP}" | tail -1)" echo "TARGET_MP='${TARGET_MP}'" 1. Open your shell of choice (in your terminal of choice) with a current working directory (CWD) such that * CWD is on a partition other than the target. (Get information about your partitions using lsblk, fdisk or your tool of choice.) * extundelete will restore any file it finds (if any) to a CWD subdir name=RECOVERED_FILES, so I'm guessing that, if you already have one with that name, you want to move it. (If you know how to override that, please lemme know. IIRC, --restore-directory does *not* do this.) 1. Remount the target partition read-only: mount --options remount,ro --source "${TARGET_PART}" 1. Run extundelete: date # because if this runs too long, you'll wanna give up extundelete --restore-file "${TARGET_FQP}" "${TARGET_PART}" 1. Check the restored file: SAVED_RELPATH="./RECOVERED_FILES/${TARGET_FN}" echo '(hopefully) restored file @' ls -al "${SAVED_RELPATH}" 1. Presuming the restored file @ SAVED_RELPATH is what you want, you can either remount TARGET_PART read/write and move it there, or (what I usually do) 1. move the restored file to an external backup 1. reboot the PC containing TARGET_PART 1. copy the restored file from the backup to TARGET_DIR Your corrections or improvements are welcome.

So, i accidentally delete my files. I attempt to recover files using extundelete with --restore-all options. Inside the RECOVERED_FILES directory i got files.xxxxx which i think is inode file. My question is what to do with file.xxxxx file ?

Apart of unix perms are there other protection for don't remove or overwrite files? By example: 1. Restringing dirs than rm can delete. 2. Overwrite protection when I made cat >file instead of cat >>file 3. Overwrite protection option for default for all commands cp, rsync, etc. No configuration command by command. 4. If there are a trash system, substituting overwrite by removing file and create a new one with same name. 5. Delayed delete.

Around 1.5 hours ago I deleted a very important directory on my openVZ vps. I have tried root@server:/home extundelete /dev/simfs --restore-directory ./ --output-dir /home/restore/ extundelete: failed to read-only open device "/dev/simfs": Error code 1 How can I solve this issue?

I accidentally deleted the file .vimrc in my $HOME directory. I rebooted the system and accessed it as root. Then: $ sudo mount -o remount,ro /dev/sda5 $ sudo extundelete /dev/sda5 --restore-file /home/xralf/.vimrc The output of the command indicates that it failed to restore .vimrc file. Is the file already absolutely lost or is there some other possibility to recover it?