Partición NTFS en disco duro externo no reconocida o montada en El Capitan o Sierra, incluso con la última versión de Paragon o Tuxera

Tengo un Air 11" de mediados de 2013 con El Capitan recién actualizado a Sierra.

Tengo un Seagate USB 3 HD externo con un esquema de partición GUID, una partición HFS+ que arranque y una partición de datos NTFS.

El HD se compró con formato Mac y venía con una versión gratuita de Paragon, que he actualizado a la última versión. Se usa como disco de datos en mi PC, pero como el único disco en mi Mac al que le falta el SSD.

Lo había estado usando con éxito en mi computadora portátil con Windows y Mac lo mejor que puedo recordar, pero luego no usé la Mac durante tres meses más o menos hasta el otro día.

La Mac arranca desde la partición HFS pero no ve una segunda partición válida.

Intenté apagar y volver a cambiar la unidad a la PC y ambas particiones funcionan bien allí.

Probé tanto la versión gratuita para Seagate como la versión de prueba del controlador Paragon NTFS 14. También probé sin Paragon y el sistema operativo ni siquiera me permite usarlo de solo lectura. Ahora también probé la última versión de prueba de Tuxera.

Primeros Auxilios es el único que incluye algo parecido a un código de error:

Unknown filesystem version: e.89

¿Podría haber algo en la tabla de particiones que deba cambiarse con una herramienta de bajo nivel?

¡He notado que la Mac de alguna manera parece saber el nombre anterior de la segunda partición de cuando era una partición de instalación HFS!


Así es como las diversas herramientas en mi Mac y PC ven la unidad...

Mac, Utilidad de disco:Unidad de utilidad de disco
Partición de la Utilidad de Discos

mac, diskutil list:lista de utilidades de disco

Mac, Tuxera:
Tuxera

Mac, Primeros Auxilios:
Primeros auxilios

Windows, Administración de discos:
lista de utilidades de disco

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     

Volcados hexadecimales de disco sin formato según lo solicitado en los comentarios de 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
@klanomath: Mientras tanto, reduje la parte NTFS y agregué una segunda idéntica más una exFAT. Ambos funcionan tanto en Win como en Mac y el NTFS original muestra el problema exacto como antes. Agregaré la salida gpty fdisk, pero los números no coincidirán con las capturas de pantalla originales, así que avíseme si necesita que las actualice.
@klanomath: Bien. Ahora añadido...
@klanomath: Antes de probar esto y como parece conocer los detalles de bajo nivel, ¿qué podría explicar por qué Windows lo ve como una partición NTFS a pesar de la información incorrecta y ve su nombre actual, "Seagate BUP NTFS" mientras que Tuxera Disk Manager ve su nombre anterior, "ElCapInstaller" de cuando en realidad fue formateado como HFS. ¿ Podría tener información de partición GUID y HFS ? ¿Me arriesgo a perder datos si hemos pasado algo por alto?
¡Buena pregunta! Supongo lo siguiente: OS X / Tuxera / Paragon verifica el tipo de partición (que es Apple_HFS) y luego intenta encontrar el sector de arranque de volumen HFS (el tercer bloque de la partición que contiene una cadena HFSJ y algunas otras informaciones ocultas del sistema de archivos HFS ) que falla. Windows probablemente ignora el tipo de partición falsa pero detecta los dos sectores de arranque NTFS o es una cosa de dos etapas: aunque el tipo de partición es incorrecto, detecta los sectores de arranque NTFS y algunos otros detalles ocultos del sistema de archivos y finalmente logra montar el volumen.
¡No corre el riesgo de perder datos si no repara o inicializa un volumen! Cambiar la tabla de particiones con gpt siempre es reversible. gpt solo modifica los primeros 34 y los últimos 33 bloques de un disco (tamaño de bloque de 512 bytes). ¡No escribe en el espacio del disco donde residen las particiones/volúmenes!

Respuestas (1)

disk0s4 tiene el tipo de partición GUID incorrecto, como se ve en la captura de pantalla de Tuxera. El tipo de partición es 48465300-0000-11AA-AA11-00306543ECAC, que es HFS+ (el tipo de partición OS X estándar). Puede verificar esto ingresando sudo gpt -r show disk0.

Sin embargo, debería ser EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, que es el GUID para las particiones de datos básicos (BDP) de Microsoft.

Para cambiar el tipo de partición de inicio al modo de recuperación de Internet o a un segundo dispositivo de inicio (por ejemplo, una memoria USB), elimine disk0s4 con gpt y vuelva a agregarlo con los mismos límites (número de índice, bloque inicial y tamaño) pero de un tipo diferente.

En ciertas circunstancias, necesito la salida sudo fdisk /dev/disk0y algunos hexdumpresultados adicionales, se requiere espacio en disco no asignado entre disk0s3 y disk0s4 y el bloque y el tamaño iniciales deben modificarse en comparación con su tabla de partición gpt actual.


Inicie el modo de recuperación de Internet o una memoria USB con una instalación completa de OS X o una memoria USB del instalador de OS X. La edición de la tabla de particiones GUID con gpt requiere que desmonte el disco. No puede desmontar el disco en el que está arrancado.

  • Abra Terminal (barra de menú Utilidades > Terminal) e ingrese diskutil listpara obtener una descripción general. Obtenga el identificador de disco de la unidad de 500 GB; puede ser disk0 o disk1. A continuación, supongo que es disk0. Sin embargo, use el identificador de disco que ha encontrado en su entorno.

    Si inicia sesión como administrador, algunos comandos requieren que anteponga sudo ...la ejecución de algunos comandos (por ejemplo, gpt). Arrancado en una memoria USB del instalador o en el modo de recuperación de Internet, siempre es usuario raíz y no es necesario anteponer sudo.

  • Obtener la tabla de particiones:

    gpt show -r disk0
    
  • Desmontar el disco

    diskutil umountDisk disk0
    
  • Elimine la cuarta partición (falsamente tipificada):

    gpt remove -i 4 disk0
    diskutil umountDisk disk0
    
  • Sus resultados de volcado hexadecimal ("eb 52 90 4e 54 46 53 20" es la "cadena" ∂RENTFS(x20)) muestran que disk0s4 tiene sectores de arranque NTFS especiales (que generalmente ocurren en el primer y último bloque de un volumen NTFS) en block0 y bloque 121948143. (x0000000 es byte/bloque 0 de disk0s4 y xe898fde00 convertido con un servicio hex2dec es byte 62437449216 o 62437449216/512: bloque 121948143). Esto muestra que no hay espacio entre disk0s3 y disk0s4 y el tamaño es (121948143 bloques + block0) 121948144 bloques.
  • vuelva a agregar la cuarta partición con un tipo adecuado pero con los otros valores anteriores:

    gpt add -i 4 -b 488722456 -s 121948144 -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 disk0
    
  • reiniciar
En la PC, muestra algún tipo de brecha de 620 MB entre E:y F:, ¿podría ser "espacio en disco no asignado" como mencionas? ¿O esto más la disparidad en el nombre de la partición que ve la PC frente a la que ve la Mac podría sugerir que los dos sistemas operativos tienen ideas diferentes sobre dónde F:comienza y si hay una brecha o si pertenece a una de las particiones?
@hippietrail Los 620 MiB (= 650 MB) son su partición OS X Recovery HD (disk0s3) y son legítimos. Esperaría una brecha de 2 MiB o tal vez 100 MiB que no es visible ni detectable por ninguna de estas herramientas de las que publicó capturas de pantalla. Solo gpt y fdisk y tal vez hexdump pueden hacerlo.
¡Parece haber funcionado perfectamente! Lo he estado usando durante un día sin problemas perceptibles (-: