How to fix partition table after resizing bootcamp, MacOS disappear

Question

I have an issue accessing my MacOS data, can someone guide me how to fix this? I tried to increase the BOOTCAMP using MiniTool Partition Wizard. After that both MacOS and Bootcamp Windows disappear from the boot menu (Power on then press Option). Now I have to use a temporary MacOS on my extend SSD. But still can't access the data from the main MacOS. Do you have any idea on how to fix this, if I can use my MacOS and Windows as before that is great, but in case it is difficult at least can I access to MacOS disk to just copy some important data? I saw some post to fix this by adjusting the "hex" but I don't quite understand that, and it seems suitable for different case depending on different partition table, therefore I can't just apply blindly as my partition table is different with others. Below is my "diskutil list":

• 300GB which is my main MacOS (I need to access its data)
• 69.4 GB is my Bootcamp Windows
• 100 GB storage disk of my Mac data (the only one I can access now)
• The rest are there by the system.

Please assist to guide me how to fix this if you know. Appreciate. Thank you.

To add info on what I did when resizing the Bootcamp:

• I use MacOS Disk Utility to resize the disk0s1 down, to have free space (10GB)
• Then I boot to Bootcamp Windows, using the MiniTool Partition Wizard with the feature "Extend Partition" to extend my Bootcamp (10GB)

Answer 1

The sudo get -r show disk0 command shows values stored in the GUID Partition Table (GPT) on the internal drive. The sudo dd if=/dev/disk0s2 count=1 bs=128 | hexdump -Cv shows values stored at the beginning of the second partition on the internal drive.

The size in blocks of a APFS container is stored in the 8 bytes at offset 40 (28 hexadecimal) of the partition. In your case the bytes are fb 99 f2 04 00 00 00 00. This can be converted to 512 byte sectors by the following steps.

1. Reverse the order and remove the leading zeros to get 4f299fb.
2. Use the Calculator application (or other equivalent means) to convert hexadecimal to decimal. In this case, the result is 83,007,995 blocks, where a block is 4096 bytes.
3. In your case, there are 8 sectors per block. So the conversation to sectors is accomplished by multiplying by 8 to get 664,063,960 sectors, which is 340,000,747,520 bytes.

However, the output from the sudo gpt -r show disk0 command shows the size of the partition, with this APFS container, is only be 644,531,248 sectors, which is 329,999,998,976 bytes. This discrepancy would prevent any volumes in the APFS container from mounting.

Apparently, the macOS APFS container in the second partition and Windows NTFS volume in the third partition overlap by 10 GB. Since you can not mount the Windows NTFS volume, there is not enough information posted to the question to know this for certain. In other words, location and size of the NTFS volume is currently unknown. Also, neither the APFS container or NTFS volume may be intact.

I suppose, since the data on the macOS APFS volumes is important, the following commands could be used to remove the Windows partition and expand APFS partition to 340 GB. Hopefully, the desired volumes will mount and the data can be recovered.

diskutil unmount disk0s3
sudo gpt -f remove -i 3 disk0
sudo gpt -f remove -i 2 disk0
sudo gpt -f add -i 2 -b 409640 -s 664063960 -t apfs disk0