For about fifteen years, writing to an NTFS volume on a Mac has meant one of two things: buy a commercial driver, or install macFUSE and ntfs-3g and accept the consequences. Both approaches share a structural assumption that no longer holds cleanly on Apple Silicon — that a third party is allowed to drop a kernel extension into the storage stack.
This post is about why that assumption is fraying, and what replaced it.
1. What the kext route actually costs
macFUSE ships a kernel extension. On modern macOS, loading it requires booting into Recovery Mode, enabling "Reduced Security," and approving the extension in System Settings. That is not a bug or an oversight — it is the platform's stated position on kernel-level code, and it is reasonable. But the practical consequences are real:
- Any machine under MDM policy may forbid the security downgrade outright.
- The approval survives reboots, but not always major OS upgrades.
- Once a kernel extension is in the storage path, a bug in it is a bug in the kernel. A panic takes the whole machine with it, not one process.
None of this makes macFUSE wrong. It remains the most transparent option, and ntfs-3g is a genuinely impressive piece of software maintained by people who deserve better funding. It is simply a 2000s-era architecture being run in a 2020s security model.
2. What FSKit changes
macOS 15.4 introduced FSKit: a user-space framework for implementing file systems. Apple's own newer file systems use it. The important property is where the code runs — in user space, as an ordinary app-adjacent module, not in the kernel.
The tradeoffs invert:
| Kernel extension (macFUSE + ntfs-3g) | User-space module (FSKit) | |
|---|---|---|
| Install | Recovery Mode, Reduced Security, approval | Normal app install |
| Failure blast radius | Kernel panic possible | Process-level |
| OS upgrade survival | Requires re-approval sometimes | Follows app updates |
| Works on | Wide range of macOS versions | macOS 15.4+ only |
| Maturity | ~20 years of edge cases | Young API surface |
That last row matters, and I will come back to it.
3. Why the storage layer is a bad place for a bug
NTFS is not a simple format. A dirty volume — one that was unplugged mid-write, or left behind by a crashed Windows box — carries a transaction log that must be replayed before the volume is safe to touch. A driver that skips log replay and starts writing is how people lose directories.
The more defensible designs do three things: replay the log at mount, run structural checks (MFT records, cluster allocation, directory indexes) rather than trusting the header, and refuse to guess when damage is deep — handing the volume back to chkdsk on a Windows machine, which is the only tool with full knowledge of the format's repair semantics.
That last point is the one most tools get wrong. "Repair" that silently zeroes a corrupt MFT record is worse than no repair at all.
4. One concrete FSKit implementation
DiskBee (published as NTFSProKit) is an FSKit-based NTFS read-write driver. I have a working relationship with the team, so treat the following as a description rather than an endorsement.
What is architecturally interesting:
- No kernel extension, therefore no Recovery Mode, no Reduced Security, no restart — the install path that MDM administrators can actually approve.
- BitLocker support: password or recovery key, with write operations re-encrypted in real time so the volume stays valid when it goes back to Windows.
- Formatting to NTFS through the system's own disk utility path rather than a third-party partitioner.
- A speed test that measures through the NTFS engine itself rather than through the raw block device — which is the number that actually predicts what you will see when copying files.
What is not: it requires macOS 15.4 or later, full stop. On a 15.2 machine this entire approach is unavailable and macFUSE remains the answer. The Free tier is read-only by design (browse, copy out, BitLocker read) — writing requires the one-time Pro license. And the FSKit API is young; a twenty-year-old ntfs-3g has seen edge cases that a 2025-era implementation has not.
5. How to choose
- Corporate Mac, MDM-managed, security posture matters → user-space, if the OS is new enough.
- macOS 15.0–15.3, or you want to read the driver's source → macFUSE + ntfs-3g.
- One-off transfer, small files → copy to exFAT or over the network; do not install anything.
- BitLocker volumes → check explicitly that your tool supports write with re-encryption, not just read.
The structural point stands regardless of vendor: the kernel is no longer where this problem gets solved on macOS, and any 2026 comparison table that ignores FSKit is already out of date.
Disclosure: I work with the team that publishes DiskBee. I have kept the limitations section as blunt as the feature list.
Top comments (0)