My goal is to access NTFS partitions on a 6TB external HDD in Windows 11 that **déjà** has a valid GPT créé in Linux. The problème is Windows 11 mounts the drive using MBR.
both Windows Disk Management and the utility J'utilise called Disk Genius sees the HDD as MBR
I attempted to convert the MBR to GPT and it looks like c'est trying to créez un whole nouveau GPT as Disk Genius reports no space to créer GPT:
Avant I go any further, puis-je simply make Windows 11 read and use the **existing** GPT that Linux créé?
I've read a lot of articles on converting MBR to GPT and realize c'est not what Je veux do - Je viens de want to use what déjà exists. I ne need to créez un nouveau GPT.
For completeness, ici is what the GPT looks like in Linux (the 120GB partition Je veux 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
```
ici is the MBR du 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.
```
Comment get Windows 11 to use existing Linux GPT on 6TB external HDD?
Re: Comment get Windows 11 to use existing Linux GPT on 6TB external HDD?
*Every* GPT disk également has an MBR partition table, for compatibility reasons, although normally the MBR of such a disk is supposed to have **seulement** a single "GPT protective" partition (tapez code 0xEE) that covers the entire disk – or as much du disk as a MBR can cover, anyway – and just tells old logiciel that the disk is non-empty; a modern OS would ignore it and seulement 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 a été *shrunk* to add stuff alongside it – so c'est 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 du GPT avec seulement the first four partitions present, and the strange protective partition stands in for the EFI système partition. Either somebody got the partition tapez wrong – an ESP serait tapez 0xEF, not 0xEE – or deliberately wanted to disguise the ESP so that the firmware would ignore it?)*
Converting this MBR to GPT serait the opposite of what you want, depuis it would replace your valid GPT partitions avec useless ones converted depuis le outdated MBR, so c'est fortunate that it n'a pas succeed. (Although you could recover them by hand depuis le list in your post.)
À la place, depuis the MBR actuellement has useless information, vous devriez replace it avec a standard "protective" MBR. The easiest way to do c'est avec the `gdisk` (aka "gptfdisk") tool from Linux:
- `gdisk /dev/sdc`;
- Main menu: `x` to enter the "Expert" menu;
- Expert menu: (optional) `o` to take a look at the current MBR;
- Expert menu: `n` to generate a nouveau protective MBR;
- Expert menu: (optional) `o` to take a look at the newly generated MBR;
- Expert menu: (optional) `p` to assurez-vous the GPT n'a pas gone anywhere;
- Expert menu: `w` to write the nouveau partition tables to disk.
(This pourrait être achieved avec fdisk, but would take more steps and need more care.)
The end result should look exactly like this – i.e. seulement 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
#
```
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 a été *shrunk* to add stuff alongside it – so c'est 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 du GPT avec seulement the first four partitions present, and the strange protective partition stands in for the EFI système partition. Either somebody got the partition tapez wrong – an ESP serait tapez 0xEF, not 0xEE – or deliberately wanted to disguise the ESP so that the firmware would ignore it?)*
Converting this MBR to GPT serait the opposite of what you want, depuis it would replace your valid GPT partitions avec useless ones converted depuis le outdated MBR, so c'est fortunate that it n'a pas succeed. (Although you could recover them by hand depuis le list in your post.)
À la place, depuis the MBR actuellement has useless information, vous devriez replace it avec a standard "protective" MBR. The easiest way to do c'est avec the `gdisk` (aka "gptfdisk") tool from Linux:
- `gdisk /dev/sdc`;
- Main menu: `x` to enter the "Expert" menu;
- Expert menu: (optional) `o` to take a look at the current MBR;
- Expert menu: `n` to generate a nouveau protective MBR;
- Expert menu: (optional) `o` to take a look at the newly generated MBR;
- Expert menu: (optional) `p` to assurez-vous the GPT n'a pas gone anywhere;
- Expert menu: `w` to write the nouveau partition tables to disk.
(This pourrait être achieved avec fdisk, but would take more steps and need more care.)
The end result should look exactly like this – i.e. seulement 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
#
```