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. Its source is public and auditable, 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. 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. Writing to a volume before its transaction log has been replayed is a risk taken on the user’s behalf — which is why log replay at mount is the first thing to look for in a driver’s design notes.
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 worth checking on any tool you evaluate: does it hand deeply damaged volumes to chkdsk on a Windows machine, or does it attempt a "repair" of its own on an MFT record it only partly understands? The answer is usually in the vendor’s documentation rather than the marketing page — and it is a question about design, not about who has the better product.
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 (diskutil).
- A speed test that measures through the NTFS engine itself rather than through the raw block device — closer to what you actually 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 a 2026 comparison that ignores FSKit is missing the biggest structural change.
Updated 2026-11: removed a statement about Apple's own file systems that I could not source, and reworded one passage that could be read as a claim about how other tools behave. No other changes.
Disclosure: I work with the team that publishes DiskBee. I have kept the limitations section as blunt as the feature list.
Top comments (2)
FSKit is still very raw. I hit so many problems building a filesystem on it that I dropped it for macFUSE.
The worst one was that low-priority callers stall whenever someone reads file data. Finder's Get Info runs at background I/O priority. While another process read uncached files on the volume, every lookup it made waited on a fixed delay, and on a big folder "Calculating Size" never finished. The same folder on exFAT showed its size at once.
My guess is that FSKit throttles file I/O served from the extension, since exFAT reads file data in the kernel.
Thanks for writing this up — that's concrete enough to reproduce, which is more useful than most feedback we get.
I won't claim we don't hit this. One thing worth putting on record: an Apple DTS engineer acknowledged on the developer forums (June 2025, thread 788609) that when a volume is probed, kext drivers take priority over FSKit — and that this basic behavior is "reasonably justifiable and difficult to address". That's about the probe/mount path, not about your runtime trace — I'm citing it only to say that a user-space driver is, at the system level, the later arrival. It's a property of the generation, not of one vendor's build, which is why I'd rather locate your case than wave it off.
Two things are still worth separating though:
Get Infothat never finishes can look like the same symptom and have nothing to do with each other."FSKit throttles I/O from the extension" is a reasonable hypothesis, but I don't think it's established yet.
If you're willing to share: macOS build number, volume size and file count, whether the volume was freshly mounted or long-lived, and the client that was doing the uncached read — that's enough to tell mount-path from runtime-path. Happy to pass it to the team; the support address on the site is the durable channel.
Disclosure: I work with the team that publishes DiskBee, so read this as a technical description, not an endorsement.