Lost ext4 partition: testdisk lists files, but fails to fix partition table

Question

Summary:

Testdisk finds the lost ext4 partition and is able to list containing files, but trying to write the partition structure to the disk does nothing.

Update: After running e2fsck -f /dev/sdc1, the disk was mounted and seems to be running normally. However, it also reported some errors (See 15. below).

What happened:

I will try to list everything I did related to the problem:

1. I got a new external 5TB hard drive that was pre-formatted as FAT32 (named Intenso).
2. I deleted that partition and created a new ext4 partition using gparted (named Intenso5TB).
3. As the partition belonged to root, I changed owner and group to my user.
4. I moved a few hundred GB of data to that partition, then safely removed it.
5. The next time I plugged in the hard drive, it was mounted as read only. My user was still the owner.
6. I added "rw" to the mount options in Ubuntu's "Disks" utility and unmounted the drive.
7. The Disks utility then displayed the partition /dev/sdc1 as "type unknown" and could not be mounted.
8. I chose "Edit Partition" and selected "Type linux (0x83)" (no type was preselected). There was no change (Still Type unknown).

9. I ran sudo testdisk /dev/sdc and did a quick analysis, which found:

   * Linux                    0   4  5 76000  41  9 1220942336 [Intenso5TB]
   

   pressing p shows the files I moved to the partition, so I told Testdisk to write the partition structure to the disk.

10. After another reboot to refresh the partition table, behaviour was again as described in 7.

11. I redid 9.; this time I tried using

    partprobe /dev/sdc
    

    to avoid rebooting again, but got the message:

    Error: Partition(s) 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64 on /dev/sdc have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.
    

12. sudo fdisk -lu returns

    Disk /dev/sdc: 4,6 TiB, 5000981078016 bytes, 1220942646 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 33550336 bytes
    Disklabel type: dos
    Disk identifier: 0x4400838c
    
    Device     Boot Start        End    Sectors  Size Id Type
    /dev/sdc1  *      256 1220942591 1220942336  4,6T 83 Linux
    

13. I ran sudo parted /dev/sdc then rescue 256 1220942591 which did nothing (no delay, no output, just a new command prompt inside parted), same with rescue 0 1220942591, rescue 1 1220942591 or rescue 1 -1.

14. I ran a deep search with Testdisk, which reported several identical lines of:

    Linux                    0   4  5 76000  41  9 1220942336 [Intenso5TB]
    

    as well as:

    check_FAT: can't read FAT boot sector
    Invalid FAT boot sector
     0 D FAT16 LBA            252822 192 45 254047 161 57   19677685
      FAT16 LBA            252822 192 45 254047 161 57   19677685
    

    while running and closed with:

    TestDisk 7.0, Data Recovery Utility, April 2015
    Christophe GRENIER <[email protected]>
    http://www.cgsecurity.org
    
    Disk /dev/sdc - 5000 GB / 4657 GiB - CHS 76000 255 63
    
    The harddisk (5000 GB / 4657 GiB) seems too small! (< 16 TB / 15 TiB)
    Check the harddisk size: HD jumpers settings, BIOS detection...
    
    The following partition can't be recovered:
         Partition               Start        End    Size in sectors
    >  FAT16 LBA            252822 192 45 254047 161 57   19677685
    
    
    
    
    
    
    
    
    
    
    [ Continue ]
    80 GB / 75 GiB
    

15. After running e2fsck -f /dev/sdc1, the disk showed up in the launcher. I cancelled e2fsck with Ctrl+C to avoid further changes until I know more. The drive was then successfully mounted on click. I seem to be able to read and write. Output from e2fsck:

    e2fsck -f /dev/sdc1
    e2fsck 1.42.13 (17-May-2015)
    ext2fs_open2: Bad magic number in super-block
    e2fsck: Superblock invalid, trying backup blocks...
    Superblock needs_recovery flag is clear, but journal has data.
    Recovery flag not set in backup superblock, so running journal anyway.
    Intenso5TB: recovering journal
    Pass 1: Checking inodes, blocks, and sizes
    Inode 59883521 is in use, but has dtime set.  Fix<y>? yes
    Inode 59883521 has imagic flag set.  Clear<y>? yes
    Inode 59883521 has compression flag set on filesystem compression support.  Clear<y>? yes
    Inode 59883521 has INDEX_FL flag set but is not a directory.
    Clear HTree index<y>? yes
    Inode 59883521, i_blocks is 16777216, should be 0.  Fix<y>? yes
    Deleted inode 59885573 has zero dtime.  Fix<y>? yes
    Deleted inode 59885574 has zero dtime.  Fix<y>? yes
    ^CIntenso5TB: e2fsck cancelled.
    
    Intenso5TB: ***** FILE SYSTEM WAS MODIFIED *****
    

My Questions:

1. Is there any obvious mistake I have made that could have caused this problem in the first place?

2. Is there any hope to recover the lost partition? New question: Are the errors reported by e2fsck a reason to worry? Could they hint at a physically damaged drive?

3. What causes the error message from partprobe in 11?

(The data was moved from another disk that I have not touched since, so, while it is not visible right now, it should be salvageable from there.)

Answer 1

Running e2fsck -f /dev/sdc1 fixed a bad superblock and the device was recognised without problems. I then let e2fsck fix all problems it discovered. On a subsequent run e2fsck did not report any further errors.

An extended offline test with smartctl completed after 9 hours reporting no errors (to prevent automatic spindown from aborting the test, I applied this workaround).