How to fix Mac hard drive partition showing as FDisk_partition_scheme

Question

My situation seems very similar to how to fix GUID hard drive corrupted to MBR but with enough differences that I haven't been able to put together a confident solution.

I have a 3TB Toshiba drive in a USB enclosure being used on a Mac with OS X El Capitain 10.11.3.

The drive was set up with a single partition. The drive was not bootable and did not have a system installed so I'm assuming it would not have a recovery partition either. I can't say for sure it never had a system installed, but I don't think so. It has not been used with Bootcamp or on any non-Mac computer.

The drive worked normally for a long time but then failed to be recognized recently. On investigating with Disk Utility, it shows as having a partition type of FDisk_partition_scheme. I'm sure it was originally the typical default of GUID Partition Map formatted as OS X Extended (Journaled).

I can't think of any specific use or event that may have caused the change.

Here is the information I've collected from the drive.

diskutil list /dev/disk6

/dev/disk6 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *3.0 TB     disk6
   1:                       0xEE                         375.1 GB   disk6s1

diskutil info /dev/disk6

   Device Identifier:        disk6
   Device Node:              /dev/disk6
   Whole:                    Yes
   Part of Whole:            disk6
   Device / Media Name:      DT01ABA300

   Volume Name:              Not applicable (no file system)

   Mounted:                  Not applicable (no file system)

   File System:              None

   Content (IOContent):      FDisk_partition_scheme
   OS Can Be Installed:      No
   Media Type:               Generic
   Protocol:                 USB
   SMART Status:             Not Supported

   Total Size:               3.0 TB (3000592982016 Bytes) (exactly 5860533168 512-Byte-Units)
   Volume Free Space:        Not applicable (no file system)
   Device Block Size:        512 Bytes

   Read-Only Media:          No
   Read-Only Volume:         Not applicable (no file system)

   Device Location:          External
   Removable Media:          No

   Virtual:                  No
   OS 9 Drivers:             No
   Low Level Format:         Not supported

fdisk /dev/disk6

Disk: /dev/disk6    geometry: 97451/255/63 [1565565872 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE 1023 254  63 - 1023 254  63 [         1 -  732566645] <Unknown ID>
 2: 00    0   0   0 -    0   0   0 [         0 -          0] unused
 3: 00    0   0   0 -    0   0   0 [         0 -          0] unused
 4: 00    0   0   0 -    0   0   0 [         0 -          0] unused

gpt recover /dev/disk6

gpt recover: /dev/disk6: no primary or secondary GPT headers, can't recover

gpt -r -vv show /dev/disk6

gpt show: /dev/disk6: mediasize=3000592982016; sectorsize=512; blocks=5860533168
gpt show: /dev/disk6: PMBR at sector 0
       start        size  index  contents
           0           1         PMBR
           1  5860533167

gdisk /dev/disk6

GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries.

Here is a screen shot of the first part of the drive in wxHexEditor. The EFI PART starts at 4096.

I started looking for the HFSJ string starting at an offset of 409642, as suggested in other answers, but didn't find it near there. So I searched starting from the beginning of the drive and found the first occurrence at offset 314598400.

However, if I keep searching for occurrences of HFSJ, I find a lot of them that look exactly the same and with a lot of zero space around them, like the first one. Those start at 360424448 and are spaced 32768 apart. For example, at offsets 360424448 360457216 360489984 360522752 360555520

I used the Find All search in wxHexEditor and stopped after a few minutes. It had found a couple thousand at that point. I'm not sure what to make of those, if anything.

I was also able to find a section labeled EFI System Partition at offset 3000592961536. That also shows the name that the drive had, "Rosie".

Here are screen shots of the first HFSJ partition and the EFI System Partition. Added a screen shot of offset 8192 based on the comments.

Thanks for any help.

Answer 1

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.

Answer 2

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.

Answer 3

Did you get it back in the end?? I'm having the very same after I tried to use MacDrive to pull some big files to a win10 via USB it froze up & I was left with my trusty mac hdd whacked exactly like your with the 0xEE partition

UPDATE: I fixed my issue with simpler steps there is a testDisk tool that lists the start, end point and sizes of partitions on the HD, then the pdisk (the c option) allowed me to input that data and suddenly I could read my HD completely as before I get a warning but all the data is back