Partition corruption after resizing with GParted – Need help recovering my Linux KDE Neon (nvme0n1p4)

[NitramO]

Context
I originally posted this issue on the KDE forum (link), and I was advised to seek help here, as TestDisk might be useful in recovering my data.

I had a dual boot setup with Windows 10 and Linux KDE Neon 5, where GRUB was installed on the old KDE partition (/dev/nvme0n1p4) and used to boot all my OSes.

A few months ago, KDE Neon 5 became outdated and could no longer be updated properly, so I installed KDE Neon 6 on a new partition while keeping the old KDE Neon 5.
However, I never reconfigured GRUB, so I continued using the GRUB from the old KDE installation to boot both my new KDE Neon 6 and Windows 10.

Even though I stopped using KDE Neon 5 as my main OS, I kept it because it still contained important files that I hadn’t fully migrated yet.

What caused the problem
I initially tried to run my Windows 10 installation inside a VM using KVM/Passthrough, but I couldn’t get it to work properly.
Since that failed, I thought about installing Windows 11 on a new partition instead.

To do that, I decided to shrink the partition of my old KDE (nvme0n1p4) using GParted to free up space for the new installation.

Steps taken:
- Booted into RescueZilla (Live USB)
- Launched GParted and started resizing nvme0n1p4
- GParted crashed during the process, and the partition became corrupted

Since then, the partition /dev/nvme0n1p4 is inaccessible, and because GRUB was installed on that partition, I could no longer boot into Linux—the PC booted directly into Windows 10.

By selecting my KDE Neon 6 installation from the boot menu, I ended up in a minimal GRUB shell.
I managed to manually boot into KDE Neon 6 using GRUB commands, and once inside my Linux system, I reinstalled GRUB properly for KDE Neon 6 so that I could boot normally again.

Current Situation
- /dev/nvme0n1p4 is still detected by GParted and TestDisk
- Total partition size and used space are displayed correctly
- An unallocated space appears, matching the amount I attempted to shrink before the crash
- Some areas of the file system are readable, but others still show I/O errors
- fsck and e2fsck fixed some errors but not all
- GRUB for KDE Neon 6 has been reinstalled and is now working

Recovery Attempts So Far

1. Checking the partition in GParted (from RescueZilla)
From RescueZilla, I opened GParted to inspect the partition status:
- The partition /dev/nvme0n1p4 is still detected
- The total partition size and used space are correctly displayed
- There is unallocated space, which matches the amount I attempted to shrink before the crash

2. Repair attempts with fsck and e2fsck
First attempt with fsck:

Code: Select all

sudo fsck /dev/nvme0n1p4

- It detected a massive number of errors and asked for manual confirmation ("o") to fix each one.
- I pressed "o" repeatedly, but there were still many more errors left to fix.

Attempt with e2fsck (automatic mode):

Code: Select all

sudo e2fsck -y /dev/nvme0n1p4

- It automatically fixed many errors without requiring manual confirmation.
- However, some critical errors remained unresolved.

Another attempt with different parameters:

Code: Select all

sudo e2fsck -f -y /dev/nvme0n1p4

- Some errors were fixed, but others persisted, including corrupted inodes, unreadable blocks, and file system inconsistencies.

Example errors encountered:

Code: Select all

  
Inode 102614 has an invalid checksum.  
Fix? yes  
Inode 203487 is in use, but has dtime set.  
Fix? yes  

Some issues were resolved, but not all.

3. Attempt with TestDisk
I then tried TestDisk to see if I could recover the partition:

Code: Select all

sudo testdisk

- It detected the /dev/nvme0n1p4 partition
- It reported corrupted blocks and overlapping file system structures
- It suggested rebuilding the partition table, but I wasn’t sure about the correct approach
- A deep scan correctly identified the partition with the right size, but I wasn’t sure which recovery option to choose safely.

4. Using find-overlap.py and dd to recover the partition
I found a script on GitHub that helps identify corrupted areas in a partition after a failed resize operation:
GitHub - find-overlap.py

The script generated several dd commands to attempt recovery.

Example of the generated commands and their execution:

First dd command (successful copy of 179GB):

Code: Select all

sudo dd if=/dev/nvme0n1p4 bs=1048576 count=171032 of=/dev/nvme0n1p4

Second dd command (I/O error while copying 140GB):

Code: Select all

sudo dd if=/dev/nvme0n1p4 bs=1048576 skip=171039 seek=171032 of=/dev/nvme0n1p4

Result:

Code: Select all

dd: error reading '/dev/nvme0n1p4': Input/output error

Some areas were restored, but others remain corrupted.

What I Need Help With
- Can TestDisk help restore this partition safely? If so, what’s the best method for this specific case?
- Should I retry some dd commands or use ddrescue instead to recover the remaining corrupted areas?
- Are there any other tools or approaches I could use to retrieve the existing files from the partition?
- Could the corruption of this partition pose a risk to my other partitions? (I want to make sure nothing else is affected.)

I know that ideally, I should have worked on a cloned drive, but unfortunately, I didn’t have another large enough disk available at the time.
I’ve learned my lesson, and in the future, I’ll make sure to always work on a backup first.

That said, any help to recover as much data as possible from this partition would be greatly appreciated.

Thanks in advance for any help.

[recuperation]

Context
I originally posted this issue on the KDE forum (link), and I was advised to seek help here, as TestDisk might be useful in recovering my data.

I had a dual boot setup with Windows 10 and Linux KDE Neon 5, where GRUB was installed on the old KDE partition (/dev/nvme0n1p4) and used to boot all my OSes.

A few months ago, KDE Neon 5 became outdated and could no longer be updated properly, so I installed KDE Neon 6 on a new partition while keeping the old KDE Neon 5.
However, I never reconfigured GRUB, so I continued using the GRUB from the old KDE installation to boot both my new KDE Neon 6 and Windows 10.

Even though I stopped using KDE Neon 5 as my main OS, I kept it because it still contained important files that I hadn’t fully migrated yet.

What caused the problem
I initially tried to run my Windows 10 installation inside a VM using KVM/Passthrough, but I couldn’t get it to work properly.
Since that failed, I thought about installing Windows 11 on a new partition instead.

To do that, I decided to shrink the partition of my old KDE (nvme0n1p4) using GParted to free up space for the new installation.

Steps taken:
- Booted into RescueZilla (Live USB)
- Launched GParted and started resizing nvme0n1p4
- GParted crashed during the process, and the partition became corrupted

Since then, the partition /dev/nvme0n1p4 is inaccessible, and because GRUB was installed on that partition, I could no longer boot into Linux—the PC booted directly into Windows 10.

By selecting my KDE Neon 6 installation from the boot menu, I ended up in a minimal GRUB shell.
I managed to manually boot into KDE Neon 6 using GRUB commands, and once inside my Linux system, I reinstalled GRUB properly for KDE Neon 6 so that I could boot normally again.

Current Situation
- /dev/nvme0n1p4 is still detected by GParted and TestDisk
- Total partition size and used space are displayed correctly

Fitting to the old or the new partition size? Please post your TestDisk log file.

- An unallocated space appears, matching the amount I attempted to shrink before the crash
- Some areas of the file system are readable, but others still show I/O errors

How did you come to that conclusion with regards to broken "areas"?

- fsck and e2fsck fixed some errors but not all
- GRUB for KDE Neon 6 has been reinstalled and is now working

Recovery Attempts So Far

1. Checking the partition in GParted (from RescueZilla)
From RescueZilla, I opened GParted to inspect the partition status:
- The partition /dev/nvme0n1p4 is still detected
- The total partition size and used space are correctly displayed

See my question above.

- There is unallocated space, which matches the amount I attempted to shrink before the crash

2. Repair attempts with fsck and e2fsck
First attempt with fsck:

Code: Select all

sudo fsck /dev/nvme0n1p4

- It detected a massive number of errors and asked for manual confirmation ("o") to fix each one.
- I pressed "o" repeatedly, but there were still many more errors left to fix.

Attempt with e2fsck (automatic mode):

Code: Select all

sudo e2fsck -y /dev/nvme0n1p4

- It automatically fixed many errors without requiring manual confirmation.
- However, some critical errors remained unresolved.

Another attempt with different parameters:

Code: Select all

sudo e2fsck -f -y /dev/nvme0n1p4

- Some errors were fixed, but others persisted, including corrupted inodes, unreadable blocks, and file system inconsistencies.

Example errors encountered:

Code: Select all

  
Inode 102614 has an invalid checksum.  
Fix? yes  
Inode 203487 is in use, but has dtime set.  
Fix? yes  

Some issues were resolved, but not all.

3. Attempt with TestDisk
I then tried TestDisk to see if I could recover the partition:

Code: Select all

sudo testdisk

- It detected the /dev/nvme0n1p4 partition
- It reported corrupted blocks and overlapping file system structures
- It suggested rebuilding the partition table, but I wasn’t sure about the correct approach
- A deep scan correctly identified the partition with the right size, but I wasn’t sure which recovery option to choose safely.

4. Using find-overlap.py and dd to recover the partition
I found a script on GitHub that helps identify corrupted areas in a partition after a failed resize operation:
GitHub - find-overlap.py

The script generated several dd commands to attempt recovery.

Example of the generated commands and their execution:

First dd command (successful copy of 179GB):

Code: Select all

sudo dd if=/dev/nvme0n1p4 bs=1048576 count=171032 of=/dev/nvme0n1p4

This command copies a 171032 * 1048576 sectors at the beginning of nvme01n1p4 onto itself - makes no sense.

Second dd command (I/O error while copying 140GB):

Code: Select all

sudo dd if=/dev/nvme0n1p4 bs=1048576 skip=171039 seek=171032 of=/dev/nvme0n1p4

Result:

Code: Select all

dd: error reading '/dev/nvme0n1p4': Input/output error

I a not sure if this comes from touching the end of the partition or from an unreadable block.

Some areas were restored, but others remain corrupted.

What I Need Help With
- Can TestDisk help restore this partition safely? If so, what’s the best method for this specific case?

No. Now there are two possible partition sizes, the big one before attempting to shrink and the small shrinked one.
Based on your information it is unclear at what stage Gparted crashed.

- Should I retry some dd commands or use ddrescue instead to recover the remaining corrupted areas?

If there is any doubt that physical dammage may exist, ddrescue is to be preferred for recovery. Recovery does not mean data manipulation on the broken nvme disk.

- Are there any other tools or approaches I could use to retrieve the existing files from the partition?

When in doubt about phsical dammage (the interrupted shrinkage operation is supposed only to cause logical dammage), check SMART data:
viewtopic.php?f=5&t=10910

I have no experience though with the smartmontools log file when it contains data for a NVME disk.
Depending on the outcome of the report of smartmontools, use ddrescue to clone the whole NVME device or just the partition if you can afford to loose the rest.
If there is doubt or proof with regards to the health of the NVME disk, clone the clone to have a recoverable playground for your rescue attempts.

- Could the corruption of this partition pose a risk to my other partitions? (I want to make sure nothing else is affected.)
If the corruption of your partition is logical, no, if there are physical issues, yes.

You can use TestDisk to include the old or the new partition into the partition table depending on what TestDisk finds, but you can use TestDisk as well to try to look into the partition hopefully finding a familiar file and folder structure and copy everything to another disk.
You could try out other recovery software that understands the ext4 file sytem, and finally, as means of last resort you have PhotoRec.
When running Photorec you should run it against the big old partition. That requires either writing the partition to the partition table or mounting an image file containing the content of your broken partition or creating a virtual device pointing to the big old partition on your NVME disk. If I remember correctly, I once found an example on superuser.com that showed how losetup can point to an area within a device that is not a partition.

Using the big old partition most likely produces two files for every file that Gparted moved to the beginning of the partition. While this seems to be disturbing, it increases the chance of recovering an unfragmented, healthy version of the moved files.

P.S.:
I have not seen such as well documented case as yours for months.

[NitramO]

Context
I originally posted this issue on the KDE forum (link), and I was advised to seek help here, as TestDisk might be useful in recovering my data.

I had a dual boot setup with Windows 10 and Linux KDE Neon 5, where GRUB was installed on the old KDE partition (/dev/nvme0n1p4) and used to boot all my OSes.

A few months ago, KDE Neon 5 became outdated and could no longer be updated properly, so I installed KDE Neon 6 on a new partition while keeping the old KDE Neon 5.
However, I never reconfigured GRUB, so I continued using the GRUB from the old KDE installation to boot both my new KDE Neon 6 and Windows 10.

Even though I stopped using KDE Neon 5 as my main OS, I kept it because it still contained important files that I hadn’t fully migrated yet.

What caused the problem
I initially tried to run my Windows 10 installation inside a VM using KVM/Passthrough, but I couldn’t get it to work properly.
Since that failed, I thought about installing Windows 11 on a new partition instead.

To do that, I decided to shrink the partition of my old KDE (nvme0n1p4) using GParted to free up space for the new installation.

Steps taken:
- Booted into RescueZilla (Live USB)
- Launched GParted and started resizing nvme0n1p4
- GParted crashed during the process, and the partition became corrupted

Since then, the partition /dev/nvme0n1p4 is inaccessible, and because GRUB was installed on that partition, I could no longer boot into Linux—the PC booted directly into Windows 10.

By selecting my KDE Neon 6 installation from the boot menu, I ended up in a minimal GRUB shell.
I managed to manually boot into KDE Neon 6 using GRUB commands, and once inside my Linux system, I reinstalled GRUB properly for KDE Neon 6 so that I could boot normally again.

Current Situation
- /dev/nvme0n1p4 is still detected by GParted and TestDisk
- Total partition size and used space are displayed correctly

Fitting to the old or the new partition size? Please post your TestDisk log file.

Hello recuperation,

Thank you for your thorough reply and for pointing out the questions regarding the old vs. new partition size. I wanted to clarify exactly what happened when GParted crashed:

I was in the middle of resizing `/dev/nvme0n1p4` (attempting to shrink it) when GParted unexpectedly froze with that “window clone cascading” effect. It crashed completely before I could save any logs. Because of that failed resize, the partition now appears in two segments:

- One segment that matches the smaller size I aimed for (shown as allocated),
- and another segment that GParted calls “unallocated,” but it’s actually still part of the same original space of `/dev/nvme0n1p4`.

Additionally, there’s a larger unallocated chunk on the right (238.09 GiB) which came from shrinking my Windows partition (`/dev/nvme0n1p3`). I had moved `/dev/nvme0n1p4` to the left to keep the free space contiguous—GParted evidently finished the move, but crashed during the final resizing steps.

Unfortunately, I don’t have the TestDisk logs from just after the crash (I used a Live USB and rebooted). If re-running TestDisk and sharing fresh logs is useful, let me know which steps or options you need so I don’t risk overwriting anything important.

- An unallocated space appears, matching the amount I attempted to shrink before the crash
- Some areas of the file system are readable, but others still show I/O errors

How did you come to that conclusion with regards to broken "areas"?

I observed “broken areas” when `dd` commands generated by `find-overlap.py` hit Input/Output errors partway through copying. Plus, `fsck` and `e2fsck` repeatedly report inode corruption that never fully resolves.

- fsck and e2fsck fixed some errors but not all
- GRUB for KDE Neon 6 has been reinstalled and is now working

Recovery Attempts So Far

1. Checking the partition in GParted (from RescueZilla)
From RescueZilla, I opened GParted to inspect the partition status:
- The partition /dev/nvme0n1p4 is still detected
- The total partition size and used space are correctly displayed

See my question above.

Below are the unabridged fsck/e2fsck outputs (translated from French but keeping the same structure). Each time, e2fsck modifies something, then aborts:

Code: Select all

martin@martin-pulse17b13vfk:~$ sudo fsck /dev/nvme0n1p4 -y
fsck from util-linux 2.39.3
e2fsck 1.47.0 (5-Feb-2023)
/dev/nvme0n1p4: recovering journal
/dev/nvme0n1p4 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory inode 102614, block #1, offset 0: corrupted directory
Recover? yes

Entry “M-\k^NM-Pu&M-rM-;M-L^RM-^R…” in ??? (102614) references inode 7632710 found in the unused inode area group 931.
Fix? yes

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

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

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

Code: Select all

martin@martin-pulse17b13vfk:~$ sudo e2fsck -y /dev/nvme0n1p4
e2fsck 1.47.0 (5-Feb-2023)
/dev/nvme0n1p4: recovering journal
/dev/nvme0n1p4 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory inode 102614, block #1, offset 0: corrupted directory
Recover? yes

Entry “M-\k^NM-Pu&M-rM-;M-L^RM-^R…” in ??? (102614) references inode 7632710 found in the unused inode area group 931.
Fix? yes

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

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

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

Code: Select all

martin@martin-pulse17b13vfk:~$ sudo e2fsck -f -y /dev/nvme0n1p4
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory inode 102614, block #1, offset 0: corrupted directory
Recover? yes

Entry “M-\k^NM-Pu&M-rM-;M-L^RM-^R…” in ??? (102614) references inode 7632710 found in the unused inode area group 931.
Fix? yes

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

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

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

3. Attempt with TestDisk
I then tried TestDisk to see if I could recover the partition...

I did run TestDisk once. It detected `/dev/nvme0n1p4` but said it saw overlapping or corrupted file system structures. It mentioned possibly rebuilding the partition table, though I don’t recall the exact steps. I’d be happy to re-run it carefully if you have specific instructions or a recommended approach (especially regarding whether to restore the “old” or “new” partition size).

This command copies a 171032 * 1048576 sectors at the beginning of nvme01n1p4 onto itself - makes no sense.

Yes, the `find-overlap.py` script generated multiple `dd` commands that copy different blocks within `/dev/nvme0n1p4` onto itself. One succeeded for ~179 GB, another gave an I/O error after ~140 GB, at which point I stopped.

- Should I retry some dd commands or use ddrescue instead...

If there is any doubt that physical dammage may exist, ddrescue is to be preferred...

I ran `smartctl -a /dev/nvme0n1`, which reported no hardware issues. Here’s the full output:

Code: Select all

martin@martin-pulse17b13vfk:~$ sudo smartctl -a /dev/nvme0n1
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.11.0-17-generic] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 990 PRO 4TB
Serial Number:                      S7DPNJ0X130771D
Firmware Version:                   4B2QJXD7
PCI Vendor/Subsystem ID:            0x144d
IEEE OUI Identifier:                0x002538
Total NVM Capacity:                 4000787030016 [4.00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      1
NVMe Version:                       2.0
Number of Namespaces:               1
Namespace 1 Size/Capacity:          4000787030016 [4.00 TB]
Namespace 1 Utilization:            3289295740928 [3.28 TB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            002538 414142ead7
Local Time is:                      Wed Feb 26 18:54:58 2025 CET
Firmware Updates (0x16):            3 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x0055):     Comp DS_Mngmt Sav/Sel_Feat Timestmp
Log Page Attributes (0x2f):         S/H_per_NS Cmd_Eff_Lg Ext_Get_Lg Telmtry_Lg Log0_FISE_MI
Maximum Data Transfer Size:         512 Pages
Warning  Comp. Temp. Threshold:     82 Celsius
Critical Comp. Temp. Threshold:     85 Celsius

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     9.39W       -        -    0  0  0  0        0       0
 1 +     9.39W       -        -    1  1  1  1        0       0
 2 +     9.39W       -        -    2  2  2  2        0       0
 3 -   0.0400W       -        -    3  3  3  3     4200    2700
 4 -   0.0050W       -        -    4  4  4  4      500   21800

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         0

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        37 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    86373966 [44.2 TB]
Data Units Written:                 38167397 [19.5 TB]
Host Read Commands:                 683412656
Host Write Commands:                648478067
Controller Busy Time:               3426
Power Cycles:                       47
Power On Hours:                     2816
Unsafe Shutdowns:                   32
Media and Data Integrity Errors:    0
Error Information Log Entries:      3
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               37 Celsius
Temperature Sensor 2:               38 Celsius
Thermal Temp. 1 Transition Count:   1
Thermal Temp. 1 Total Time:         50

Error Information (NVMe Log 0x01, 16 of 64 entries)
No Errors Logged

Read Self-test Log failed: Invalid Field in Command (0x002)

All signs point to purely logical damage, not hardware failure.

- Could the corruption of this partition pose a risk to my other partitions? (I want to make sure nothing else is affected.)

If the corruption of your partition is logical, no, if there are physical issues, yes.
...
P.S.:
I have not seen such as well documented case as yours for months.

My other partitions—Windows (`/dev/nvme0n1p3`) and KDE Neon 6 (`/dev/nvme0n1p6`)—are still fine, and I’ve successfully reinstalled GRUB. I’d just like to see if there’s a way to salvage this half-resized partition from my old KDE Neon 5 installation and understand how best to handle such scenarios.

Finally, for reference, here is the GParted screenshot again:



- `/dev/nvme0n1p4` is shown at 417.53 GiB, with about 21.35 GiB free inside that partition and 155.29 GiB labeled as unallocated (which was supposed to be removed from the original size).
- There is also 238.09 GiB of unallocated space outside the partition, located between `/dev/nvme0n1p4` and `/dev/nvme0n1p6`, which I originally freed by shrinking Windows. Then I moved `/dev/nvme0n1p4` to the left so all the free space could be contiguous on the right. The move succeeded, but the actual shrink seems to have failed halfway.

At this point, I don’t have a 4 TB disk to clone onto. I could potentially acquire or borrow a 1 TB external drive if it’s absolutely required (for a partial clone of the old KDE partition). However, I’d prefer a solution that doesn’t force me to clone the entire disk if it can be avoided.

If you have any recommended TestDisk steps or other utilities to recover or finalize the resize safely, please let me know. I’m ready to supply whatever logs or outputs you need, as long as I know exactly which commands to run. Thanks again for your assistance!

[recuperation]

When you mentioned logs I forgot to say that you should have consulted the Gparted documentation. Maybe there had been a log created allowing GParted to continue its operation. Now it does not play any role anymore, because you manipulated your broken partition.

- There is also 238.09 GiB of unallocated space outside the partition, located between `/dev/nvme0n1p4` and `/dev/nvme0n1p6`, which I originally freed by shrinking Windows. Then I moved `/dev/nvme0n1p4` to the left so all the free space could be contiguous on the right. The move succeeded, but the actual shrink seems to have failed halfway.

You are now describing an important detail that you missed in your first description. Shrinking the partition was not the critical element of your actions. That only meant moving files from the back of the partition to the beginning and correcting a little bit of metadata. Moving the beginning of the partition to the left triggered a big block number (in NTFS this would be the cluster number) renumbering job.

If you have any recommended TestDisk steps or other utilities to recover or finalize the resize safely,

I already answered that question. Have you read it?

Read
https://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

and go through the process on a clean machine without saving anything to understand the recipe I gave to you in my first answer.

[NitramO]

Hello recuperation,

When you mentioned logs I forgot to say that you should have consulted the Gparted documentation. Maybe there had been a log created allowing GParted to continue its operation. Now it does not play any role anymore, because you manipulated your broken partition.

I looked for a log right after the crash, but the Live USB session froze and rebooted. That wiped out any existing logs, so I couldn’t retrieve them. I get now that without those logs, it’s hard to pick up from where GParted left off.

You are now describing an important detail that you missed in your first description. Shrinking the partition was not the critical element of your actions. That only meant moving files from the back of the partition to the beginning and correcting a little bit of metadata. Moving the beginning of the partition to the left triggered a big block number (in NTFS this would be the cluster number) renumbering job.

Right, thanks for pointing out that moving it left was the real issue. I focused on the resize, but I see how the big renumbering step was more critical.

I already answered that question. Have you read it?

Read
https://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

and go through the process on a clean machine without saving anything to understand the recipe I gave to you in my first answer.

I’ll go through the guide you linked and try the steps carefully. If I hit any more roadblocks, I’ll post again. Thanks for the help!