macFUSE Alternatives on macOS: What Works in 2026

What macFUSE actually is, and why people look for alternatives#

FUSE — Filesystem in Userspace — lets an ordinary program pretend to be a disk: it answers the questions the kernel would ask a real file system, and the result appears as a volume. macOS has no FUSE of its own, and macFUSE has supplied it for well over a decade. Almost every “mount this remote thing on a Mac” recipe online assumes it.

The project is not abandoned — version 5.3.3 shipped on 4 July 2026, supporting macOS 12 through 27 on Apple silicon and Intel, after six feature releases in a year. People go looking for alternatives because of what the kernel-extension path asks of them, and because the ecosystem around it has thinned out.

Kernel extensions and Reduced Security on Apple silicon#

macFUSE's original backend is a kernel extension. On an Intel Mac you approve it once in System Settings. On Apple silicon you also have to lower the machine's boot security, and that is the part people resent. The exact route, from Apple's own documentation:

1. Choose Apple menu › Shut Down.
2. Press and hold the power button until Loading startup options appears.
3. Click Options, then Continue, and authenticate as an administrator.
4. In the menu bar choose Utilities › Startup Security Utility.
5. Select your system volume, then click Security Policy…
6. Select Reduced Security and tick Allow user management of kernel extensions from identified developers.
7. Click OK, authenticate, and restart. The change only takes effect after the restart.

There are three levels. Full Security runs only the current OS or system software Apple currently trusts; Reduced Security allows any version Apple has ever trusted — which is what makes third-party kexts possible, and also what lets an older, since-patched macOS boot on that machine. On a laptop that leaves the house, that is a trade worth thinking about rather than a checkbox to click past. And it is not once-and-done: a kext is tied to the kernel it was built against, so a major macOS release can break the mount until a matching macFUSE arrives. That is the “my mount stopped working after the update” that fills the forums every September.

What changed: the FSKit backend and macOS 26#

Since macFUSE 5.1.0 (October 2025) there is a second backend that does not use the kernel extension at all. It is built on FSKit, Apple's user-space file system API, and you select it with a mount option:

sshfs user@example.com:/srv /Volumes/srv -o backend=fskit

The macFUSE home page puts it plainly: “Thanks to the new FSKit backend in macFUSE, supported file systems can now run entirely in user space on macOS 26. That means no more rebooting into recovery mode to enable support for the macFUSE kernel extension.”

Two qualifications matter for anyone mounting a server. First, FSKit arrived in macOS 15.4, but macFUSE could only mount “local” volumes with it — physically attached storage. Support for “non-local” volumes, which is what a network file system is, arrived only with macOS 26. On macOS 13, 14 or 15 the FSKit backend does not solve this problem at all.

Second, the backend is young, and its own documentation lists the gaps: mount points must live under /Volumes, files open in read/write mode only, the FUSE notification API is unsupported, most kernel-handled mount options are not implemented yet, and “I/O performance of FSKit volumes is not on par with volumes using the kernel extension backend.” There is also an open issue from December 2025 where sshfs on macOS 26.1 fails with File system named macfuse not found and mount(8) returned 69. So: promising, real, and not yet the thing you build a working day on.

Is macFUSE unsafe?#

No — and the honest answer is more interesting than the alarmist one. macFUSE is signed and notarised by Apple, and its documentation is explicit that it “does not require you to disable Gatekeeper or System Integrity Protection.” It is maintained by people who have been doing this carefully for years. Nothing about installing it is reckless.

The risk is architectural, not moral. Code in the kernel has no seatbelt: a bug in a file system driver is a panic, where the same bug in a user-space process is just a crashed process. That is why Apple has spent a decade moving drivers out of the kernel, and why FSKit and File Provider exist. Choosing against a kext is choosing the direction the platform is going, not casting doubt on anyone's code — and the cost you will actually feel is Reduced Security on the boot volume, a Recovery reboot to get there, and a mount that can break on a major upgrade.

Why Homebrew dropped macFUSE and sshfs#

If you have hit sshfs: command not found after a clean brew install sshfs, this is why. Starting with macFUSE 3.10.0 the licence stopped being open source: redistribution in binary form bundled with commercial software is not allowed without written permission. Homebrew does not accept non-open-source dependencies in homebrew/core, so macFUSE was moved to a cask and the formulae that depended on it — sshfs included — were removed.

Separately, sshfs itself is no longer maintained: issues and pull requests are disabled upstream and the maintainer invites anyone who wants it to fork and take over. It still works; nobody is fixing it. The community answer on macOS is the gromgit/homebrew-fuse tap, which carries sshfs-mac.

brew install --cask macfuse
brew install gromgit/fuse/sshfs-mac

What Apple provides instead#

Apple has shipped two separate answers, and confusing them is the single most common mistake in discussions of this topic. They solve different problems.

File Provider — the API behind iCloud Drive and Dropbox#

File Provider is how iCloud Drive, Dropbox, Google Drive and OneDrive put themselves in your Finder sidebar. An app ships an extension; macOS asks that extension for directory listings and file contents and materialises files locally when something opens them. The volume appears in the sidebar and under ~/Library/CloudStorage/, and any app using the standard Open and Save dialogs can reach it.

It has been in macOS for years, runs in user space, is sandboxed, and needs no approval in System Settings and no reboot. It was designed for remote storage — exactly the case in question. Where the volume appears and how it behaves is worth knowing before you pick a client, because it is the same for all of them.

FSKit — user-space file systems, and what it still cannot do#

FSKit is newer and lower-level: a public API since macOS 15.4 (private since 14.0) for implementing an actual file system as an app extension, with DiskArbitration integration, so it can back a real mounted volume. It is aimed at the kind of thing macOS itself ships — HFS, msdosfs, ExFAT, NTFS — and it is the mechanism macFUSE's new backend rides on.

Its limits are the ones listed above, and network-volume support only arrived with macOS 26 — so unless every Mac you support is on the current release, it is not yet something to standardise on.

Which one applies to remote servers#

For reaching an SSH server, a NAS or an object store: File Provider. It is on every macOS you are likely to support, needs no security downgrade, and is what the tools below use. FSKit matters if you are implementing a disk format, or want to keep an existing FUSE file system without the kext on macOS 26.

The options available today#

Keep using macFUSE and sshfs#

Still the most flexible option, and if your machine already works there is no urgency to change: real POSIX semantics, every sshfs mount option, mount points wherever you like. The price is Reduced Security on Apple silicon, an unmaintained sshfs, a tap outside Homebrew core, and a mount that may need attention after each major macOS release.

macFUSE with the FSKit backend#

Worth trying if you are on macOS 26 and want to keep your existing FUSE tooling without the kext: same commands, plus -o backend=fskit. Expect the documented limitations, expect lower throughput than the kext, and check the issue tracker before committing a team to it — sshfs specifically still has an open report.

FUSE-T — kext-less FUSE over NFS or SMB#

FUSE-T takes a different route to the same goal: instead of a kernel extension it runs a local NFS or SMB server and lets the kernel's existing network client mount it, with an FSKit backend added for macOS 26. No kext, no Recovery Mode, and it is a drop-in for many FUSE programs.

Two things to know before you deploy it. Its NFS backend has historically shipped without authentication on the loopback server, which is a consideration on a shared or untrusted network; and some FUSE features, notably file lock notifications, are unsupported on that backend. It is free for personal use, with a commercial licence required to bundle it in a product.

Native clients built on File Provider#

Barely a category three years ago, now the mainstream answer: ordinary applications that ship a File Provider extension. You add a server, it appears in the Finder, and nothing is installed outside the app.

• Mountain Duck 5 — its own description: “The new Integrated connect mode syncing with File Provider (macOS) and Cloud Files (Windows) APIs. No device driver installation or network mount required.” Very broad protocol coverage: SFTP, FTP, WebDAV, SMB, S3, Azure, Google Drive, Dropbox, OneDrive, SharePoint, Box, Backblaze B2 and more.
• ExpanDrive — also on the Apple File Provider extension, volumes in ~/Library/CloudStorage, around fifteen services, and integration with the built-in macOS ssh-agent. If agent-based authentication is a requirement for you, this is the one to look at first: SSHMount does not support ssh-agent.
• SSHMount — ours. SSH and SFTP only, deliberately, with a built-in SSH terminal and host key verification that happens before any credential is sent. Sandboxed, distributed through the Mac App Store.
• SteadyMount and a handful of newer menu-bar apps take the same approach for SFTP, WebDAV and FTP.

What you give up against FUSE is generality. A File Provider volume is not a POSIX file system but a synchronising provider with its own rules about when files materialise — excellent for editing config files, moving assets and working in the Finder; wrong for running a build directly against the mount.

Browse-and-copy clients#

Cyberduck and Transmit are excellent, but they are not mounts: files stay in their window until you copy them somewhere. Worth saying, because people are often sent to them as the answer to this question — and Transmit genuinely used to be one. Transmit Disk was discontinued in 5.6.0, with Panic citing app notarisation in macOS 10.15 and saying they hope to revisit it.

SMB and NFS, when you control the server#

The option nobody mentions, and often the correct one. If it is a NAS or a server you administer, exporting over SMB or NFS gives you a mount handled by the kernel's own heavily optimised network clients: no third-party software at all, and far better behaviour with large files and random access than anything tunnelled over SSH. Connect with ⌘K in the Finder:

open 'smb://nas.example.com/media'
# or, without the Finder:
mkdir -p /Volumes/media && mount_smbfs //user@nas.example.com/media /Volumes/media

Use SSH when the server is remote or untrusted, or when SSH is the only port open. Do not tunnel a gigabit LAN through it out of habit.

Manual transfer: rsync and scp#

Still correct for a great many jobs. If you touch the remote files a few times a week, copying is simpler than mounting and cannot leave you with a half-materialised file. rclone extends the idea to seventy-odd backends, free and scriptable; it can mount too, but on macOS that mount still needs macFUSE, FUSE-T or the FSKit backend underneath.

rsync -avz --progress user@example.com:/srv/site/ ~/work/site/
rsync -avz --delete ~/work/site/ user@example.com:/srv/site/

Comparison#

Which option should you choose?#

Four situations that cover most of the traffic to this page. The short version, before the detail:

You edit files on a remote development server#

A File Provider client is the right shape: files in the Finder, your editor opens them directly, nothing installed outside the app. SSHMount and Mountain Duck both do this well, and our free tier mounts one volume read-only if you want to try the shape of it first. If you authenticate with ssh-agent, choose ExpanDrive — it integrates with the macOS agent and SSHMount does not. If you need to run builds against the files, do not mount at all: work locally and deploy.

You work with large video files on a NAS#

Use SMB or NFS. Not a close call: editing software seeks constantly, and any user-space file system — ours included — sits further from the kernel's network stack than the built-in SMB client. Reach for SSH only if the NAS is off-site or only reachable that way.

You need S3, OneDrive, SharePoint or Google Drive#

Mountain Duck or ExpanDrive. SSHMount speaks SSH and SFTP and nothing else, on purpose. If your storage is object storage or a corporate drive, we are the wrong tool and pretending otherwise would waste your afternoon.

You transfer occasionally, or you are scripting it#

rsync, scp or rclone. Free, scriptable, no extension of any kind. A mount is convenience for continuous work and overhead for a weekly upload.

If, after all that, what you want is an SSH server in your Finder with a terminal next to it, on a Mac you would rather not put into Reduced Security — that is the narrow thing we built:

How to migrate from sshfs to a native mount#

Worth doing properly, because the point is getting the boot volume back to Full Security. Order matters: unmount, uninstall, then raise security.

1. Unmount everything that FUSE is serving. Check first:

mount | grep -i -e macfuse -e fuse-t -e osxfuse
umount /Volumes/srv        # or, if it is busy:
diskutil unmount force /Volumes/srv

2. Remove macFUSE. It ships an uninstaller in its preference pane, under System Settings › macFUSE. If you installed it through Homebrew:

brew uninstall gromgit/fuse/sshfs-mac
brew uninstall --cask macfuse

3. Confirm no kernel extension is left loaded. Nothing should come back from either command:

kmutil showloaded | grep -i fuse
systemextensionsctl list | grep -i fuse

4. Restore Full Security. Same route into Recovery as before — Shut Down, hold the power button until Loading startup options, Options, Continue, Utilities › Startup Security Utility, Security Policy… — but this time choose Full Security. Restart.

5. Set up the native mount. Add the server in whichever File Provider client you chose. The volume appears in the Finder sidebar and on disk under ~/Library/CloudStorage/ — worth knowing, because that is the path to give to any tool that wants one:

ls ~/Library/CloudStorage/

Troubleshooting#

The five failures behind most of the questions we get. If yours is not here, the support page covers the two that are specific to SSHMount.

sshfs: command not found after installing with Homebrew#

The sshfs formula is no longer in homebrew/core, because macFUSE is no longer open source and Homebrew does not accept closed-source dependencies there. brew install sshfs either fails or installs nothing usable. Use the tap: brew install gromgit/fuse/sshfs-mac, having installed the macFUSE cask first.

“System Extension Blocked” and the mount never appears#

macOS loaded the installer but refused the kernel extension. On Apple silicon the approval in System Settings is not enough on its own — the boot policy has to allow user-managed kexts, which means the Recovery Mode route above and a restart. If you approved the extension but never rebooted into Recovery, this is what you see.

File system named macfuse not found / mount(8) returned 69#

This is the FSKit backend failing to register, reported on macOS 26.1 and still open. Check that both macFUSE FSKit entries are enabled in System Settings, and that no second copy of macFUSE (from MacPorts, or an old installer) is present. If it persists, drop -o backend=fskit and use the kernel extension backend while the issue is investigated.

mount_macfuse: the file system is not available (2)#

Almost always a macFUSE build that does not match the running kernel, which is what a major macOS upgrade produces. Reinstall the macFUSE release that lists your macOS version as supported, then reboot. This failure mode is inherent to the kext approach and is the single most common reason people go looking for an alternative in the first place.

The mount disappears after sleep, or when the network changes#

SSH connections do not survive a change of network interface, and a FUSE mount on a dead connection leaves a stale mount point rather than disappearing. Force-unmount it (diskutil unmount force) and mount again. If it is a daily annoyance, prefer a client that reconnects on its own.

Frequently asked questions#

In short#

macFUSE did not become dangerous or abandoned — it became the heavyweight option, still the most capable general-purpose answer, and on macOS 26 able to shed the kernel extension. But the question is no longer “what replaces macFUSE” — it is “do I need a file system driver at all?” For most people reaching a remote server: no.

Match the tool to the job. Object storage and corporate drives: Mountain Duck or ExpanDrive. A NAS on your own LAN: SMB. Occasional or scripted transfers: rsync or rclone. A file system you genuinely need to implement: FSKit, or macFUSE while FSKit matures. And if the job is SSH and SFTP in the Finder, with a terminal beside it and the boot volume left at Full Security — that is the one thing SSHMount does.