# ntfsmac: NTFS Read/Write on Apple Silicon Without a Kernel Extension

> ntfsmac runs a Linux microVM to write to NTFS and ext2/3/4 volumes, then exports the result to macOS over NFS. It is Apple Silicon only, and it asks for Full Disk Access before it will mount anything.

**khr898/ntfsmac** — NTFS read/write on Apple Silicon macOS — no kernel extension, no SIP modification.

- Repository: https://github.com/khr898/ntfsmac
- Stars: 602 · Forks: 23
- Language: Swift
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/khr898-ntfsmac

## The NTFS write problem ntfsmac is aimed at

macOS reads NTFS volumes but does not write to them. The README states this plainly, and it also states why the two usual workarounds are getting harder: a kernel extension is blocked by newer SIP policy, and the alternative is a paid third-party driver. ntfsmac takes a third path. A disposable Linux microVM performs the actual NTFS write, and macOS mounts the result over NFS.

The target user is narrow and specific. The README lists Apple Silicon (arm64) only, with no Intel fallback, and macOS 13.0 or later. If you are on an Intel Mac, this project is not for you, and the README does not pretend otherwise. The second audience is people who already tried a kext-based driver and hit the System Extension approval flow. ntfsmac avoids that flow entirely, which is the point of the project rather than a side effect.

There is a secondary capability worth noting: the same microVM mounts ext2, ext3 and ext4 partitions. The README says the guest kernel's built-in ext4 driver handles all three, blkid auto-detects the type, and no --fs-driver flag is needed. That makes ntfsmac a general Linux-filesystem bridge for macOS, not only an NTFS tool.

## How the microVM, NFS export and vmnet bridge fit together

The mechanism is a chain, and each link matters. ntfsmac wraps anylinuxfs, which the README describes as a libkrun microVM running ntfs-3g. That guest does the filesystem work. The result is exported to macOS over NFS on a host-only vmnet bridge. So the mount you see in Finder is an NFS client mount, not a local filesystem driver.

That design has consequences the README makes visible. Because the transport is NFS, the CLI exposes client-side mount options such as --read-only, which the README describes as a client-side read-only NFS mount (ro). The NFS layer is also why the project cares about transport diagnostics: the README says the GUI reconciles anylinuxfs session evidence with the host NFS mount table, and that diagnostics fail closed unless an active ntfsmac mount uses the expected private vmnet path and effective soft NFS parameters.

The firewall handling is the part most likely to surprise you. The README says each mount owns its evaluated PF child anchor, its PF enable reference, and only the exact VPN-bypass host route it needs, and that teardown never flushes global PF state or removes another session's route. Related to that, --preserve-private-relay bypasses host pfctl -E so iCloud Private Relay keeps working while the /32 endpoint host route is still installed to prevent VPN tunnel capture. If you run a VPN and have watched other mount tools break it, this is the design detail to read first.

Multiple concurrent mounts are supported. The README says the CLI mounts each device independently and the GUI lists every mounted drive with its own status and speed indicator, replacing an older single-drive combined readout.

## Installing ntfsmac from the Homebrew tap and running a first mount

The CLI installs from a Homebrew tap. The README gives these three commands, and the third is a health check rather than a mount, so run it before you attach anything.

```bash
brew tap khr898/ntfsmac
brew install ntfsmac
ntfsmac diagnose
```

Expect the tap and install steps to take a moment, then expect diagnose to print environment, bridge and helper health information. The README also documents a structured variant, ntfsmac diagnose --json, which it describes as a structured JSON health check for bug reports. If diagnose reports a permission problem, that is the Full Disk Access guidance the README says the project added: automated FDA detection that points you at helper permissions after setup and in diagnostics.

Mounting is one command. Omit the device identifier and ntfsmac presents a menu of connected drives.

```bash
ntfsmac mount
ntfsmac mount disk4s1
ntfsmac mount disk4s1 --read-only
```

The README uses disk4s1 as the example partition identifier; the general form is diskNsM, and an unpartitioned whole disk is diskN, for example disk4. With no mount point given, the default is /Volumes/<label>, so after a successful mount you should see the volume appear there. For a first run, use --read-only on a disk you do not want to modify, confirm the volume appears and its contents are readable, then unmount.

```bash
ntfsmac unmount disk4s1
```

The README states the installer pre-provisions and configures the Alpine Linux microVM runtime upfront, which it says eliminates first-mount download wait times. It also states the runtime pulls an immutable Alpine arm64 digest and keeps versioned caches side by side. That is a claim about the installer's behaviour, not a measurement.

BitLocker volumes add one step. The README shows that a plain mount prompts for the password, and that a scripted mount reads the credential from stdin so it never lands in argv, process lists or shell history.

```bash
echo "$KEY" | ntfsmac mount disk4s1 --bitlocker-credential-stdin
```

The README says the password is kept strictly in transient memory during mount and is never stored in macOS Keychain, app settings, or disk files. The GUI is a separate download: an ad-hoc-signed .dmg from Releases, which the README says is not distributed as a Homebrew cask.

## Where ntfsmac gets in your way

The first limitation is the platform. Apple Silicon only, macOS 13.0 or later, no Intel fallback. That is a hard boundary stated in the README, not a soft recommendation.

The second is the signing story. The README says the GUI .dmg is ad-hoc-signed and explicitly not distributed as a Homebrew cask, and it points readers to a Signing & distribution section for the reason. Ad-hoc signing means Gatekeeper has no notarization to check against, so expect the usual macOS warnings on first launch. The README does not document a notarized build path, and it does not document rollback for the in-app updater, which the README describes as streaming download progress, verifying bundle integrity and relaunching with active-mount protection.

The third is the dependency chain. ntfsmac wraps anylinuxfs, which runs ntfs-3g inside a libkrun microVM. Three layers, each with its own version. The README acknowledges this by listing version reporting as a diagnostic feature: expected and detected host-runtime versions, audited source commits, the installed Alpine/cache version and guest package versions. When a mount fails, the failure can live in any of those layers.

The fourth is the NFS transport itself. An NFS client mount over a host-only vmnet bridge is not the same as a local filesystem. The README's own diagnostics treat the private vmnet path and soft NFS parameters as conditions that must hold, and fail closed otherwise. If your environment interferes with vmnet or with PF, you are outside the supported path. The README does not describe a fallback transport.

Finally, ext support arrives through the same microVM, so ext mounts carry the same prerequisites: Full Disk Access, the helper, and the bridge. The README says --ignore-permissions is passed automatically for ext drives, which maps ownership to the local user via all_squash. That is convenient, and it also means the ownership you see is not the ownership on disk.

## How ntfsmac differs from Paragon, Mounty and paid NTFS drivers

The related searches around this project are dominated by commercial drivers and by Mounty, so the comparison is worth making explicit rather than implied.

The paid drivers in that list are closed-source products that install their own filesystem components on macOS. ntfsmac does not write an NTFS driver at all. It runs ntfs-3g inside a Linux guest and hands macOS an NFS mount. The difference in approach is the reason the project exists: no kext, no SIP modification, no System Extension approval. It is also the reason ntfsmac carries a microVM and a network bridge where a driver would carry only a kext.

Mounty is a different kind of comparison. It is well known for remounting NTFS volumes read/write using macOS's own driver, which means it inherits whatever limitations that driver has. ntfsmac does not use the macOS NTFS driver by default; the README states the default is ntfs-3g, with --fs-driver ntfs3 available to opt into the kernel ntfs3 driver. That flag is the one place ntfsmac comes close to the remount approach, and it is an opt-in rather than the default.

Against commercial tools, the trade is licensing and support. ntfsmac is MIT-licensed, so you can read the source and the third-party licence file. What you give up is a vendor support contract and a notarized installer. The README's own diagnostics section reads like a project that expects users to file bug reports with structured output rather than call a support line.

One capability in the README has no obvious equivalent in the paid-driver framing: ext2/3/4 mounting through the same path. If your reason for looking at NTFS tools is really "I need to move files between macOS and Linux disks," ntfsmac covers both cases with one install.

## Maintenance, updates and what the MIT licence leaves to you

The repository is not archived, and the last push was on 2026-09-15, two days before this writing. Releases are frequent and recent: v3.1 on 2026-09-15, v3.0 the same day, and v2.3 on 2026-09-03. The README's What's new list maps closely onto those releases, covering in-app updates, the pre-installed Alpine runtime, Full Disk Access guidance, BitLocker support, ext support, concurrent mounts, diagnostics and the per-session PF handling. Whatever else is true, this is not an abandoned repository.

Upgrade cost is mostly the runtime, not the binary. The README says the runtime pulls an immutable Alpine arm64 digest and keeps versioned caches side by side, and that packaging rejects floating image references. That design means an upgrade can leave an older cached runtime on disk rather than overwriting it. The README does not state a cache eviction policy or a cleanup command, so budget disk space for side-by-side runtimes and check the diagnostics output for the installed Alpine and cache version after upgrading.

The GUI adds its own update path: the README describes checking for updates in the GUI Settings window, streaming download progress, verifying bundle integrity, and relaunching with active-mount protection. Active-mount protection is the detail to care about, because relaunching while a volume is mounted is exactly when a filesystem tool can do damage. The README does not describe what happens if integrity verification fails.

Licensing is MIT for ntfsmac itself. That is permissive, and it is also not the whole picture: the project vendors and wraps other software, and the repository carries a THIRD_PARTY_LICENSES.md at the top level alongside LICENSE. If you are redistributing ntfsmac or bundling it into a product, read that file rather than assuming MIT covers everything in the tree. This is a description of what the repository contains, not legal advice.

## Conclusion

Adopt ntfsmac if you are on an Apple Silicon Mac running macOS 13.0 or later, you are comfortable granting Full Disk Access to a privileged helper, and you want an MIT-licensed path to NTFS writes that does not touch SIP or load a kext. Do not adopt it on an Intel Mac, since the README states there is no Intel fallback, and do not adopt it if you need the GUI without Gatekeeper friction, because the README says the .dmg ships ad-hoc-signed rather than notarized. Before trusting it with a disk you care about, run ntfsmac diagnose and read the JSON it prints, then mount a scratch NTFS volume read/write and confirm the NFS mount appears under /Volumes before you point it at a backup drive.

## FAQ

### Can I use NTFS on my Mac?

macOS has no native NTFS write support, which the ntfsmac README states directly. ntfsmac provides write access by running ntfs-3g inside a Linux microVM and exporting the result to macOS over NFS.

### How do I read NTFS on my Mac?

macOS can already read NTFS volumes. To read one through ntfsmac instead, install it from the Homebrew tap and run ntfsmac mount with the partition identifier, or run the bare command to pick from connected drives; the README notes the default mount point is /Volumes/<label>.

### What is ntfsmac?

ntfsmac is a Swift project that wraps anylinuxfs, a libkrun microVM running ntfs-3g, and exports the mounted filesystem to macOS over NFS on a host-only vmnet bridge. The README describes it as CLI first, GUI second, and notes it also mounts ext2, ext3 and ext4 partitions.

### Is ntfsmac an alternative to Paragon NTFS for Mac?

It solves the same problem by a different route. The paid drivers install their own filesystem components on macOS, while ntfsmac does not write an NTFS driver and instead runs ntfs-3g in a Linux guest, so there is no kernel extension and no SIP modification. The trade is that ntfsmac carries a microVM runtime and an NFS transport.

### Is exFAT or NTFS better for Mac?

The ntfsmac README does not compare the two or recommend one over the other. It only addresses how to get read/write access to NTFS and ext2/3/4 volumes on Apple Silicon macOS.

### Do I really need NTFS for Mac?

The README does not answer this. It states only that macOS does not have native NTFS write support and presents ntfsmac as one way to get it, alongside paid drivers and kernel extensions.

## Sources

- [Issues](https://github.com/khr898/ntfsmac/issues)
- [khr898/ntfsmac on GitHub](https://github.com/khr898/ntfsmac)
- [License: MIT](https://github.com/khr898/ntfsmac/blob/main/LICENSE)
- [README](https://github.com/khr898/ntfsmac/blob/main/README.md)
- [Releases](https://github.com/khr898/ntfsmac/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/khr898-ntfsmac