How do I get Windows 11 to use existing Linux GPT on 6TB external HDD?
Jul 11
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.
linux
1 answer
Accepted answer · original discussion
Jul 11
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:
gdisk /dev/sdc;- Main menu:
xto enter the "Expert" menu; - Expert menu: (optional)
oto take a look at the current MBR; - Expert menu:
nto generate a new protective MBR; - Expert menu: (optional)
oto take a look at the newly generated MBR; - Expert menu: (optional)
pto make sure the GPT hasn't gone anywhere; - Expert menu:
wto 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
#
0 question comments
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.