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:

(a) dumpe2fs

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.

  • Try photorec. I realize you want to fix the entire filesystem and with this tool you will (at best) recover some of the files only. But if it succeeds then you will know your data was decrypted well and it is still there waiting to be recovered. Plus you will have some of your files, which is hopefully better than nothing. – Kamil Maciorowski Dec 24 '16 at 9:37
  • @Kamil Maciorowski: Thank you for the suggestion. I did run photorec and it found some files. But not anything useful. But like you said, it tells us that the data has been decrypted correctly. – Jason Cotman Dec 25 '16 at 1:52
  • Please append (a) the output of dumpe2fs on the file system, and (b) the output of e2fsck -fy on a copy of the file system. That's the only way anyone can give you specific advise about steps to recover the file system. – Theodore Ts'o Dec 25 '16 at 4:35
  • @ Theodore Ts'o: I have edited my original post to include the output of each of those. Thank you for your reply. – Jason Cotman Dec 27 '16 at 0:53
  • @Kamil Maciorowski: To follow-up: photorec actually did find some useful stuff. Not everything, but about 15% of the important stuff, so that's a heck of a lot better than I'd have had without your help. Thank you. – Jason Cotman Dec 27 '16 at 10:37

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.