1

This is a 4 TB hard drive formatted in Mac's Disk Utility as a single non bootable Exfat partition with the drive letter G. It worked fine before I decided to make a clone drive of my C bootable drive. During boot Windows repaired the new clone drive with the letter E, after that G is no longer accessible in Mavericks or Windows.

The hard drive is listed in Mac's Disk Utility and Windows Disk Management. But there's no drive letter and I'm unable to mount it.

In Windows Disk Management, the Hard Drive shows as Healthy "EFI System Partition" labeled as Free Space. All the options are grayed. Only "Convert to Dynamic Disk..." is accessible.

As for Disk Utility in Mac, the mount option does nothing, and Repair returns:

Error: This disk doesn’t contain an EFI system partition. If you want to start up your computer with this disk or include it in a RAID set, back up your data and partition this disk.

As mentioned, this is a non bootable drive.

The documents in the drive are very important, so a format would be detrimental.

enter image description here

enter image description here

sudo gpt -r -vv show /dev/disk0

gpt show: /dev/disk0: mediasize=4000787030016; sectorsize=512; blocks=7814037168
gpt show: /dev/disk0: PMBR at sector 0
gpt show: /dev/disk0: Pri GPT at sector 1
gpt show: /dev/disk0: Sec GPT at sector 7814037167
       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34      262144      1  GPT part - E3C9E316-0B5C-4DB8-817D-F92DF00215AE
      262178        2014         
      264192  7813771264      2  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
  7814035456        1679         
  7814037135          32         Sec GPT table
  7814037167           1         Sec GPT header

TestDisk results:

enter image description here enter image description here enter image description here

  • If you need a cross-platform drive with large file support exFAT is ideal, but it's best used with an MBR partition table rather than GUID to maximize compatibility. You say your hard drive is listed in Disk Utility - in spite of not being able to mount anything, are its partition(s) also listed in DU, or is it just showing the parent disk? – ScunnerDarkly Mar 20 '15 at 14:15
  • @GabrielMeono There is no need to mount disk0s1 because it's just a Microsoft Reserved partition. Instead you have to repair the MBR/GPT (whatever it was) to get your data back. Please describe exactly which steps you took to create the "clone drive" of your C-drive and add it to your question. And stop using Disk Utility or things might get worse! – klanomath Mar 20 '15 at 14:48
  • The G drive was never intended to be modified, the cloning was done from C drive to E drive (both are physical drives) using a Macrium Reflect image stored in G. The cloning failed so far, since E never booted. After realizing that G was gone, I detached E drive and rebooted, the problem persists. – Gabriel Meono Mar 20 '15 at 15:11
  • @GabrielMeono Please open Terminal.app and enter diskutil list, then depending what you get sudo gpt -r -vv show /dev/diskx (you have to enter your admin password afterwards!) with x= numerical identifier of your 4 TB device. Add the result of the gpt command to your question. – klanomath Mar 20 '15 at 16:21
3

I suspect Windows` chkdsk or another Microsoft tool to erroneously repairing the partition table of your device containing the EXFAT volume.

The result of sudo gpt -r -vv show /dev/disk2 of my 4 TB device created in a VM and formatted with Disk Utility in comparison looks like this:

gpt -r -vv show /dev/disk2
gpt show: /dev/disk2: mediasize=4000655081472; sectorsize=512; blocks=7813779456
gpt show: /dev/disk2: PMBR at sector 0
gpt show: /dev/disk2: Pri GPT at sector 1
gpt show: /dev/disk2: Sec GPT at sector 7813779455
       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        2008         
      411648  7813365760      2  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  7813777408        2015         
  7813779423          32         Sec GPT table
  7813779455           1         Sec GPT header

(Please consider that the mediasize, the blocks and some other values are different to yours, because i use a slightly smaller example disk here.)

The differences to your finding are obvious: the first partition of your disk isn't aligned properly to the 4096 byte sector size and is smaller. The second partition starts too early and is probably too big.

You probably have to fix both partition. This will only work if you partitioned the drive with Disk Utility in Mac OS X.

Preparation:

Backup your Mac and then detach all external drives.
Download and install wxHexEditor. Enable the root user and log-in as root.

Hint: While working with wxHexEditor don't use copy and paste. Enter everything manually! You might accidentally write directly to your disk.

Where does the EXFAT partition start and end?

First you have to determine the starting block of your EXFAT volume:

  • Open Terminal and enter diskutil list. Get the Identifier of the disk to repair.

  • Open Calculator. Open wxHexEditor. Check that you work in read-only mode ("Options" -> "File mode" -> "Read only"). In the menubar go to "Devices" -> "Open disk device" -> choose the appropriate diskNumber.

  • Hit the search button (marked with the red circle in the picture below) and enter EXFAT (exactly like in the picture). Please try to arrange the wxHexEditor window like in the examples below with straight red lines.

    search

  • My EXFAT entry (see picture below) is at offset 210763776. Now you can calculate the start block of the volume with: OffsetBytes/512 = NewStartBlockEXFAT. The start block in my example is 411648.

    If you get a significantly smaller starting block (=<409639) stop here, because you probably didn't partition your disk with Disk Utility previously.

    find

  • The ending block of the EXFAT volume can't be determined easily; we have to guess it (somehow). The problem is the variable gap between partition 2 and the second GPT table. In your case it has 1679 blocks, in my example it has 2015 blocks.

    • Method 1 (maximal size in the "unallocated space" between the block containing the EXFAT string and the second GPT table):
      The maximal volume size is StartBlock2ndGPT-NewStartBlockEXFAT. The size has to be dividable through 8. Reduce the size until you get a size dividable through 8. Example: In my case the maximal size would be 7813779423 (StartBlock2ndGPT) - 411648 (StartBlockEXFAT) = 7813367775 (which isn't dividable through 8). The biggest size dividable through 8 is 7813367768.

    • Method 2 (minimum size containing all occupied blocks between the block containing the EXFAT string and the second GPT table):
      You might jump to sector 7814037135 (the first block of your secondary GPT table) with the arrow button (the second button left of the search button) and search backwards and match case disabled with "Find some bytes" to get the last occupied sector. This may take a while. Make a note of your finding (if you have one in a reasonable timeframe). Divide the offset through 512 to get the sector number. The sector number should be smaller than 7814037135. Now calculate the provisional minimal size of your volume: StartBlockEXFAT+1-LastOccupiedSector. The result must be dividable through 8. To get size add blocks until the size is dividable through 8.
      You may stop the process after 5 minutes without result because then the last occupied block number is probably smaller than 7807917625 assuming the process searches 10 MByte/s (the last ~3 GB of your disk). Use Method 1 then.

    Both results probably lead to a wrong size of the EXFAT volume, but this should be repairable. It's more important to get the proper start block. Additionally method 2 may deliver incorrect results if the disk has been completely filled with data previously using a different partition layout and hasn't been zero-filled afterwards.

Restoring the "old" GPT

Here i assume the identifier of the disk containing the EXFAT volume is disk0.

  • First you have to unmount the disk

    diskutil umountDisk disk0
    
  • Check the partition layout, then remove the two partitions:

    gpt -r -vv show /dev/disk0
    
    gpt remove -i 2 disk0
    gpt remove -i 1 disk0
    
  • Since the (Apple-)EFI usually has a fixed size we can easily add it with:

    gpt add -b 40 -i 1 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk0
    
  • With the start block of the EXFAT partition and Size (the volume size found with Method 1 or 2 above) we can also add it:

    gpt add -b NewStartBlockEXFAT -i 2 -s Size -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 disk0
    
  • Remount disk0 with:

    diskutil mountDisk disk0
    
  • Quit Terminal, Calculator and wxHexEdit and open Disk Utility.

  • Check your EXFAT volume for errors.

If you run into problems (e.g you can't find the proper EXFAT volume size), have doubts or questions immediately stop and contact me with a comment @klanomath!

  • Thank you so much! It's now detected both in Windows and OS X. All the files are intact :D – Gabriel Meono Mar 20 '15 at 21:01
  • @GabrielMeono How did you determine the size of the EXFAT volume? Or, how big is it now? – klanomath Mar 20 '15 at 21:08
  • Now is 3725.90 GB with 129 MB Unallocated. TestDisk was able to browse the files, and also pointed the same start and end of the sectors. After that I selected "Write" on TestDisk. Rebooted and the hard drive was back on Windows. Mac did not detect the device at first, so I used your terminal command to mount it. And it came back! – Gabriel Meono Mar 20 '15 at 21:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .