MacOS – External HDD with encrypted mac partitions is no longer recognized

disk-utilitymacospartition

I have an external disk which I use for data and a TimeMachine backup. For some reason the partition table appears to be broken and I may already have worsened the problem by trying to fix it with testdisk, where I went through EFI/GTP -> analyze -> quick search and tried to restore all partitions, which tells me the structure is bad, so I restored the first two. I'm not sure what EFI System is good for, if activated it is mounted, but that wasn't the case before the problems started.

The 4TB disk is split into two parts around 2TB each, both standard encrypted macOS partitions.

I already tried to follow HFS+ Partition of Mac OSX is not recognized in Windows 10 Bootcamp but when I try to add the second partition, it says GPT partition #2 does not exist or is too big; skipping.

The same happened on another external disk. Both worked fine earlier today/a few days ago. The only change I see is that I used a different cable for one of the disks but not for the other.

So now that I have restarted my macbook, the second disk works again, whereas the first does not (presumably because I messed it up).

I would appreciate if someone can point me to a solution for this. Also I would be interested how this can happen at all.

Best Answer

Ok, let us step back for a second here. What OS are you running these commands from, and when was the volume originally partitioned? Although you've not mentioned it, its clear from the screenshots you've posted that (at least, as some point, depending on what you mean by "restoring" the first two), your volume was formatted into a Core Storage "Logical Volume Group", with at least one Core Storage "Logical Volume".

CoreStorage is a pretty well deprecated technology at this point. It was only really actively used for a brief window by Apple.

This more or less necessarily means that "the 4TB disk is split into two parts around 2TB each, both standard encrypted macOS partitions" isn't quite true, as there's not really such a thing as a "standard" "encrypted" macOS partition. There are [J]HFS[+] logical volumes which are encrypted via CoreStorage, although today they're quite rare (10.12+, APFS is preferred, and Time Machine on JHFS+ uses a whole different mechanism using disk images/sparse bundles). None of these, are, unfortunately, close to "standard".

My first recommendation (and its difficult to say what to do after this, without more information) at this point would to be would be to try to revert the Core Storage LVG into standard JHFS+ partitions, so they're individually recognized on in the GPT partition table. You may have to decrypt the Logical Volumes first. That would be diskutil cs revert [disk5s2 or the LVG UUID], possibly after one or more diskutil cs decryptVolume [diskXsX or LV UUID] commands.

As for restoring disks and volumes, if you wish to retain their structure, your best bet is to use asr — although of course occasionally with dd in combination with /dev/r[diskX] there can still be some milage to be had, I really don't recommend it.

Related Solutions

Disk Utility – Why EFI Partitions Are Created on External Disks

So you can image the drive and get things set up while your new drive is in an enclosure and only swap it into your Mac as an internal drive once it is tested and ready to go. Also, not having to code special exceptions when to and when not to write an EFI partition is sound engineering practice.

You can't write buggy code if you don't write any code.

MacOS – Trouble with GUID HDD recovery in testdisk

Initially partitioned with Disk Utility (as GUID pt, 1 partition, HFSJ) I would expect the partition tables of your WD Red 4 TB disks to look like this:

     start         size  index  contents
         0            1         PMBR
         1            1         Pri GPT header
         2           32         Pri GPT table
        34            6         
        40       409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
    409640   7813365344      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
7813774984       262151         
7814037135           32         Sec GPT table
7814037167            1         Sec GPT header

with the EFI = 409640 blocks and the empty default Apple spacer of 262144 blocks. All aligned to the 4096 Byte physical block size the resulting HFSJ partition starts at block 409640 and has a size of 7813365344 blocks.

You may just test this by removing the current partition (below I assume the disk identifier of the external drive is disk2 - use the disk identifier you have found in your environment):

diskutil umountDisk /dev/disk2
sudo gpt remove -i 1 disk2
sudo gpt add -i 1 -b 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk2
sudo gpt add -i 2 -b 409640 -s 7813365344 -t 48465300-0000-11AA-AA11-00306543ECAC disk2

If asked don't initialize any volume.

Now verify the volume:

diskutil verifyVolume disk2s2

After further investigations it turns out that one of the two external disks contains an additional recovery partition. After adding a 3rd partition like this:

     start         size  index  contents
         0            1         PMBR
         1            1         Pri GPT header
         2           32         Pri GPT table
        34            6         
        40       409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
    409640   7812357952      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
7812767592      1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
7814037128            7         
7814037135           32         Sec GPT table
7814037167            1         Sec GPT header

and the help of Disk Warrior (to restore broken file systems) both main volumes of the external disks have been salvaged.

Best Answer

Related Solutions

Disk Utility – Why EFI Partitions Are Created on External Disks

MacOS – Trouble with GUID HDD recovery in testdisk

Related Question