Fixing partially unallocated partition after gparted crash

Question

Earlier today I was trying to shrink and move a partition when gparted totally froze. (not the main os partition) After waiting about 4 hours I force shutdown my computer. Now when I look at the partition in gparted it looks like this and this. As you can see, some part within the partition space is apparently unallocated. I can't mount, shrink, move or otherwise change the partition. Checking it with gparted throws an error. What can I do? (/dev/nvme0n1p8 is the affected partition)

EDIT: e2fsck:

sudo e2fsck /dev/nvme0n1p8
e2fsck 1.43.4 (31-Jan-2017)
/dev/nvme0n1p8 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Missing '.' in directory inode 510513.
Fix<y>? yes
Setting filetype for entry '.' in ??? (510513) to 2.
Missing '..' in directory inode 510513.
Fix<y>? yes to all
Setting filetype for entry '..' in ??? (510513) to 2.
Entry 'S3J5cHRpYy50dGY=.png' in ??? (510513) has deleted/unused inode 6166343.  Clear? yes

Entry 'RnJlaWdodFRleHQgTGlnaHRTQy50dGY=.png' in ??? (510513) references inode 6167543 found in group 752's unused inodes area.
Fix? yes

ext2fs_read_inode: Inode checksum does not match inode while reading inode 6167543 in check_filetype

/dev/nvme0n1p8: ***** FILE SYSTEM WAS MODIFIED *****
e2fsck: aborted

/dev/nvme0n1p8: ***** FILE SYSTEM WAS MODIFIED *****

EDIT fdisk -l (/dev/nvme0n1p8 is the affected partition)

ubuntu-gnome@ubuntu-gnome:~$ sudo fdisk -l 
Disk /dev/loop0: 1.4 GiB, 1462083584 bytes, 2855632 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 
Disk /dev/nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 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: 03DB32A6-DAC5-46B5-8138-C9F14617A1FB

Device             Start        End   Sectors   Size Type
/dev/nvme0n1p1      2048    1026047   1024000   500M EFI System
/dev/nvme0n1p2   1026048    1288191    262144   128M Microsoft reserved
/dev/nvme0n1p3   1288192   46344191  45056000  21.5G Linux swap
/dev/nvme0n1p4 971556864  972503039    946176   462M Windows recovery environmen
/dev/nvme0n1p5 972503040  997814271  25311232  12.1G Windows recovery environmen
/dev/nvme0n1p6 997816320 1000214527   2398208   1.1G Windows recovery environmen
/dev/nvme0n1p7  46344192  513597439 467253248 222.8G Linux filesystem
/dev/nvme0n1p8 513597440  971556863 457959424 218.4G Linux filesystem

Partition table entries are not in disk order.


Disk /dev/sda: 1.9 GiB, 2003828736 bytes, 3913728 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: dos
Disk identifier: 0x782a20f2

Device     Boot Start     End Sectors  Size Id Type
/dev/sda1  *        0 2964415 2964416  1.4G  0 Empty
/dev/sda2       84608   89215    4608  2.3M ef EFI (FAT-12/16/32)

sudo df

Filesystem     1K-blocks    Used Available Use% Mounted on
udev             8108160       0   8108160   0% /dev
tmpfs            1624936   10352   1614584   1% /run
/dev/sda         1482208 1482208         0 100% /cdrom
/dev/loop0       1427840 1427840         0 100% /rofs
aufs             8124668  209576   7915092   3% /
tmpfs            8124668   84140   8040528   2% /dev/shm
tmpfs               5120       4      5116   1% /run/lock
tmpfs            8124668       0   8124668   0% /sys/fs/cgroup
tmpfs            8124668       0   8124668   0% /tmp
tmpfs            1624932      60   1624872   1% /run/user/999

sudo mount -a produces no output

Answer 1

First, your partition appears to be fine; it's the filesystem it contains that's damaged.

A partition is defined by a start point and either an end point or a length, depending on the partition table type, along with some ancillary data like a partition type code. Partition tables are very simple data structures, and you've presented no evidence that yours is damaged.

Filesystems, on the other hand, are much more complex data structures that reside within partitions. That is, a partition provides a pointer to the start of a filesystem data structure, and the filesystem does much more interesting things, like enabling a computer to locate individual files and directories. They're rather delicate and very complex. The vast majority of the time spent in "resizing a partition" or "moving a partition" is actually spent adjusting filesystem data structures, not partition data structures.

I'm making a big deal about this distinction because a lack of understanding about it can lead you on a wild goose chase. In particular, the only way a partitioning tool like gdisk or (mostly) TestDisk might help would be if your filesystem is mostly intact but the partition start point is wrong. In this case, TestDisk might be able to locate the correct start point and build a new partition around it. This seems unlikely, though -- your output indicates that e2fsck has identified a filesystem but is having difficulty fixing it. If you were moving the start point of the partition, this means that either the filesystem's starting data structures were moved, but the job was incomplete or botched; or the operation hadn't yet gotten around to moving the start point of the partition. Either way, the filesystem's data structures are damaged, and even if you could locate the old start point, it wouldn't help. Thus, you're looking at a filesystem-level repair, using the start point identified by the partition table as it is now. The only way a bad partition start point would make sense in your case is if the current partition start point is referring to an old filesystem -- either something from a previous partition or the original partition you were trying to shrink, but GParted has moved the filesystem's start point but not adjusted the partition's start point. These scenarios are both possible but unlikely. If one of them is correct, then TestDisk might find the correct filesystem start point. This is a long shot. It might be worth trying, but I wouldn't hold out much hope for success.

If, OTOH, the partition points to the current and correct filesystem start point, then the filesystem is simply badly damaged. In this case, I recommend you first try to copy off any important user data you can. If the partition will mount in read-only mode, you might be able to copy off the data it holds. If you get enough data, you could then unmount the filesystem, create a fresh filesystem in the partition (or a new one of the desired location and size), and copy your data back.

If the partition won't mount at all, then some advanced recovery tools might help. These include:

• TestDisk -- This tool is generally used to locate filesystems and create new partitions around them, but IIRC, it also has a mode that enables browsing filesystems for files. It's conceivable this would find something. I know relatively little about this functionality, though, so I can't provide more details on how to use it.
• PhotoRec -- This tool enables you to recover individual files from a badly damaged filesystem. The last I checked, though, it didn't do a good job of recovering filenames or directory structures, so you'll be left sifting through a lot of files.
• debugfs -- This is an advanced ext2/3/4fs forensics tool that might enable you to recover something.
• e2fsck -- You've already tried this tool, but it has advanced options that might help with recovery.

I don't have much advice on the last two options. I'm sure there are online tutorials to help with them, but I don't have any specific sites in mind, so your Web search is as good as mine. If the automatic e2fsck options fail, as they have for you, then you're deep into expert filesystem recovery territory.

Another option is to employ a professional data recovery service. This is likely to be expensive, but if your partition held important data, it might be worth the cost.

Whatever you do, don't try to write to the disk without a backup! Anything you do at this point could make the situation worse than it already is, so before you try using e2fsck, TestDisk, or anything else that will write to the disk, it's imperative that you use dd to make a raw backup of the partition (and perhaps areas outside of the partition, if you were shrinking it by moving its start point to the right and the partition table shows the new start point). Note that dd is itself risky, so be sure to enter the correct input (if=) and output (of=) options!

Good luck with your recovery efforts!