Context
cgofuse on macOS currently links against libfuse2 (via macFUSE 2 or
fuse-t's libfuse2-compat layer). On macOS 15+ Sequoia, Apple
introduced FSKit
— a kext-less, fully-supported API for userspace filesystems that
fixes long-standing issues with NFS-tunneled FUSE on macOS.
As of April 2026, FSKit support is available through libfuse3:
- macFUSE 5.2.0 (2026-04-09) ships libfuse3 with
-o backend=fskit
that goes through MFMount.framework.
- fuse-t 1.2+ also offers
-backend=fskit via libfuse3.
PR #87 added libfuse3 support on Linux and FreeBSD via the fuse3
build tag, but explicitly left macOS aside (CI couldn't load macFUSE
kext on GitHub runners at the time). With macFUSE 5.2+ kext-less via
FSKit and fuse-t already kext-less, that blocker is lifted.
Why this matters for macOS users
A FUSE mount running through libfuse2 on macOS is tunneled via
localhost NFS. Consequences:
- macOS classifies the volume as network, not local.
- Sandboxed apps (Plex Media Server, Jellyfin, Photos, etc.) refuse
to read the mount unless the user manually grants Network Volumes
permission in System Settings → Privacy & Security → Files and
Folders. Hard to discover, impossible to grant programmatically.
- Finder labels the mount with the synthetic hostname (
fuse-t: or
localhost:), ignoring volname.
The FSKit backend solves all three because the mount is genuinely
local.
What we'd need
Extend the fuse3 build-tag wiring to also work on macOS, linking
against macFUSE 5.2+ / fuse-t 1.2+ libfuse3. The Go-side API doesn't
need to change — it's mainly a build / link concern.
Is anyone planning to work on this?
Happy to test against a draft PR. Real-world use case: a media-stack
orchestrator (mediastack) that mounts a union FS for its services;
the libfuse2-on-macOS setup forces every user through the Plex
"Network Volumes" permission dance.
Context
cgofuse on macOS currently links against libfuse2 (via macFUSE 2 or
fuse-t's libfuse2-compat layer). On macOS 15+ Sequoia, Apple
introduced FSKit
— a kext-less, fully-supported API for userspace filesystems that
fixes long-standing issues with NFS-tunneled FUSE on macOS.
As of April 2026, FSKit support is available through libfuse3:
-o backend=fskitthat goes through MFMount.framework.
-backend=fskitvia libfuse3.PR #87 added libfuse3 support on Linux and FreeBSD via the
fuse3build tag, but explicitly left macOS aside (CI couldn't load macFUSE
kext on GitHub runners at the time). With macFUSE 5.2+ kext-less via
FSKit and fuse-t already kext-less, that blocker is lifted.
Why this matters for macOS users
A FUSE mount running through libfuse2 on macOS is tunneled via
localhost NFS. Consequences:
to read the mount unless the user manually grants
Network Volumespermission in System Settings → Privacy & Security → Files and
Folders. Hard to discover, impossible to grant programmatically.
fuse-t:orlocalhost:), ignoringvolname.The FSKit backend solves all three because the mount is genuinely
local.
What we'd need
Extend the
fuse3build-tag wiring to also work on macOS, linkingagainst macFUSE 5.2+ / fuse-t 1.2+ libfuse3. The Go-side API doesn't
need to change — it's mainly a build / link concern.
Is anyone planning to work on this?
Happy to test against a draft PR. Real-world use case: a media-stack
orchestrator (mediastack) that mounts a union FS for its services;
the libfuse2-on-macOS setup forces every user through the Plex
"Network Volumes" permission dance.