Guide

macFUSE on modern macOS, and what replaced it

For fifteen years, “mount it on a Mac” meant macFUSE. Three separate things changed — Apple’s stance on kernel extensions, the boot policy on Apple silicon, and macFUSE’s own licence — and they get conflated into “macFUSE is dead”, which is not true. Here is what actually changed, what still works, and what to use instead, including the options that are not ours.

What macFUSE is

FUSE is an interface for writing a file system as an ordinary program instead of as kernel code. macFUSE is the macOS implementation: a kernel extension that receives file system operations from the kernel and hands them to a program in user space. sshfs, most ext4 and NTFS drivers for the Mac, rclone mount, and a long list of commercial clients have all been built on it.

That design has one structural cost, and it is the cost that came due: the part that talks to the kernel is kernel code.

What changed

  1. Apple deprecated kernel extensions, and has not removed them

    Apple announced the replacement — System Extensions and DriverKit — at WWDC 2019 and has told developers since that kexts are no longer recommended because they put the integrity and reliability of the operating system at risk. What Apple has not done is announce a date for removing kext loading. So the honest statement is not “kexts no longer work”; it is “kexts still load, on a security policy Apple keeps narrowing, with no commitment to a next release”.

    Apple — kernel extensions and system security policy on Apple silicon ↗

  2. On Apple silicon, loading one means lowering the machine’s security

    A third-party kext needs Reduced Security plus Allow user management of kernel extensions from identified developers, both set in the Startup Security Utility from recoveryOS, then an approval in System Settings and a reboot. That is not a per-app permission: it is the boot policy of the whole Mac, and it is the step a managed or compliance-bound fleet is usually forbidden to take.

    macFUSE — Getting Started (wiki) ↗

  3. macFUSE is no longer open source, and no longer free to bundle

    The last fully open-source release was 3.8.3. The repository now says plainly that it carries the source of libfuse.dylib and macFUSE.framework and that “the other components, e.g. the macFUSE kernel extension, are closed-source”. From 3.10.0 the licence added: “redistributions bundled with commercial software are not allowed without specific prior written permission.” macFUSE remains free for personal and non-commercial use — but that clause is why paid Mac apps stopped shipping it, and why so many of them changed how they mount in the same couple of years.

    macFUSE issue #616 — the 3.10.0 licence change ↗

What still works

More than the internet suggests. macFUSE 5 is maintained and covers current macOS, including macOS 26. The kernel-extension backend still loads, on a Mac whose owner is willing to run it at Reduced Security. And macFUSE now ships a second backend built on FSKit, Apple’s framework for file systems in user space, which needs no kernel extension and no change to the machine’s security settings at all.

The detail that decides most cases: macFUSE’s FSKit backend covers local volumes from macOS 15.4, and non-local volumes — distributed and network file systems, which is what everything on this page is — from macOS 26. On macOS 14 and 15, a network mount through macFUSE still means the kernel extension.

What does not work

A kext on a Mac that must stay at Full Security

Reduced Security is a boot-policy change made from recoveryOS. On a Mac under mobile device management, or one whose compliance baseline requires Full Security, there is no version of the kernel-extension path that works. This is the case that sends most people looking for an alternative.

macFUSE — Getting Started (wiki) ↗

macFUSE inside a Mac App Store app

A sandboxed App Store app cannot install a kernel extension, and the licence forbids bundling with commercial software without written permission in any case. Both halves have to be false for it to work; neither is.

macFUSE issue #616 — the 3.10.0 licence change ↗

sshfs as a maintained project

sshfs still works, and for many people works well. But its own repository says it plainly: “SSHFS does not have any active, regular contributors, and there are a number of known issues.” Treat it as something you run knowingly, not as something under active development.

libfuse/sshfs — development status ↗

The alternatives, including the ones that are not us

A page that answers “macFUSE alternative” with one product deserves to rank badly. Most of these are free, several are already on your Mac, and for a lot of people one of them is simply the right answer.

macFUSE 5, FSKit backend

macFUSE itself, running the file system in user space instead of in the kernel.

Kernel extension
No
Needs
macOS 15.4 or later for local volumes; macOS 26 or later for non-local (network) volumes
Good for
Keeping an existing FUSE file system — sshfs, an ext4 or NTFS driver, anything already written against libfuse — without touching the boot policy.
Watch out
The split matters: almost everything on this page is a network file system, and macFUSE’s own notes put non-local volumes on the FSKit backend at macOS 26. Below that, a network mount still means the kernel extension. macFUSE’s documentation also still describes the kernel backend as the one with the best performance and full feature support.

macFUSE — releases and release notes ↗

rclone nfsmount

rclone starts an NFS server on loopback and lets macOS’s own NFS client mount it.

Kernel extension
No
Needs
rclone, and nothing else installed
Good for
Anyone already using rclone. No third-party software, no kernel extension, no root.
Watch out
rclone documents that on macOS the mount is read-only unless you pass --vfs-cache-mode, and that a cloud remote is not as reliable as a file system — NFS gives it fewer places to retry than FUSE did. Bucket remotes cannot store empty directories.

rclone — nfsmount ↗

FUSE-T

A kext-free FUSE for macOS: libfuse talks to a local NFS, SMB or FSKit server instead of a kernel extension.

Kernel extension
No
Needs
Installing FUSE-T; software built for libfuse
Good for
Existing FUSE software on a Mac that must stay at Full Security.
Watch out
A different implementation with a different feature surface — its own docs note the API differs from Linux libfuse. Behaviour under it is not identical to macFUSE.

FUSE-T ↗

Plain NFS

macOS’s built-in NFS client, mounting an export from the server directly.

Kernel extension
No
Needs
A server you control that exports NFS
Good for
A Linux or BSD server on your own network. Nothing to install, and it is the fastest of these by a wide margin.
Watch out
Only works if you administer the server. UID/GID mapping is yours to get right, and NFS over the open internet needs a VPN in front of it.

SMB

macOS’s built-in SMB client — Finder’s Connect to Server, or mount_smbfs.

Kernel extension
No
Needs
An SMB server: a NAS, a Windows box, Samba
Good for
A NAS. This is the best-supported network file system on macOS and, when it is an option, it is usually the right answer.
Watch out
Not an option at all for object storage or a consumer cloud. Finder’s SMB has its own long-running quirks with reconnection after sleep.

Built-in WebDAV

Finder’s Connect to Server, with an https:// address.

Kernel extension
No
Needs
A WebDAV server
Good for
A quick look at a Nextcloud or a hosting provider’s WebDAV endpoint, with nothing installed at all.
Watch out
Apple’s WebDAV client is the weakest of the three built-ins — slow directory listings, awkward reconnection, and a long tail of servers it will not authenticate against.

Mountit

Ours

What this site sells: a Rust core and a SwiftUI app that bring remote storage into Finder, with no kernel extension.

Kernel extension
No — and there is no version of Mountit that has ever shipped one
Needs
macOS 14 or later
Good for
Object storage and consumer clouds as well as file protocols, with a cache built for Finder, credentials in the Keychain, and an evidence level published per service.
Watch out
It is commercial, and it is not a general FUSE runtime: it mounts the services it implements, not any file system you can write. It mounts through File Provider — a location in Finder’s sidebar, not a volume in /Volumes. An FSKit module for a real volume ships in the Mountit Pro build and does not mount yet.

What Mountit does →

Where Mountit fits, and where it does not

Mountit has never shipped a kernel extension. It mounts through File Provider — a location in Finder’s sidebar rather than a volume in /Volumes — on every macOS version and in both editions. An FSKit module for a real volume ships inside the Mountit Pro build and does not mount yet. Neither path asks you to change your Mac’s boot security.

The cases where it is not the right tool, stated plainly:

  • You administer the server. Export it over NFS or SMB and use macOS’s built-in client. Faster, free, and nothing to install.
  • You want to run an arbitrary FUSE file system. Mountit is not a FUSE runtime. It mounts the services it implements. macFUSE’s FSKit backend or FUSE-T is what you want.
  • You are already happy in a terminal with rclone. rclone nfsmount costs nothing and does a lot of this.

What is left is where we think it earns its price: object storage and consumer clouds alongside file protocols, a cache built for the way Finder actually asks for things, credentials in the Keychain, and an evidence level published per service so you can see which ones have been mounted against a real server and which have not.

What Mountit actually does The evidence per service Compared with ExpanDrive and more

Questions

Does Mountit need macFUSE?

No. Mountit has never shipped a kernel extension and does not use FUSE at all. It mounts through File Provider — a location in Finder rather than a volume in /Volumes — on every macOS version and in both editions. Nothing you install changes your Mac’s boot security policy.

An FSKit module, for a real volume on macOS 26, ships inside the Mountit Pro build. It does not mount yet: it needs the File System Extensions consent only you can grant, and past that the network-URL path FSKit uses still fails on macOS 26.6 for Apple’s own modules too.

Is macFUSE dead?

No, and saying so would be wrong. macFUSE 5 is maintained, supports current macOS, and has gained an FSKit backend that runs in user space with no kernel extension and no security change. What changed is the cost of the kernel path on Apple silicon, and the licence, which stops commercial software bundling it without written permission.

Can I keep using the macFUSE kernel extension?

Yes, if you are willing to put the Mac into Reduced Security and enable user management of kernel extensions from identified developers, both from recoveryOS, then approve the extension in System Settings and reboot. That is a decision about the whole machine, not about one app — which is exactly why it is refused on managed fleets.

What is FSKit, and how is it different?

FSKit is Apple’s framework for implementing a file system as an ordinary app extension, in user space, introduced in macOS 15.4. Nothing runs in the kernel, so an Apple silicon Mac can stay at Full Security with third-party file systems installed. A crash takes the extension down, not the machine.

I only want to mount an SFTP server. What is the least I can install?

If you administer the server, export it over NFS or SMB and use macOS’s built-in client — nothing to install, and faster than any of the alternatives here. If you cannot, rclone nfsmount needs one binary and no kernel extension; pass --vfs-cache-mode or the mount will be read-only. Mountit is the paid option, and it is the right one mainly when you want Finder integration, a cache tuned for it, and services beyond what NFS and SMB reach.

Why is a competing product recommending competitors?

Because the alternative is a page that ranks for “macFUSE alternative” and then answers a question nobody asked. If NFS or SMB solves your problem, they solve it better than we do and for nothing. We would rather be the honest result for the cases we are actually best at.

Sources

Every claim on this page about somebody else’s software came from one of these, read on 1 September 2026. Third-party facts age; if one of these has moved on and this page has not, tell us and it gets corrected.