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.

Start of drive in wxHexEditor

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.

First HFSJ partition, EFI partition at end, and offset 8192.

Thanks for any help.

  • If would appear your disk had a block size of 4096 bytes and now has a size of 512 bytes. Since the block size is not stored on the disk itself, my question would be: Did you change the hardware in any way? Also, if the block size was 4096 bytes, then you should be able to read the old GPT table entries starting at 8192 bytes. So far, you have only posted the GPT header starting at 4096 bytes. The hex dump can be converted back to the correct decimal values using the information given here. Commented Mar 5, 2016 at 23:43
  • @DavidAnderson, The hardware did change in that the drive is in a different USB case. I could get the original case if that helps anything.
    – Doug Smith
    Commented Mar 6, 2016 at 1:46
  • @DavidAnderson I changed the screen shot to add one for offset 8192. It does show an EFI System Partition there.
    – Doug Smith
    Commented Mar 6, 2016 at 1:48
  • @klanomath Yes, your linked answer was correct. I mixed up block and offset. It's all zeros around offset 209736704, though. I also tried dividing that by 8 (26217088) in case there was an issue of a 4096 block size. That puts me within a lot of data, but no HFSJ string in sight.
    – Doug Smith
    Commented Mar 6, 2016 at 1:52
  • @klanomath, I had started through your process. My attempt to overwrite the first 40 blocks didn't actually write any data: 0+0 records in 0+0 records out 0 bytes transferred in 0.000013 secs (0 bytes/sec)
    – Doug Smith
    Commented Mar 6, 2016 at 1:55

3 Answers 3


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.

  • Thank you, this partially helped. When executing gpt create the system responds with "operation not permitted" but at least Disk Utility allows me to erase the disk now. I managed to fix two disks that got corrupted on Ventura. Commented Dec 18, 2022 at 0:16

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.

  • +1 We get an identical size & start block for the EFI and an identical start block but a different size of the main volume.
    – klanomath
    Commented Mar 6, 2016 at 2:27

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

  • Yes, I did get it back and I'm glad to hear you did too. Thanks for documenting your simpler steps.
    – Doug Smith
    Commented Sep 21, 2021 at 14:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .