Partition type FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, drive unmountable

Question

Yes, I already tried this one: Partition type suddenly FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, drive unmountable

My main partition is in this ffffffff-ffff-ffff-ffff-ffffffffffff format or whatever it is. And I need all the Data on this disk3s2.

Here is a picture of my Disk, a couple of hours ago:

• disk3s1: EFI
• disk3s2: Macintosh (ffffffff-ffff-ffff-ffff-ffffffffffff partition with all of my Data on, I want this Data!)
• disk3s3: Apple_HFS Recovery HD
• disk3s4: New (Another useless Partition, its empty.)
• disk3s5: Apple_Boot Recovery HD

What I did to try to repair my disk:

diskutil umountDisk /dev/disk3
sudo gpt destroy /dev/disk3
diskutil umountDisk /dev/disk3
sudo gpt create -f /dev/disk3

sudo gpt add -i 1 -b 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk3

So whenever I try to add another partition, I get this Error:

gpt add: /dev/disk3: error: no space available on device

Please help if you have any suggestions, I lost a lot of important Data!!!

---

Update:

diskutil list

leads to this:

 /dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *120.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage SSD                     119.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            SSD                    +118.8 GB   disk1
                                 Logical Volume on disk0s2
                                 ...deleted it...
                                 Unencrypted

/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *320.1 GB   disk3
   1:                        EFI EFI                     209.7 MB   disk3s1

and

sudo gpt -r show disk3

leads to 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  624732774         
  625142414         32         Sec GPT table
  625142446          1         Sec GPT header

Answer 1

The volumes could be recovered in a TeamViewer session by searching for special strings similar to the method outlined in this answer: My SATA hardrive was ejected, and is unable to be remounted due to issues.

The assumptions made:

• disk3s4 (24.6 GB) and disk3s5 (650 MB) are located at the end of the disk (see diskutil list screenshot of the question - both vanished after destroying the old partition table with sudo gpt destroy /dev/disk3)
• disk3s2 (Macintosh) occupies/occupied the whole unallocated disk space (except the 1st Recovery HD) of ~294 GB and is encrypted.

---

To get the starting block of the first Recovery HD enter (which has to be in the 271 GiB - 274 GiB or ~291 GB - ~295 GB range of the disk)

sudo hexdump -s 271g /dev/disk3 | grep "48 46 53 4a"

(hexdump uses GibiBytes instead of GigaBytes!) which revealed:

447f801400 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f828a00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f840c00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 00 06
447f871e00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
...

0x447f801400 is Byte 294196876288 (or block 574603274) of the disk. Since the string HFSJ resides in the third block of a volume, the Recovery HD starts with block 574603272.

The typical output if the previous volume wasn't a FileVault but a normal HFSJ volume would look like this instead:

447f800c00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 01 ff
447f801400 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f828a00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f840c00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 00 06
447f871e00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
...

The first and second byte number show a difference of 0xc00-0x1400=0x800 or 2048 Bytes because the preceding OS X volume has an alternative volume header in the second last block while FileVault volumes don't have one.

The Recovery HD has a fixed size of 1269536 blocks and it can be added with gpt to the partition table.

sudo gpt add -i 3 -b 574603272 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk3

Now verify the volume with

diskutil verifyVolume disk3s3

If the partition boundaries and the volume are/is OK you'll get an exit code 0.

In the unallocated disk space between EFI and Recovery HD a CoreStorage partition was added:

sudo gpt add -i 2 -b 409640 -s 574193632 -t 53746F72-6167-11AA-AA11-00306543ECAC disk3

The FileVault password window popped up and the password was entered - so it was added successful probably.

The disk and the volume were verified with:

diskutil verifyDisk disk3
diskutil verifyVolume disk3s2

which both exited with code 0 and all was fine.

Later the FileVault volume was extended to the full size of the disk with:

diskutil cs lvUUID resizeStack 318g #with lvUUID: the Logical Volume UUID of the second CoreStorage container