ext4 y NTFS en macOS sin extensiones del kernel

Actualizado octubre 2026 · válido para macOS 13–15 · Apple Silicon e Intel

macOS no puede leer una partición Linux ext4 en absoluto, y monta el NTFS de Windows en solo lectura. El apaño habitual —macFUSE— es una extensión del kernel. En Apple Silicon eso implica arrancar en Recovery, bajar la política de seguridad a "Reducida" y aprobar un kext de terceros que corre dentro del kernel. Mucha gente, razonablemente, no quiere hacer eso solo para copiar unos ficheros de un disco de NAS. Así es como consigues lectura/escritura completa en ambos sistemas de archivos sin ninguna extensión del kernel, y los detalles de ingeniería que lo sostienen en una app firmada y notarizada.

Por qué macFUSE necesita el kernel — y FUSE-T no

FUSE ("Filesystem in Userspace") permite que un programa normal implemente un sistema de archivos. Pero el kernel sigue teniendo que enrutar las syscalls open()/read()/write() hacia ese programa en espacio de usuario. macFUSE hace ese enrutado con una extensión del kernel: un dispositivo de caracteres /dev/macfuse* respaldado por código kext.

FUSE-T toma otro camino. En lugar de un kext, levanta un pequeño servidor NFS en espacio de usuario en localhost y le pide al cliente NFS integrado —de serie, de Apple— del kernel que lo monte. El cliente NFS ya vive en el kernel y está firmado por Apple, así que no hay nada que aprobar, ni Recovery, ni seguridad reducida. Tu driver del sistema de archivos habla FUSE con un demonio FUSE-T, que traduce a NFS, que el kernel habla de forma nativa. Mismo resultado, cero código de kernel de terceros.

driver ext4 / NTFS  ⇄  libfuse  ⇄  demonio FUSE-T  ⇄  NFS (localhost)  ⇄  kernel de macOS

Hay una contrapartida que conviene decir claro: la semántica de NFS no es idéntica a un montaje nativo del VFS. Un par de cosas se ven distintas a través de statfs (más abajo), y el rendimiento es bueno pero no a nivel de driver. Para "escribir una carpeta de 30 GB en un disco de NAS", es un trato estupendo a cambio de no tocar nunca el kernel.

ext4: fuse2fs y la trampa del replay del journal

Para ext4 el driver es fuse2fs, que viene con e2fsprogs e implementa el sistema de archivos sobre libext2fs. Monta en lectura/escritura sobre FUSE-T y maneja ext4 de verdad — incluidos los incómodos de cajas NAS con cuotas internas activadas.

El fallo sutil con el que todo el mundo tropieza: fuse2fs no reproduce el journal de ext4. Un disco que una máquina Linux o un NAS desmontó de forma sucia te llega "sucio" — el journal tiene transacciones confirmadas que nunca se escribieron en sus bloques finales. Si lo montas directamente, obtienes cannot read block bitmap y un montaje fallido, en un disco que en realidad está bien. La solución es un chequeo previo que reproduzca el journal primero:

# reproduce el journal / repara antes de montar en lectura-escritura
e2fsck -p /dev/diskXsY        # -p: reparaciones automáticas y seguras
# si el superbloque tiene flags de error, escala:
e2fsck -fy /dev/diskXsY

Sáltatelo en un montaje de solo lectura (no quieres tocar el disco), pero en lectura/escritura es la diferencia entre "funciona" y "esta app está rota". Dale también un timeout generoso — un replay del journal en un volumen NAS de 14 TB no es instantáneo.

NTFS: ntfs-3g, compilado contra FUSE-T

ntfs-3g es el driver NTFS open source de referencia — el mismo que trae cualquier distribución de Linux. El problema en macOS es que la compilación habitual de Homebrew enlaza contra el libfuse de macFUSE, lo que vuelve a arrastrar el kext. La solución es compilar ntfs-3g contra el libfuse de FUSE-T, para que toda la ruta de NTFS quede también sin kext.

Un detalle más: un disco que Windows dejó hibernado (Inicio rápido, o sin expulsar bien) monta en solo lectura o se niega a montar. Borrar el fichero de hibernación deja montarlo en lectura/escritura:

ntfs-3g -o remove_hiberfile /dev/diskXsY /Volumes/puntodemontaje

Detectar el solo-lectura bien: statfs, no una prueba de escritura

macOS auto-monta por su cuenta un disco NTFS, en solo lectura, antes de que actúe cualquier herramienta de terceros. Detectar eso de forma fiable es más delicado de lo que parece. Una prueba de "intenta escribir un fichero temporal" da falsos resultados sobre el montaje FUSE-T respaldado por NFS. La señal honesta es la que usa Utilidad de Discos: el flag MNT_RDONLY de statfs(2). Eso es lo que te dice que un volumen está realmente montado en solo lectura, para poder ofrecer remontarlo como escribible en vez de adivinar.

Lo que de verdad lo hace distribuible: la firma

Nada de esto sirve si el sistema operativo bloquea los binarios. Una build distribuible necesita:

• Hardened Runtime + firma Developer ID + notarización en cada binario empaquetado — fuse2fs, ntfs-3g, e2fsck, mke2fs y compañía, además de la app y el CLI.
• fuse2fs y ntfs-3g cargan la librería de FUSE-T, firmada por un equipo distinto, así que necesitan desactivar la validación de librerías (com.apple.security.cs.disable-library-validation) o el sistema los mata al arrancar.
• Montar como usuario normal sin pedir contraseña cada vez requiere un helper privilegiado. SMAppService (macOS 13+) registra un demonio helper con el que la app habla por XPC — que es también por lo que el montaje sin kext es, en la práctica, cosa de macOS 13+.

Acierta con esas tres cosas y tienes ext4 y NTFS en lectura/escritura en un Mac de serie con Acceso completo al disco y nada más — sin Recovery, sin kext, sin seguridad reducida.

Puedes montar todo esto tú mismo

Todo lo de arriba es open source: FUSE-T, e2fsprogs/fuse2fs, ntfs-3g. Si te gusta encajar scripts de build, entitlements de firma y un helper privilegiado, adelante — es un buen fin de semana. Omnimount es lo que obtienes cuando alguien ya hizo eso y lo envolvió en una app de barra de menú; es GPL-3.0, así que puedes leer exactamente cómo encaja cada pieza.