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
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
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.