tl;dr: How do I recover data from an ext4 volume that is giving errors like "Structure Needs Cleaning?" I've tried lots of things, as described below, but still no success.
EDIT: Please see below original post for the output of e2fsck and dumpe2fs as per a commentor's request. Original post follows.
In attempting to mount a Truecrypt 7.1 volume that I use frequently, today I got this lovely error:
Error: mount: mount /dev/mapper/truecrypt1 on /media/truecrypt1 failed: Structure needs cleaning
Then I tried to mount this with command-line truecrypt 7.1a on another system and got this error:
Error: mount: wrong fs type, bad option, bad superblock on /dev/mapper/truecrypt1,
Here are the steps I have taken so far:
1 - Decrypted but did not mount with Truecrypt using:
truecrypt --filesystem=none /dev/xxx.
This seems to give me an unencrypted but unmounted partition. Then I backed that up using dd and am attempting everything else on the backups.
2 - So then I try to mount it:
mount sda3.1 /mnt/tmp
... and I get the not surprising:
mount: mount /dev/loop0 on /mnt/tmp failed: Structure needs cleaning
3 - So then I try:
dmesg | tail
... and that gives me:
[ 1283.815816] EXT4-fs (loop0): ext4_check_descriptors: Block bitmap for group 64 not in group (block 1312711560940789246)!
[ 1283.815825] EXT4-fs (loop0): group descriptors corrupted!
I should mention that I am not certain that this was an ext4 volume. I honestly don't remember whether it was 2, 3, or 4. But from the above message I assume it's ext4. Just thought that might be important to mention.
4 - Now I try fsck.ext4 and things go bad. If I run it automatically, I get:
sda3.1: Note: if several inode or block bitmap blocks or part of the inode table require relocation, you may wish to try running e2fsck with the '-b 32768' option first. The problem may lie only with the primary block group descriptors, and the backup block group descriptors may be OK.
sda3.1: Block bitmap for group 64 is not in group. (block 1312711560940789246)
sda3.1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options)
5 - So now I think maybe I should try running fsck manually. So I do that. The problem is that one of two things happens:
i) I choose "y" for everything and the end result is that I can mount the volume but it's completely empty OR
ii) I have to decide what to say "y" and "n" to and I don't have a damned clue how to discern. I've been reading up on filesystems a little but it's still guesswork. Plus, there are HUNDREDS of questions that come up (the first of which is indeed about group 64... and then 65, 66, etc), so even if I did know what to do it would take me many hours to do it - and I can't make a single mistake or I might lose data, right?
6 - I read this thread: How to restore an ext4 filesystem and I also "tried mount with alternate superblock locations" as in:
mount -t ext4 -o sb=131072,ro sda3.1 /mnt/data_c
As he did, "I did the above, with the sb option equal to multiples of 4 of all the following numbers: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000." Each time, I got the same error:
mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error
In some cases useful info is found in syslog - try dmesg | tail or so. 7 - I ran testdisk and there are a lot of options but choosing Intel/PC partition table on the sda3.1 file gives me:
Partition sector doesn't have the endmark 0xAA55
... and testdisk does not see any partitions.
So this is where I am right now. If you can help, I would appreciate it. Obviously if this data didn't matter, I wouldn't care. It's not life threatening but it's extremely useful stuff to me. Why didn't I back it up, you might ask. Because sometimes you don't realize how important something has become until you lose it. And because I am an idiot sometimes.
Thank you in advance.
EDIT: I am appending outputs to my original post as per a request from a commentor:
dumpe2fs 1.43.3 (04-Sep-2016) Filesystem volume name: Last mounted on: /mnt/truecrypt1 Filesystem UUID: 26177e9d-7268-48e8-86ff-47373c24d454 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean with errors Errors behavior: Continue Filesystem OS type: Linux Inode count: 1501440 Block count: 5998016 Reserved block count: 299900 Free blocks: 2303431 Free inodes: 1393801 First block: 0 Block size: 4096 Fragment size: 4096 Group descriptor size: 64 Reserved GDT blocks: 1024 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8160 Inode blocks per group: 510 Flex block group size: 16 Filesystem created: Sat Apr 9 17:57:07 2016 Last mount time: Mon Dec 19 02:11:03 2016 Last write time: Mon Dec 19 03:24:29 2016 Mount count: 382 Maximum mount count: -1 Last checked: Sat Apr 9 17:57:07 2016 Check interval: 0 () Lifetime writes: 95 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 32 Desired extra isize: 32 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 65bfc178-1879-4c35-ab2c-39bf976dff4c Journal backup: inode blocks FS Error count: 9760 First error time: Mon Dec 19 03:24:13 2016 First error function: ext4_read_inode_bitmap First error line #: 186 First error inode #: 0 First error block #: 0 Last error time: Mon Dec 19 03:24:21 2016 Last error function: ext4_iget Last error line #: 4095 Last error inode #: 14 Last error block #: 0 Checksum type: crc32c Checksum: 0x989a676a dumpe2fs: Inode checksum does not match inode while reading journal inode
(b) e2fsck -fy
The output for this is much too long to post. So here is a link: e2fsck output
The end product is mountable but it's not recovered. There is one file in lost and found and that file is very large. I can provide details if you want.
Thank you for helping. I look forward to your take on the above.