OS X stopped recognizing my HFS+ partition when I created a new partition before it

Question

I have a 2 TB USB drive that's using GPT, but OSX (10.11.4) on my macbook pro (early 2015) stopped recognizing my HFS+ partition after I inserted a partition before it on the disk.

This is what I had originally, and OSX listed all partitions correctly in Finder:

[ Elements            | Extra Fett |             | Time machine ]

[ NTFS                | ExFAT      | Unallocated | HFS+         ]
[ ~1500               | 97         | 97          | 167          ] (GB)

The drive currently has the following layout (I shrank Elements and created TESTPART):

[ Elements | TESTPART | Extra Fett |             | Time machine ]

[ NTFS     | FAT32    | ExFAT      | Unallocated | HFS+         ]
[ ~1350    | 150      | 97         | 97          | 167          ] (GB)

...but this is what OSX sees (only lists the first three in Finder):

[ Elements | TESTPART | Extra Fett |             | ?            ]

[ NTFS     | FAT32    | ExFAT      | Unallocated | ?            ]
[ ~1350    | 150      | 97         | 97          | 167          ] (GB)

What happened? I thought this operation would be no trouble on a GPT drive.

---

Extra details

Ubuntu gdisk says it is using GPT with a protective MBR, and both gdisk and gparted list all partitions with no problems. Windows 10 partition manager also lists all partitions and says the drive uses GPT.

When I run diskutil list on OSX I get:

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *2.0 TB     disk2
   1:       Microsoft Basic Data Elements                1.5 TB     disk2s1
   2:       Microsoft Basic Data Extra Fett              104.9 GB   disk2s2
   3:       Microsoft Basic Data                         167.8 GB   disk2s3
   4:       Microsoft Basic Data TESTPART                157.3 GB   disk2s4

There are a few problems with this that I can think of:

• The unallocated space is not listed.
• The partitions are definitely listed in the wrong order.
• The HFS+ volume #3 (my time machine) that has always been visible to OSX before, lost its label and is listed as Microsoft Basic Data. It doesn't show up in Finder or Disk Utility anymore. This happened ever since I shrank Elements. I created TESTPART in the resulting space (done in Win10).

Answer 1

Unallocated space not appearing is not really a problem; many programs, including gdisk and diskutil, display only partitions, not unallocated space. Tools like GParted and cgdisk explicitly show unallocated space (although I think even GParted omits unallocated space below a certain size).

There are two ways to define partition order: The order on the disk of the partitions themselves and the order in which pointers to the partition exist in the partition table. It's least confusing if these two orders match, but there's nothing in GPT (or MBR primary partitions) to enforce this. Thus, out-of-order partitions are common and do not necessarily signify a problem. Don't worry about that detail.

Thus, the only real problem you're reporting is that your HFS+ volume has become inaccessible. This might be a partition table problem, but it's more likely to be a filesystem problem. Unfortunately, without detailed before-and-after information on partition start points, I can't differentiate the two possibilities. The safest way to proceed is:

1. Do a low-level backup of the partition with dd in either OS X or Linux, as in sudo dd if=/dev/disk2s3 of=/path/to/lots/of/space/disk2s3-backup.img. This will preserve the data in the partition in case the next step makes things worse, which is a real possibility. You should also back up the partition table as it is now by using the b option on gdisk's main menu.
2. Use OS X's Disk Utility to repair the partition. The GUI tool should be able to do this. I'm less familiar with the OS X command-line tools to do this, but in Linux it would be fsck, and it might be the same in OS X.
3. If this doesn't work, restore the backup you made in step #1 by reversing the if= and of= options.

If that doesn't work, I do have another few suggestions:

• You could delete the errant partition and try using TestDisk or something similar to recover it. The idea here is that whatever you used to modify your partitions might have adjusted the start point of your HFS+ partition, which would render it inaccessible. TestDisk scans for filesystems and creates new partition table entries for them, which should fix that problem. This isn't a sure thing, though.
• Re-create the partition and restore its files from a backup.
• If that fails, restore the original partition (by re-creating it using the exact start and end points it has now or by restoring the gdisk partition table backup) and use PhotoRec, or a similar tool, to recover the partition's contents on a file-by-file basis. This will be much more tedious than restoring files from a backup, and you're unlikely to recover everything, but with any luck you'll be able to recover most of the files.

It might be helpful to know what tool you used to resize the NTFS partition and create a new one. Although I don't know of any bugs in common utilities that would produce this exact symptom, I certainly trust some partitioning tools more than others. (The standard Windows utilities are very buggy with extended/logical partitions on MBR disks, for instance -- but yours is a GPT disk, so that's not really an issue.)

---

EDIT:

I just noticed something about your description: What should be an HFS+ volume is marked as being of type "Microsoft Basic Data" by diskutil. That's Just Plain Wrong. It's easily fixed with gdisk:

1. Launch gdisk on the disk.
2. Type p to view the partition table and positively identify the partition that can't be accessed. I expect it to be partition 3, but it's best to be sure.
3. Type t to change the type code. You'll be asked for a partition number.
4. Type 3 (or whatever the appropriate number is, as just identified).
5. When prompted, enter a type code of AF00.
6. Type w to save your changes. (You'll be asked for verification.)

This should fix the problem. (If you do it from OS X, you may need to reboot.) There's a chance that you'll need to enter AF05 rather than AF00 as the type code, so if it doesn't work, try repeating that process, but with that change.

Other tools can probably fix it, too, but I'm not familiar with the procedures, offhand. (Maybe removing the "msftdata flag" in parted or GParted would do it....)