Free-NTFS-for-Mac: open source NTFS read-write on macOS, with the write limits stated up front
Nigate: An open-source NTFS utility for Mac. It supports all Mac models (Intel and Apple Silicon), providing full read-write access, mounting, and management for NTFS drives.
At a glance
- What is it?
- Nigate mounts NTFS volumes read-write on Intel and Apple Silicon Macs, with an Electron interface and a shell-script path. The repository is unusually candid about the one thing it cannot do: in-place edits of existing files.
- Who is it for?
- Nigate is a good fit when the machine already has NTFS media it cannot reformat and reformatting would cost data or time. It is the wrong tool when you need full-featured NTFS editing, because the interface cannot overwrite a file in place and the workaround is copying it to APFS, editing, and copying it back.
- Can I use it commercially?
- Yes. Zlib is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 11, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The gap Nigate fills is write access, not mounting
macOS can read NTFS volumes out of the box. What it will not do is write to them, so a Windows-formatted drive arrives on a Mac as a read-only volume and Finder offers no way to change that. Nigate exists to close that specific gap, and the repository description states the scope precisely: full read-write access, mounting and management, across every Mac model, both Intel and Apple Silicon.
The technical route is the one NTFS-3G and its AnyLinuxFS descendant established. A kernel extension plus the FUSE layer takes over the mount and translates POSIX writes into NTFS operations. The repository topics name the whole stack, including `ntfs-3g`, `ntfstool`, `anylinuxfs`, `macntfs`, `macfuse`, `arm` and `m1`, which tells you this is built on the existing FUSE approach rather than inventing a new driver. That also tells you why administrator privileges are non-negotiable: installing and loading a kernel extension is a privileged operation, and the README is upfront that the system will prompt for a password during mounting.
The interesting part is that the tool outgrew its original name. The project began as a geek terminal utility and now ships an Electron interface on top, while keeping the shell scripts as the lower layer. Both are documented, and both are worth knowing about, because the terminal path does things the GUI does not.
An Electron shell over a folder of shell scripts
GitHub reports TypeScript as the primary language, and `package.json` shows why. The app is Electron 28.3.3 with `electron-builder`, TypeScript for the logic, Stylus for styles, `node-pty` for a real terminal inside the window, and `marked` for rendering documentation. The product is called Nigate, the bundle identifier is `io.hoochanlon.github`, and the icon path in the build config points at a flash-themed `.icns` file.
The `ninja/` directory holds the scripts that do the actual work, and `package.json` wires the whole thing to them. `setup` calls `ninja/izanaki.sh`, and the build targets pass architecture flags straight through to `ninja/build.sh`:
"build": "./ninja/build.sh",
"build:dmg": "./ninja/build.sh --dmg",
"build:arm64": "./ninja/build.sh --arm64",
"build:x64": "./ninja/build.sh --x64",
"build:universal": "./ninja/build.sh --universal"Those five targets cover the practical cases: a signed DMG, a plain build, an Apple Silicon binary, an Intel binary, and a universal binary for people who move between machines. There is also `pnpm run start` for local development, which builds and launches Electron with `--dev`, and a `watch:all` script that runs the TypeScript and Stylus watchers together.
One detail in the dependency list deserves attention: `npmRebuild` is set to false in the build configuration, and the Electron download is pointed at a mirror with its own cache directory. Both choices suggest a build that has to work behind restricted networks, which fits the audience this tool serves.
One command installs the terminal version, and LANG picks the language
The quickest path documented is a single curl-and-bash invocation pasted into a terminal running with full administrative privileges. It fetches `ninja/nigate.sh` from a CDN mirror and runs it:
/bin/bash -c \"$(curl -fsSL https://cdn.statically.io/gh/hoochanlon/Free-NTFS-for-Mac/main/ninja/nigate.sh)\"The same block appears three times in the README, differing only by a `LANG` prefix, which sets the interface language for the Japanese and Chinese variants. That same convention applies to the dependency installer `ninja/kunai.sh` and the uninstaller `ninja/ninpo.sh`, so installing and removing the FUSE dependencies is a matched pair of one-liners rather than a manual procedure.
The second documented method avoids running a script from the network altogether. You download it, then create a symlink in `/usr/local/bin` plus a shell alias, and the script is available as a bare command afterwards:
curl https://fastly.jsdelivr.net/gh/hoochanlon/Free-NTFS-for-Mac/ninja/nigate.sh > ~/Public/nigate.sh && sudo -S mkdir -p /usr/local/bin && cd /usr/local/bin && sudo ln -s ~/Public/nigate.sh nigate.shortcut && echo \"alias nigate='bash nigate.shortcut'\" >> ~/.zshrcFor the graphical path, binaries are published through GitHub tags rather than installed from source. That matters for a tool that needs a kernel extension: users are not expected to have Node, pnpm and a macOS signing identity on hand.
The write limitation that should decide your editor
This is the part of the documentation worth reading twice, because it is where most NTFS tools would rather stay quiet. The GUI application cannot modify data in place inside an existing file. It lacks the kernel write permission for that. What it does support is metadata-level work: copy, cut, delete and rename.
The practical consequence is narrow but real. If you open a document from the NTFS volume in an editor that rewrites the file in place, you can corrupt it. The README's recommendation is to use an editor that supports atomic write, naming VS Code and Kate as examples, because those tools save by creating a new file and replacing the old one, which avoids the overwrite path the GUI cannot service. The alternative it offers is to copy the file to the Mac's own filesystem, edit it there, and copy it back.
There is one exception, and it lives in the terminal layer. The Ninja Tools script `kamui.sh` does support direct in-place modification of files on the mounted volume, for cases where that is genuinely required. So the choice is not only about editors: the GUI and the shell scripts have different write capabilities over the same mount, which is a slightly odd split but a documented one.
The `kamui.sh` script also reaches beyond NTFS. It supports ext2, ext3 and ext4, btrfs, xfs, zfs, exFAT, LUKS encryption, LVM and RAID, so the same toolbox handles Linux-formatted volumes, encrypted containers and logical volume stacks on a Mac. That is a considerably wider claim than the project name suggests, and it is the reason the tool is organized around scripts rather than around a single driver.
Gatekeeper, SIP and the pre-flight checks that trip people up
Before any mounting happens, the README lists the conditions that cause failure, and each one has a concrete fix. Unsigned applications trip Gatekeeper on first launch, and the documented escape hatch is a system policy command:
sudo spctl --master-disableAfter that, the Anywhere option appears under System Settings, Privacy & Security. Turning off a security control to run an unsigned build is a real trade-off, and it is worth being clear-eyed about it: you are accepting the risk of an unsigned binary loading a kernel extension.
System Integrity Protection is the optional second half. Disabling it requires Recovery Mode: restart while holding the power button until the Apple logo and progress bar appear, open Terminal from the toolbar, and run `csrutil disable`. Afterward, `csrutil status` reports the current state. The README marks this step optional, which is the right call, since the dependency installer is designed to cover most cases without it.
Three non-security warnings are just as useful. Windows Fast Startup leaves the volume in a hibernated state that macOS cannot mount, so the drive must be fully shut down in Windows or Fast Startup turned off. USB drive names cannot contain spaces or illegal characters. And a drive that has been used to build bootable media, such as one formatted with Ventoy or WePE, can take noticeably longer to mount read-write because of its partition layout.
Release cadence, the reset button, and the licence discrepancy
Three releases are recorded, all of them from January 2026. v1.4.4, published on 2026-01-22, added official Intel Mac support, expanded the installation guide and cleaned cache files out of Git history so forks became smaller. v1.4.5 followed the next day, focused on practical operations such as quickly opening a USB drive, plus a repair feature and interface work. A `beta` tag sits alongside them, explicitly marked experimental and not fully tested, with a stated requirement of macOS 14 or later.
That beta tag is worth a warning of its own. Downloading a `beta` build when a numbered release exists means picking untested code over tested code for no benefit, and the release notes say so directly.
The interface features are mostly about protecting a user from a user. There is real-time detection of NTFS devices as they are connected, an auto read-write switch that skips anything you have deliberately set to read-only, a tray mode, and a status protection you toggle by long-pressing for three seconds, which disables auto-mount, tray mode and sleep prevention together. A prevent-sleep toggle matters for long writes, since a machine that sleeps mid-write is how you lose an afternoon. The reset button is the non-destructive disk repair path, which is the right default when the alternative is a full format.
The licence needs a note. GitHub's metadata reports the repository as Zlib, while `package.json` declares MIT and a LICENSE file sits in the tree. If the licence matters to your use, read the LICENSE file directly rather than trusting either metadata field, since the two disagree and the file is the authoritative artifact.
Editorial conclusion
Nigate is a good fit when the machine already has NTFS media it cannot reformat and reformatting would cost data or time. It is the wrong tool when you need full-featured NTFS editing, because the interface cannot overwrite a file in place and the workaround is copying it to APFS, editing, and copying it back. The binary build comes from GitHub tags, so start from v1.4.5 rather than the beta tag, and read the reset button's warning before your first mount. The last push was on 2026-07-31.
Frequently asked questions
How do I get NTFS read-write access on a Mac?
macOS mounts NTFS volumes read-only by default. Nigate adds read-write support through an NTFS-3G based FUSE driver and a MacFUSE kernel extension. You can install it with a single curl-and-bash command run as administrator, or download a tagged build and use the Electron interface, in which case mounting will still prompt for your password.
Can I edit a file on an NTFS drive while it is mounted by Nigate?
Not directly in the GUI, which cannot modify data in place in an existing file because it lacks the kernel write permission for it. Copy, cut, delete and rename all work. For editing, the README recommends an editor that uses atomic write, such as VS Code or Kate, or copying the file to the Mac's own filesystem, editing there, and copying it back. The `kamui.sh` script does support direct in-place modification.
Why does the mounted NTFS drive fail to appear or fail to mount?
The README names the usual causes. If the drive was last used with Windows Fast Startup, the volume is hibernated and macOS cannot mount it, so shut the drive down fully in Windows or disable Fast Startup. A drive name containing spaces or illegal characters is also unsupported. A volume used to create bootable media such as Ventoy or WePE may simply take longer to mount read-write.
Is Nigate free, and what licence applies?
The source is published on GitHub under a Zlib licence according to the repository metadata, while `package.json` declares MIT and a LICENSE file exists in the repository. The two declarations disagree, so read the LICENSE file to see which terms actually apply to your intended use.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/hoochanlon-free-ntfs-for-mac)