macOS Won't Write to Your NTFS Drive — Four Ways Around It

You plug in a Windows-formatted SSD. It shows up in Finder, you drag a file onto it, and nothing happens. Or you get "The volume is read-only."

Nothing is broken. macOS has read NTFS for years and has never written to it — NTFS belongs to Microsoft, and Apple never took on the job of guaranteeing it. So the drive mounts, you can copy things off it, and writing is blocked on purpose. That has been true in every macOS release so far.

Before installing anything, answer one question: is this a one-off transfer, or a drive you use every day? Most write-ups skip straight to "install this driver," which is how people end up carrying kernel extensions they did not need.

First, check what you are dealing with

Thirty seconds in Terminal:

mount | grep -i ntfs          # look for "read-only" in the options
diskutil info /Volumes/NAME   # file system, mount mode, writability
sw_vers                        # your macOS version

read-only in the mount options means you are in the ordinary case, and the rest of this applies. If the volume does not appear at all, or macOS offers to initialise it, stop here — that is usually BitLocker or a damaged partition table, and no driver will help until you sort that out.

Two more things quietly rule options out:

• Your macOS version. The user-space route further down only exists from 15.4 onward.
• Whether the Mac is managed. Run profiles status -type enrollment. If it is enrolled in MDM, some of these paths are closed by policy no matter what you install.

Option 1 — install nothing

Sometimes you just need a handful of files. Copy them out and you are done; a network share, a cloud folder or a spare exFAT stick covers it with no software at all.

I put this first because it is the honest answer for a one-off transfer, and because it is the only one that does not sell you anything. The picture changes when the drive is a working drive: you edit on the Mac, the file has to go back, and it happens every day. That is where installing something starts to make sense.

Option 2 — reformat to exFAT

exFAT reads and writes on both systems with no extra software. Most forum threads end right there.

What they tend to leave out: exFAT has no journal. NTFS keeps a transaction log ($LogFile) and can often recover a volume that was unplugged mid-write, while exFAT has nothing to roll back to — an interrupted write can leave the directory structure damaged. You also lose Windows ACLs, and large folders of small files get noticeably slower.

On a USB stick you swap files with, that is a fair trade. On a drive holding work you cannot recreate, it isn't.

Option 3 — macFUSE + ntfs-3g

The old community answer, and it does work. The source is readable, and the project has taken in something like two decades of odd edge cases. Below macOS 15.4 it is the usual free route; the commercial drivers run on those versions too, if you would rather pay.

The install is the painful part on Apple silicon. Boot into Recovery Mode, enable Reduced Security, approve the kernel extension in System Settings. That is Apple's deliberate policy for kernel-level code, not an oversight in the process.

That Recovery Mode step is where a lot of installs stall. On a company-managed Mac, MDM policy may forbid the security downgrade outright, and you will not get past the first step. A major OS upgrade can ask you to approve the extension again before the drive mounts. And the extension sits in the storage path, so a bug in it is a kernel bug — the blast radius is the machine, not one process.

Reasonable pick if your Mac is below 15.4, or if reading the driver's source matters to you.

Option 4 — a user-space file system module (macOS 15.4+)

macOS 15.4 shipped FSKit, Apple's framework for implementing file systems outside the kernel.

Since none of it runs in kernel space, the install looks like any other app: no Recovery Mode, no Reduced Security, no restart. A crash stays a process-level event, and OS upgrades ride along with the app's own updates instead of triggering another approval round.

You pay for that in version support and maturity. FSKit starts at 15.4, and nothing built on it has been around as long as ntfs-3g.

DiskBee (published as NTFSProKit) is one implementation — described on the vendor's site. I work with the team behind it, so read the next few lines as a description rather than a pitch:

• No kernel extension, so it installs on MDM-managed machines that block the security downgrade.
• BitLocker volumes unlock with a password or the 48-digit recovery key, and writes are re-encrypted on the fly so the drive still opens on a Windows PC.
• The free tier is read-only, permanently — browse, copy out, read BitLocker. Writing needs the one-time Pro license (USD 15.00 list price as of 2026-11; regional pricing and any change live on the vendor site).
• Everything runs locally; file names and contents are not collected.

The limits are just as plain. macOS 15.4 or later, no exceptions — on 15.0–15.3 this option does not exist for you, and option 3 is the answer. The free tier will not write, by design, so if writing is the entire point, it does not solve your problem.

Picking one

A one-off transfer: copy the files off and skip all of this. A drive whose contents you could lose: exFAT. Below 15.4, or you want to read the source: macFUSE + ntfs-3g. 15.4 and up, an MDM-managed machine, or a BitLocker volume you need to write to: the user-space module.

Disclosure: I work with the team that publishes DiskBee. The limitations above are deliberately not softened.