Need some serious help to protect my file through FSCK in Linux

Question

This is Ubuntu 18.10 dual booted with Windows 10. A folder in my external hard disk is not opening. Shows a "lock" sign. And i tried below FSCK commands, it is giving me some direction which I don't understand. Help me to decode/resolve this issue.

pranav@inspiron-5548:~$ sudo umount /dev/sdb
umount: /dev/sdb: not mounted.
pranav@inspiron-5548:~$ sudo fsck /dev/sdb
fsck from util-linux 2.32
e2fsck 1.44.4 (18-Aug-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

Found a gpt partition table in /dev/sdb
pranav@inspiron-5548:~$ sudo fsck -y /dev/sdb
fsck from util-linux 2.32
e2fsck 1.44.4 (18-Aug-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

Found a gpt partition table in /dev/sdb
pranav@inspiron-5548:~$ e2fsck -b 8193 /dev/sdb
e2fsck 1.44.4 (18-Aug-2018)
e2fsck: Permission denied while trying to open /dev/sdb
You must have r/w access to the filesystem or be root
pranav@inspiron-5548:~$ sudo e2fsck -b 8193 /dev/sdb
e2fsck 1.44.4 (18-Aug-2018)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

Found a gpt partition table in /dev/sdb
pranav@inspiron-5548:~$ sudo e2fsck -b 32768 /dev/sdb
e2fsck 1.44.4 (18-Aug-2018)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

Found a gpt partition table in /dev/sdb

pranav@inspiron-5548:~$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 465.8 GiB, 500107859968 bytes, 976773164 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 2E688F46-2196-5965-EED0-7AF7C385FADA

Device     Start       End   Sectors   Size Type
/dev/sdb1     63 976773119 976773057 465.8G Micros
pranav@inspiron-5548:~$ lsblk -o +LABEL, FSTYPE /dev/sdb
lsblk: unknown column: LABEL,

I selected "Repair File System" from Disk Utitity of Ubuntu. But it does seems to stop. Its been like 20 minutes. What should i do?

Answer 1

Your output contains this a few times:

Found a gpt partition table in /dev/sdb

sdb is the entire drive/device, and it's been partitioned, so the actual partition you want to mount must be sdb1, sdb2, sdb3, etc.

You can use one of these commands to see what partitions there are:

• fdisk -l /dev/sdb
• lsblk -o +LABEL,FSTYPE /dev/sdb

Or sometimes it's just nicer to use a GUI like Disks / gnome-disk-utility, to click on the partition you want & click on the "play" button to mount it. But if Disks shows a partition with a padlock sign on it, that means it's encrypted, and the "play" button changes to an "unlocked padlock" so you can decrypt it, if you know the password/phrase.

---

Update

After seeing some updated info, like the screenshot from Disks, it appears to be a 500GB FAT partition on /dev/sdb1 taking up the whole drive. That explains why mount -t extN was failing. I see no mention of 250GB... unless that's how much space is taken by files?

• I don't know why Disks' repair filesystem was taking so long, but it doesn't show you the terminal to check, and I haven't had a 500GB FAT filesystem before, it could be trying to read the entire drive or something, and could've taken an hour or two to complete. Running fsck.fat in a terminal would show you what it's doing (especially with the -v verbose flag).

mount (without a -t) should still work, as my comment example mount -v /dev/sdb1 /mnt/b then you could look inside /mnt/b and see what files are there.

If there's really no files then it appears the drive was reformatted (probably by Easeus partition master? FYI the partition type should make no difference to what size files can be written, only the filesystem, and reformatting would definitely erase/lose access to all the old files) so it's not as simple as recovering the old partition info with TestDisk, recovering the whole old ext filesystem may even be impossible. I'm not sure if you could find a backup superblock and use it to "fix" the ext again...

Before doing more writing (attempted fixes) some files might still be on the old disk (as long as Easeus didn't overwrite everything) so recovering a few might be possible with PhotoRec. Here's it's Step-By-Step Guide - your biggest question should be the original filesystem, if it was ext then pick ext, otherwise the only option is "other". If you recover no files with one method, there's nothing to lose by trying the other.

Answer 2

If /dev/sdb1 used to be a Linux ext2/3/4 partition, it's not any more. It looks like a "Microsoft Data Partition"... hence fsck is failing to find an ext2/3/4 partition. If it was NTFS, you can't use fsck on it. You'll have to use chkdsk from Windows.

It looks like you dual-boot with Windows 10. Have you recently done some major updates in Windows 10? If so, that may have wiped your /dev/sdb1 partition, esp if /dev/sdb is in MBR partition table format. This is a Microsoft "bug". If this happened, recovery can be done using testdisk. After booting to a Ubuntu Live DVD/USB, install testdisk, and see here for the procedure.

Otherwise, did you install a Windows driver to allow you to read/write to Linux ext2/3/4 partitions. If so, that probably corrupted your partition. Uninstall the driver asap.

Otherwise, did you accidentally format /dev/sdb1?

Update #1:

The user was "...using Easeus partition master to change partition table from MBR to GPT" and cancelled it whilst in process. Bad idea. I hope that you made a backup first. Then they tried to use testdisk to resurrect the partition. More bad idea. The disk is toast, and will require re-init with GPT partition table, then partition it, or reinstall Ubuntu.