# macFUSE: user space file systems on macOS, and what the umbrella repository actually contains > macFUSE lets non-privileged users mount their own file systems on macOS without writing kernel code. This review covers what the repository ships, how to install it, and where the closed-source kernel extension changes the calculus. **macfuse/macfuse** — macFUSE umbrella repository - Repository: https://github.com/macfuse/macfuse - Stars: 9,822 · Forks: 549 - Language: Unknown - License: NOASSERTION - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/macfuse-macfuse ## The problem macFUSE solves, and the developers it is aimed at On macOS, adding a file system has historically meant writing kernel code. macFUSE removes that requirement. The README states the package "lets non-privileged users create their own file systems without having to write a single line of kernel code," with file system code running in user space while the macFUSE kernel extension provides only a bridge to the kernel interfaces. The audience is narrow and specific. This is not a tool an end user installs to get a new disk format; it is infrastructure that other software depends on. The README names three popular use cases: accessing files in the cloud, accessing files on non-native file systems that macOS does not support, and transparent encryption or decryption of files. The second category explains why search interest clusters around ext4, NTFS, XFS and SSHFS: those are the file systems people reach for macFUSE to mount, usually through a third-party driver that links against it. The design consequence matters more than the feature list. Because macFUSE file systems are regular applications rather than kernel extensions, the README notes that developers get the same flexibility in programming tools, debuggers and libraries as they would when writing any other Mac application. A crash in a user space file system does not take down the kernel. That is the trade: you gain a debugging story and lose the ability to do anything the kernel interface does not expose. ## Two APIs, one dylib, and a closed-source kernel extension The repository exposes two programming surfaces. libfuse.dylib provides what the README calls "a superset of the standard Unix FUSE API." macFUSE.framework is a high-level Objective-C wrapper around the libfuse C API. A C or C++ project links the dylib; a Swift or Objective-C project can use the framework instead of hand-rolling bindings. The architecture is a split. File system logic lives in your process, in user space. The kernel extension does not implement file systems; it bridges your process to the kernel's file system interfaces. Everything a mounted volume does passes through that bridge, so the extension sits on the path of every read and write even though it holds no file system logic. This repository is an umbrella. The README is explicit that it "contains the source code of libfuse.dylib and macFUSE.framework" and that "the other components, e.g. the macFUSE kernel extension, are closed-source." The top-level layout reflects that: Framework, Library-2, Library-3, Mount, LICENSE.txt, README.md, plus a .gitmodules file, which indicates the build pulls in submodules rather than being self-contained. The licence is reported as NOASSERTION, and the README points to LICENSE.txt rather than naming terms inline; anyone who needs to know the actual terms has to read that file, because the repository metadata does not resolve them. The last full open source release was version 3.8.3, supporting macOS 10.5 to macOS 10.14.4, and it lives in the support/osxfuse-3 branch of the osxfuse/osxfuse repository. If you want to read a complete macFUSE implementation end to end, that branch is the only place the README points to. Current releases do not offer that. ## Installing macFUSE and what a first mount involves The README does not carry installation steps. It points to the macFUSE website at macfuse.io, the official wiki at github.com/macfuse/macfuse/wiki, and the community wiki at github.com/macfuse/community/wiki as the places to look. Distribution through Homebrew is a common route for Mac tooling, but the README does not document a formula, so treat the website and wiki as the authoritative install path. What the README does state is the supported range: the latest version supports macOS 12 to macOS 27. Check that first. A machine outside that range is a non-starter regardless of how the package is obtained. The practical sequence is: install macFUSE, then install the file system that depends on it. macFUSE on its own mounts nothing. A file system built against libfuse.dylib or macFUSE.framework is what turns the bridge into a visible volume. The README lists cloud access, non-native file systems and transparent encryption as the three common categories, and the search data around this project shows the same pattern in practice, with people looking for ways to reach ext4, NTFS and XFS volumes from a Mac. If you are writing the file system rather than consuming one, the entry points are the two APIs. A C project links libfuse.dylib, and an Objective-C project can build against the framework wrapper instead. Both produce an ordinary application: the README states macFUSE file systems are regular applications, so the build, debug and packaging workflow is the one you already use for Mac software. Neither produces anything visible until the resulting binary is run and mounts a volume. ## Where macFUSE is the wrong tool The clearest limitation is the source boundary. If your adoption decision requires reading the code that runs in the kernel, macFUSE fails that test today. Only libfuse.dylib and macFUSE.framework are open in this repository. The kernel extension is closed-source, and the last complete open source release is 3.8.3, which supports macOS 10.5 through macOS 10.14.4 and therefore does not cover any currently supported macOS version. You cannot substitute the old branch for the current one. The second limitation is scope. macFUSE is a bridge, not a file system. Installing it gives you no new mountable format. If what you actually want is to read an ext4 or NTFS disk, macFUSE is one layer of that stack and someone else's driver is the other. When that driver lags, macFUSE being current does not help you. The third is the platform range. macOS 12 to macOS 27 is the documented window for the latest version. Older machines are out of scope, and the project makes no claim about them. If you maintain a fleet spanning older releases, you are running two different stories, and the older one is the frozen 3.8.3 branch. Finally, the repository layout is not a single self-contained build. The presence of .gitmodules and the split between Framework, Library-2, Library-3 and Mount means anyone attempting to build from source is assembling several pieces, and the kernel extension they would need for a working mount is not among them. ## macFUSE compared with FUSE implementations that avoid kernel extensions The search data shows people comparing macFUSE against fuse-t, and the difference is architectural rather than cosmetic. macFUSE installs a kernel extension that bridges user space file system code to the kernel's file system interfaces. That extension is the closed-source component in this repository. An implementation that avoids a kernel extension has to reach the same result through a different channel, typically by presenting the file system over a protocol the operating system already speaks rather than by hooking the kernel's file system layer. The trade is the reverse of macFUSE's: you may give up the directness of the FUSE interface and the maturity of the libfuse API surface, and in exchange you avoid installing a system-level component that requires approval and that you cannot read. Which one is right depends on what you are building. If you are porting an existing libfuse file system, the API compatibility macFUSE offers through libfuse.dylib and macFUSE.framework is the reason to pick it, and rewriting against a different mechanism is a real cost. If your constraint is that no unreadable code may sit between your process and the kernel, the extension-free approach is the one that satisfies it, and the cost is a different programming model. There is also the older comparison point inside the project itself. The osxfuse 3.8.3 branch is fully open and covers macOS 10.5 to macOS 10.14.4. For anyone targeting those releases, it is a genuinely different proposition from the current releases, and the two should not be treated as the same product. ## Maintenance, releases and the cost of keeping up The repository is not archived, and the last push was on 2026-09-07. Releases track closely behind it: macfuse-5.4.0 on 2026-09-07, macfuse-5.3.3 on 2026-07-04, and macfuse-5.3.2 on 2026-06-17. That cadence suggests point releases arrive every few weeks to a couple of months, with 5.3.2 to 5.3.3 spanning roughly two and a half weeks and 5.3.3 to 5.4.0 spanning about two months. The upgrade cost is not the download. It is the dependency chain. Every file system built against macFUSE is a separate project with its own release schedule, and a macFUSE update only helps once that project has been rebuilt against it. If you run several FUSE-based tools, you are tracking several upgrade paths, and the slowest one sets your floor. On licensing, the README does not state terms inline. It says "Please see LICENSE.txt," and the repository metadata reports NOASSERTION, meaning the licence could not be resolved automatically. The one concrete fact available is the split: libfuse.dylib and macFUSE.framework are in this repository under whatever LICENSE.txt says, while the kernel extension is closed-source and therefore governed by separate terms that the README does not describe. Anyone distributing a product that bundles macFUSE needs to read LICENSE.txt and establish the terms for the closed component independently. That is a factual gap in the repository, not a legal question this review can settle. ## Conclusion Adopt macFUSE if you are building a user space file system on macOS 12 to macOS 27, or if you need an existing FUSE-based tool such as an SSHFS or NTFS client to work on a current Mac. Do not adopt it expecting the whole stack to be auditable: only libfuse.dylib and macFUSE.framework are in this repository, and the kernel extension is closed-source, so anyone with a source-review requirement should treat that boundary as the deciding fact. Before committing, verify three things on your own machine: that your macOS version falls inside the documented 12 to macOS 27 range, that the third-party file system you intend to mount is built against the 5.x API rather than the old 3.8.3 releases, and that your deployment path can accommodate a system-level component that requires user approval rather than something installed silently. ## FAQ ### What is macFUSE on a Mac? It is a software package for macOS that lets non-privileged users create their own file systems without writing kernel code, by running file system code in user space while a kernel extension provides a bridge to the kernel interfaces. It ships libfuse.dylib and macFUSE.framework as the two development APIs. ### What is macFUSE used for? The README names three popular use cases: accessing files in the cloud, accessing files on non-native file systems that macOS does not support, and transparent encryption or decryption of files. Developers can also build on-disk, layering and network file systems on top of the provided APIs. ### How do I install macFUSE? The README does not include installation steps. It directs readers to the macFUSE website at macfuse.io, the official wiki, and the community wiki for that information. The latest version supports macOS 12 to macOS 27, so check your macOS version before installing. ### Is macFUSE safe? The README does not make a safety claim either way. What it does state is the source boundary: this repository contains libfuse.dylib and macFUSE.framework, while the macFUSE kernel extension is closed-source. Anyone who needs to audit the code that sits between user space and the kernel cannot do so from this repository. ### Can I remove macFUSE? The README does not document an uninstall procedure, and no removal steps appear in the repository description or the referenced wikis as summarized here. Because macFUSE installs a system-level component, treat removal as something to confirm against the project's own documentation rather than assuming a simple file deletion. ### What is an alternative to macFUSE? The search data around this project shows comparisons with fuse-t. The difference is architectural: macFUSE installs a kernel extension to bridge user space file system code to the kernel, while an implementation that avoids a kernel extension must reach the same result through another mechanism, which changes the programming model rather than just the packaging. ## Sources - [Issues](https://github.com/macfuse/macfuse/issues) - [macfuse/macfuse on GitHub](https://github.com/macfuse/macfuse) - [README](https://github.com/macfuse/macfuse/blob/release/macfuse/README.md) - [Releases](https://github.com/macfuse/macfuse/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/macfuse-macfuse