2

I have a mid-2013 Air 11" with El Capitan just upgraded to Sierra.

I have an external Seagate USB 3 HD with GUID partitioning scheme, an HFS+ partition I boot off, and an NTFS data partition.

The HD was bought Mac-formatted and came with a free version of Paragon, which I have updated to the latest version. It's used as a data disk on my PC but as the only disk on my Mac which is missing the SSD.

I had been using it successfully on both my Windows and Mac laptop as best as I can recall but then didn't use the Mac for three months or so until the other day.

The Mac boots off the HFS partition but does not see a valid second partition.

I've tried shutting down and switching the drive back to the PC and both partitions work fine there.

I've tried both the free-for-Seagate and the trial versions of the Paragon NTFS driver 14. I've also tried without Paragon and the OS does not even let me use it read-only. I've now also tried the latest trial version of Tuxera.

First Aidis the only one which includes anything like an error code:

Unknown filesystem version: e.89

Could there be something in the partition table that needs to be changed with a low-level tool?

I have noticed that the Mac somehow seems to know the previous name of the second partition from when it was an HFS installation partition!


Here is how the various tools on my Mac and PC see the drive ...

Mac, Disk Utility: Disk Utility drive
Disk Utility partition

Mac, diskutil list: diskutil list

Mac, Tuxera:
Tuxera

Mac, First Aid:
First Aid

Windows, Disk Management:
diskutil list

Mac, gpt:

$ sudo gpt -r show disk0
Password:
      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  487043280      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  487452920    1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  488722456  121948144      4  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  610670600       2040         
  610672640  121944064      5  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  732616704       2048         
  732618752  244154368      6  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  976773120         14         
  976773134         32         Sec GPT table
  976773166          1         Sec GPT header

Mac, fdisk:

$ sudo fdisk /dev/disk0

Disk: /dev/disk0    geometry: 60801/255/63 [976773167 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE 1023 254  63 - 1023 254  63 [         1 -  976773166] <Unknown ID>
 2: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
 3: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
 4: 00    0   0   0 -    0   0   0 [         0 -          0] unused     

Hex dumps of raw disk as requested in comments by klanomath:

$ sudo hexdump /dev/rdisk0s4 | grep "eb 52 90 4e 54 46 53 20"
0000000 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00
^C
$ sudo hexdump -s 57g /dev/rdisk0s4 | grep "eb 52 90 4e 54 46 53 20"
e898fde00 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00
5
  • @klanomath: In the meantime I shrunk the NTFS part and added a second identical one plus an exFAT one. Those both work on both Win and Mac and the original NTFS shows the exact problem as before. I'll add the gpt and fdisk output but the numbers won't match the original screenshots, so let me know if you need me to update those. Nov 30, 2016 at 16:28
  • @klanomath: OK. Now added ... Nov 30, 2016 at 18:01
  • @klanomath: Before I try this and as you seem to know the low-level details, what might explain why Windows sees it as an NTFS partition despite the wrong info and sees its current name, "Seagate BUP NTFS" whereas Tuxera Disk Manager sees its former name, "ElCapInstaller" from when it was actually formatted as HFS. Could it have both GUID and HFS partition info? Do I risk data loss if we've overlooked something? Nov 30, 2016 at 18:51
  • Good question! I assume the following: OS X / Tuxera / Paragon verifies the partition type (which is Apple_HFS) and then tries to find the HFS Volume Boot Sector (the third block of the partition which contains a string HFSJ and some other hidden HFS file system infos) which fails. Windows probably ignores the false partition type but detects the two NTFS boot sectors or it's a two-stage thingy: though the partition type is wrong, it detects the NTFS boot sectors and some other hidden file system details and finally succeeds mounting the volume.
    – klanomath
    Nov 30, 2016 at 19:02
  • You don't risk data loss if you don't repair or initialize a volume! Changing the partition table with gpt is always reversible. gpt only modifies the first 34 and the last 33 blocks of a disk (512 byte block size). It doesn't write to disk space where partitions/volumes reside!
    – klanomath
    Nov 30, 2016 at 19:08

1 Answer 1

2
+50

disk0s4 has the wrong GUID partition type - as visible in the Tuxera screenshot. The partition type is 48465300-0000-11AA-AA11-00306543ECAC which is HFS+ (the standard OS X partition type). You can check this by entering sudo gpt -r show disk0.

It should be EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 though, which is the GUID for Microsoft basic data partitions (BDP).

To change the partition type boot to Internet Recovery Mode or a second boot device (e.g. a thumb drive), remove disk0s4 with gpt and re-add it with the same boundaries (index number, beginning block & size) but a different type.

Under certain circumstances - I need the output of sudo fdisk /dev/disk0 and some hexdump results additionally - unallocated disk space between disk0s3 and disk0s4 is required and the beginning block & size have to be modified compared to your current gpt partition table.


Boot to Internet Recovery Mode or a thumb drive with either a full OS X install or an OS X Installer thumb drive. Editing the GUID partition table with gpt requires you to unmount the disk. You can't unmount the disk you are booted to.

  • Open Terminal (menubar Utilities > Terminal) and enter diskutil list to get an overview. Get the disk identifier of the 500 GB drive - this may be disk0 or disk1. Below I assume it's disk0. Use the disk identifier you have found in your environment though.

    If you log-in as admin some commands require you to prepend sudo ... executing some commands (e.g. gpt). Booted to an installer thumb drive or to Internet Recovery Mode you are always root user and prepending sudo is not necessary.

  • Get the partition table:

    gpt show -r disk0
    
  • Unmount the disk

    diskutil umountDisk disk0
    
  • Remove the 4th (falsely typified) partition:

    gpt remove -i 4 disk0
    diskutil umountDisk disk0
    
  • Your hexdump results ("eb 52 90 4e 54 46 53 20" is the "string" ∂RENTFS(x20)) show that disk0s4 has special NTFS Boot Sectors (which typically occur in the first and the last block of an NTFS volume) in block0 and block 121948143. (x0000000 is byte/block 0 of disk0s4 and xe898fde00 converted with a hex2dec service is byte 62437449216 or 62437449216/512: block 121948143). This shows that there is no gap between disk0s3 and disk0s4 and the size is (121948143 blocks + block0) 121948144 blocks.
  • re-add the 4th partition with a proper type but the old other values:

    gpt add -i 4 -b 488722456 -s 121948144 -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 disk0
    
  • reboot
3
  • On the PC it shows some kind of gap of 620 MB between E: and F: - could this be "unallocated disk space" as you mention? Or could this plus the disparity in the name of the partition the PC sees vs that the Mac sees suggest the two OSes have different ideas about where F: starts and whether there is a gap or it belongs to one of the partitions? Nov 30, 2016 at 15:45
  • 1
    @hippietrail The 620 MiB (=650 MB) is your OS X Recovery HD partition (disk0s3) and it's legit. I would expect a gap of either 2 MiB or maybe 100 MiB which isn't visible/nor detectable by any of these tools you posted screenshots from. Only gpt and fdisk and maybe hexdump can.
    – klanomath
    Nov 30, 2016 at 16:23
  • Seems to have worked perfectly! I've been using it for a day with no discernible problems (-: Dec 2, 2016 at 16:48

You must log in to answer this question.

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