How do I get Windows 11 to use existing Linux GPT on 6TB external HDD?

Question

My goal is to access NTFS partitions on a 6TB external HDD in Windows 11 that already has a valid GPT created in Linux. The problem is Windows 11 mounts the drive using MBR.

both Windows Disk Management and the utility I'm using called Disk Genius sees the HDD as MBR

I attempted to convert the MBR to GPT and it looks like it's trying to create a whole new GPT as Disk Genius reports no space to create GPT:

Before I go any further, can I simply make Windows 11 read and use the existing GPT that Linux created?

I've read a lot of articles on converting MBR to GPT and realize this is not what I want to do - I just want to use what already exists. I don't need to create a new GPT.

For completeness, here is what the GPT looks like in Linux (the 120GB partition I want to use in Windows 11 is /dev/sdc14):

# fdisk -l /dev/sdc
Disk /dev/sdc: 5.46 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: USB 3.0 Destop H
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 4FBB78E0-201B-4A5B-A745-C0E797DF98D9

Device           Start         End    Sectors   Size Type
/dev/sdc1         2048     2099199    2097152     1G EFI System
/dev/sdc2      2099200    63326207   61227008  29.2G Linux filesystem
/dev/sdc3    105269248   149309439   44040192    21G Linux filesystem
/dev/sdc4    168183808   210126847   41943040    20G Linux filesystem
/dev/sdc5     63326208   105269247   41943040    20G Linux filesystem
/dev/sdc6    449202176   465979391   16777216     8G Microsoft basic data
/dev/sdc7    465979392  5860855807 5394876416   2.5T Linux filesystem
/dev/sdc8   5860855808  5860857855       2048     1M Microsoft basic data
/dev/sdc9   5860858456  5938983447   78124992  37.3G Apple APFS
/dev/sdc10  5939245592  9767921663 3828676072   1.8T Apple HFS/HFS+
/dev/sdc11  9768183808 10002558807  234375000 111.8G Apple APFS
/dev/sdc12 10002558808 10393183807  390625000 186.3G Apple APFS
/dev/sdc13 10393184256 11064272895  671088640   320G Linux filesystem
/dev/sdc14 11064272896 11315931135  251658240   120G Microsoft basic data

here is the MBR of the same disk:

# fdisk -t dos -l /dev/sdc
Disk /dev/sdc: 5.46 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: USB 3.0 Destop H
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x8a9e2113

Device     Boot     Start       End  Sectors  Size Id Type
/dev/sdc1               1   2099199  2099199    1G ee GPT
/dev/sdc2  *      2099200  63326207 61227008 29.2G 83 Linux
/dev/sdc3       105269248 149309439 44040192   21G 83 Linux
/dev/sdc4       168183808 210126847 41943040   20G da Non-FS data

Partition 1 does not start on physical sector boundary.

Answer 1

Every GPT disk also has an MBR partition table, for compatibility reasons, although normally the MBR of such a disk is supposed to have only a single "GPT protective" partition (type code 0xEE) that covers the entire disk – or as much of the disk as a MBR can cover, anyway – and just tells old software that the disk is non-empty; a modern OS would ignore it and only look at the GPT.

But your disk seems to have "hybrid" partitioning where both partition tables have valid (and conflicting) information – quite strangely, the protective partition is present but has been shrunk to add stuff alongside it – so it's very possible that both Windows and Disk Genius prioritize the MBR over the GPT in such situations.

(Upon a closer look, it seems that the MBR is an old copy of the GPT with only the first four partitions present, and the strange protective partition stands in for the EFI system partition. Either somebody got the partition type wrong – an ESP would be type 0xEF, not 0xEE – or deliberately wanted to disguise the ESP so that the firmware would ignore it?)

Converting this MBR to GPT would be the opposite of what you want, since it would replace your valid GPT partitions with useless ones converted from the outdated MBR, so it's fortunate that it did not succeed. (Although you could recover them by hand from the list in your post.)

Instead, since the MBR currently has useless information, you should replace it with a standard "protective" MBR. The easiest way to do this is with the gdisk (aka "gptfdisk") tool from Linux:

1. gdisk /dev/sdc;
2. Main menu: x to enter the "Expert" menu;
3. Expert menu: (optional) o to take a look at the current MBR;
4. Expert menu: n to generate a new protective MBR;
5. Expert menu: (optional) o to take a look at the newly generated MBR;
6. Expert menu: (optional) p to make sure the GPT hasn't gone anywhere;
7. Expert menu: w to write the new partition tables to disk.

(This could be achieved with fdisk, but would take more steps and need more care.)

The end result should look exactly like this – i.e. only one partition that is as large as possible:

# fdisk -t dos -l
Device     Boot Start        End    Sectors Size Id Type
/dev/sdc1           1 4294967295 4294967295   2T ee GPT
#