Any plans to provide (a subset of) the FUSE3 API directly on top of FSKit/an underlying primitive, in a way that doesn't compromise the new security model, but also reduces porting friction?
A FUSE compatibility layer on top of FSKit represents an excellent 3rd-party opportunity. We are definitely interested in any feedback related to obstacles in developing such a compatibility layer.
I can provide feedback as a relatively long response that describes several areas where FSKit has insufficient or absence support to match FUSE3 capability. Do you want the long response in this thread? I suppose you would also like the response via Feedback Assistant?
I've submitted Feedback FB23056342, whose text follows.
This Feedback captures my response in forum topic https://developer.apple.com/forums/thread/831338?answerId=891228022#891228022 to the request by Apple Staff to detail obstacles that FSKit may have to FUSE3 compatibility, quoted here:
"A FUSE compatibility layer on top of FSKit represents an excellent 3rd-party opportunity. We are definitely interested in any feedback related to obstacles in developing such a compatibility layer."
First, thank you. This is a helpful dialog.
We maintain a production network filesystem with a FUSE3-based implementation for Linux. We also implement this filesystem with a XNU VNOP-based kernel extension implementation for macOS. We are highly motivated to move our macOS implementation into user space (via FSKit), but we see gaps in FSKit that prevent compatible implementation to match the capabilities afforded by either the XNU VNOP or FUSE3 interface.
We are not asking Apple to publish a FUSE3 shim (though that would be nice). We are asking for FSKit (or a companion interface) to expose the complete set of VFS operations that a production network filesystem actually requires. FUSE3's struct fuse_lowlevel_ops (https://github.com/libfuse/libfuse/blob/master/include/fuse_lowlevel.h) is a useful reference to define "complete set," and mapping it against what FSKit currently provides is the most direct way to surface the gaps.
Gap list: fuse_lowlevel_ops vs. FSKit (macOS 26)
Operation: getlk / setlk
FSKit status: Absent
Impact: POSIX advisory byte-range locks (fcntl F_GETLK/F_SETLK/F_SETLKW) are not delegated to the FS implementation. For a multi-client network FS this is a hard blocker: lock arbitration must involve the filesystem, which relays it to the server.
Operation: flock
FSKit status: Absent
Impact: BSD advisory whole-file locks (flock(2)) are similarly not delegated.
Operation: ioctl
FSKit status: Absent
Impact: No mechanism for applications to issue custom ioctl calls through to the filesystem daemon. We use this for filesystem-specific out-of-band control commands that have no natural equivalent in the standard VFS call set.
Operation: getxattr / setxattr / listxattr / removexattr
FSKit status: Absent
Impact: Extended attributes are not exposed to FSKit implementors at all. This is increasingly blocking because macOS system services (sandboxing, quarantine, Finder metadata, codesigning) all rely on xattr traffic flowing through the filesystem.
Operation: forget / forget_multi
FSKit status: Absent
Impact: No inode eviction notification. A filesystem cannot release server-side references for cached inodes until the kernel silently evicts them, with no callback. This makes correct reference counting and cache coherency across clients very difficult to implement.
Operation: access
FSKit status: Absent
Impact: No delegation of access(2) / faccessat permission checks. We have a full avid_access implementation for Linux that cannot be wired up on macOS.
Operation: readdirplus
FSKit status: Absent
Impact: Combined readdir + getattr in a single round-trip is a significant network performance optimization. readdir alone forces a separate per-entry getattr on every directory listing.
Operation: fallocate
FSKit status: Absent
Impact: Space pre-allocation, important for real-time media workflows where storage must be contiguous and guaranteed before a record begins.
Operation: copy_file_range
FSKit status: Absent
Impact: Server-side copy. Without this, copying a file across a network volume requires reading every byte through the client.
Operation: lseek with SEEK_HOLE / SEEK_DATA
FSKit status: Absent
Impact: Sparse file traversal. Needed for correct backup and copy semantics on files with holes.
Operation: mknod
FSKit status: Absent
Impact: Device node creation.
Operation: poll
FSKit status: Absent
Impact: No poll/kqueue notification support for FS-backed file descriptors.
The four highest-priority blockers for us, roughly in order, are: advisory locks, ioctl, xattrs, and forget notifications.
We also have a broader concern about the FSKit's protocol model.
Beyond individual missing operations, there is a structural friction: FSKit's Swift/Objective-C protocol model has per-call overhead and limited concurrency control that is architecturally different from a C-level operations table (whether that is struct fuse_lowlevel_ops, the XNU vnode_operations table, or equivalent). For a high-throughput network filesystem handling many concurrent file handles, including media workloads with large sequential I/O, this matters. We would strongly welcome a C-callable operations table, or at minimum a stable ABI that minimizes dispatch overhead, even if the sandbox and authentication model of FSKit is preserved around it.
We are happy to provide test implementations, concrete performance data, or detailed API feedback against any new interface. The OP in the WWDC26 framed our interest well: reducing porting friction while not compromising the security model.
An alternative would be a porting tool or guide?
Maybe use the sshfs MacFuse FS, as the example, porting it to FSkit, and then document the process and what needed to be done.
Also, outlining any limitations in the process?
That said, based on DinosaurW00f's response, it does sound like the FSKit team could use this as a way of exploring the limitations they need to improve on and share this as an open source reference?
Maybe use the sshfs MacFuse FS, as the example, porting it to FSkit, and then document the process and what needed to be done.
It looks like Apple finally added a little bit extra to FSKit in macOS 26. They now support URL resources. Before, FSKit was restricted to system devices. I've got some older apps I could re-deploy using FSKit now.
I wouldn't touch anything FUSE related, and especially sshfs, due to GPL licensing issues.
Following up on this, we've introduced new API that cover many of these issues:
- Operation: getxattr / setxattr / listxattr / removexattr
- Operation: forget / forget_multi
reclaimItem(_:replyHandler:) should handle this, at least in part. Is there some reason why it’s particularly important to get multiple items in one go vs. infrastructure in the module getting a list and looping through it?
- Operation: access
-> FSVolume.AccessCheckHandler
- Operation: fallocate
-> FSVolume.PreallocateHandler
- Operation: lseek with SEEK_HOLE / SEEK_DATA
I also had a few comments/questions about:
- Operation: ioctl
It’s possible FSKit might support this at some point; however, one thing to keep in mind here is that running in user space means you have access to a much broader set of IPC tools like XPC or Unix sockets. Those may be a better option, depending on exactly what you're trying to do.
- Operation: copy_file_range
So, one thing to be aware of here is that part of the issue here is that our VNOP and API level support for this isn't great. VNOP_COPYFILE is how the Finder does server-side file copying, but VNOP_COPYFILE operates at the file level (not byte ranges) and public API support for it is very limited. So the problem here isn't just what’s missing in FSKit; it's that the available VNOP isn't ideal and that adopting that VNOP would only support a subset of usage, albeit a critical one.
- Operation: mknod
What are you actually trying to do here?
Finally, commenting on a few details:
We would strongly welcome a C-callable operations table.
The team actually did some testing and experimentation with this early on, and the results were... not great. The dispatch queues are such a large part of the system user space architecture that the older architecture simply didn't work very well.
limited concurrency control
All operations are received over NSXPC, on a serial queue. To improve concurrency, you may want to consider making the first step of any work be dispatching that work to a different queue.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
