Apple - How to fix Mac hard drive partition showing as FDisk_partition_scheme
Please try the following:
Get the disk identifier of your external 3 TB drive
diskutil list
Below I assume the disk identifier is disk6
unmount the disk:
diskutil umountDisk disk6
Overwrite the first 40 blocks:
sudo dd if=/dev/zero of=/dev/disk6 bs=512 count=40
Create a new gpt:
sudo gpt create /dev/disk6
Check the disk info with:
diskutil info /dev/disk6
Reassure yourself that the device block size still is 512 Bytes
You may also use
sudo gpt -r show /dev/disk6
If the gpt shows:
start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table
you have a disk & disk controller which report a logical block size of 512 Bytes. Please continue with the next step.
If the gpt shows:
start size index contents 0 1 PMBR 1 1 Pri GPT header 2 4 Pri GPT table
you have a disk & disk controller which report a logical block size of 4096 Bytes. Please stop here and add a comment.
First rebuild the EFI entry with:
sudo gpt add -b 40 -i 1 -s 614400 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk6
Depending on the size of the disk and the system version differently sized EFI volumes are built if partitioned with Disk Utility: either one with the size 200 MiB or one with 300 MiB. Here it's obvious that your disk contains a 300 MiB EFI and probably 4096 bytes of unallocated disk space: (314598400-1024)/512=614448 (=Start block main volume) 614448-40-8=614400 (=size of EFI)
Rebuild your main volume with:
sudo gpt add -b 614448 -i 2 -s SizeOfVolume1 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
The size of the main volume can be determined by the first (corrupted & old) entry of the second GPT table: (3000592961536/512)=5860533128 is its block number. Then the size is calculated by 5860533128-614448=5859918680 blocks. Since 5859918680 is dividable by 8 (4096 physical block size/512 logical block size) this is a good guess for the volume size.
The best guess is finally:
sudo gpt add -b 614448 -i 2 -s 5859918680 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
The second best guess is:
sudo gpt add -b 614448 -i 2 -s 5859918672 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
Probably your lost volume gets mounted now. Verify the volume with:
diskutil verifyVolume disk6s2
If necessary try to repair the volume.
diskutil repairVolume disk6s2
Since you moved the "corrupted" disk to a different case and disk controller the logical block size was modified. The old partition map is probably based on a logical block size of 4096 Bytes.
To recover the partition map in the old (4096b) case you would had to enter the following to restore the GPT (based on David Anderson's answer):
Create a new gpt:
sudo gpt create /dev/disk6
First rebuild the EFI entry with:
sudo gpt add -b 6 -i 1 -s 76800 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk6
Rebuild your main volume with:
sudo gpt add -b 76806 -i 2 -s 732457067 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
the final partition map looks like this:
sudo gpt -r show disk1 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 4 Pri GPT table 6 76800 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B 76806 732457067 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC 732533873 32768 732566641 4 Sec GPT table 732566645 1 Sec GPT header
Based on the 4096b part this "retranslates" after installing the disk in a 512b logical block size case to:
Create a new gpt:
sudo gpt create /dev/disk6
First rebuild the EFI entry with:
sudo gpt add -b 48 -i 1 -s 614400 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk6
Rebuild your main volume with:
sudo gpt add -b 614448 -i 2 -s 5859656536 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
This differs from the first (accepted) part of my answer but is the proper one! Since the EFI actually is "empty" and the 262144 unallocated blocks contain zeros only, the "first and somehow wrong" answer doesn't affect the operability of the volume.
This is not an answer, but rather an example of how to extract the GPT partition information from the data you presented. The secondary (backup) GPT partition entries were used because you did not post the contents of the primary GPT partition entries. The document "GUID Partition Table" was used to interpret the data.
Last usable LBA can be found in the GPT header. This occurs at address 8244. The value is
70 14 aa 2b 00 00 00 00 little endian = 0x2baa1470 = 732566640 @ 4096 bytes/block.
The start of the secondary (backup) GPT entries start at the next block. The value is
(732566640 + 1) * 4096 = 3000592961536 bytes.
Using this as the start of the EFI partition table entry, I get the following values. Start of EFI partition, found at address 3000592961568, is
06 00 00 00 00 00 00 00 little endian = 0x6 = 6 @ 4096 bytes/block.
End of EFI partition, found at address 3000592961576, is
05 2c 01 00 00 00 00 00 little endian = 0x12c05 = 76805 @ 4096 bytes/block.
Which gives a partition size of
76805 - 6 + 1 = 76800 @ 4096 bytes/block.
Start of HFS partition, found at address 3000592961696, is
06 2c 01 00 00 00 00 00 little endian = 0x12c06 = 76806 @ 4096 bytes/block.
End of HFS partition, found at address 3000592961704, is
70 94 a9 2b 00 00 00 00 little endian = 0x2ba99470 = 732533872 @ 4096 bytes/block.
Which gives a partition size of
732533872 - 76806 + 1 = 732457067 @ 4096 bytes / block.
If you are going to use a block size of 512 bytes, the above results will have to be multiplied by a value of 8 to convert to 512 bytes/block.