MacOS GPT Messed up File System (‘FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF’)

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

The proper GUID of APFS partitions is 7C3457EF-0000-11AA-AA11-00306543ECAC.

The default pMBR was replaced with an old-style MBR, probably by the Linux installation!

Your boot system (in Internet Recovery Mode) seems pretty old. Any disk or partition verification executed with diskutil may yield some bogus result. In no case try to repair anything with diskutil!

To get your APFS partition back remove partition disk0s2 and restore it with the proper type:

• Open in the menubar > Utilities > Terminal

• get some details:

  diskutil list #below I assume the disk identifier of the internal disk is disk0
  gpt -r show disk0
  

• Unmount disk0:

  diskutil umountDisk disk0
  

• remove and restore the 2nd partition:

  gpt remove -i 2 disk0
  diskutil umountDisk disk0
  gpt add -i 2 -b 409640 -s 372637568 -t 7C3457EF-0000-11AA-AA11-00306543ECAC disk0
  

• verify disk and partition:

  diskutil list
  diskutil verifyDisk disk0       
  diskutil verifyVolume disk0s2
  

Your Mac should be able to boot despite the MBR.

If you want (or have) to restore the pMBR because the MBR is stubborn/blocks the modification of the partition table do the following:

• get all disk details:

  diskutil list #below I assume the disk identifier of the internal disk is disk0
  gpt -r show disk0
  

• replace the GUID partition table:

  diskutil umountDisk disk0
  gpt destroy disk0
  gpt create -f disk0
  

• re-add all previous partitions visible in the last gpt -r show disk0 output:

  gpt add -i 1 -b 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk0
  gpt add -i 2 -b 409640 -s 372637568 -t 7C3457EF-0000-11AA-AA11-00306543ECAC disk0
  gpt add -i 3 -b 373047208 -s 262144 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk0
  gpt add -i 4 ...
  gpt add -i 5 ...
  

  If you get a resource busy error after one of the steps, just unmount disk0 again with

  diskutil umountDisk /dev/disk0
  

• Finally verify disk and partitions:

  diskutil list
  diskutil verifyDisk disk0       
  diskutil verifyVolume disk0s1
  diskutil verifyVolume disk0s2
  diskutil verifyVolume disk0s3
  #disk0s4 & disk0s5 can't be verified with the default macOS tools because the latter is a Linux swap and the former a Linux partition, probably with ext4