macOS has no viable FUSE kernel support, is not supported

[tv42]

OSXFUSE is no longer open source, see e.g. https://colatkinson.site/macos/fuse/2019/09/29/osxfuse/

I will not personally put in uncompensated effort into supporting non-open source environments, especially ones with this much bad faith activity. And I'm saying that as one of the few people who have directed (other people's) money toward the OSXFUSE maintainer. I also do not use macOS as my day-to-day environment.

Unless an open source OSXFUSE fork shows up relatively soon, I will rip out all the ugly kludges that only exist to serve the willfully different without a good reason OSX code. Once they are out any future macOS FUSE support will have to actually make an effort to behave like Linux for me to be interested in supporting it.

[tv42]

And it looks like Apple is killing the whole category: https://news.ycombinator.com/item?id=22251076

(And if some new userspace & safe VFS API is added later, the result will be very unlikely to look like OSXFUSE.)

[tv42]

Alright, we are 4+ months in and I've yet to hear anyone complain or volunteer. Expect macOS support to die soon, and I won't be adding all the macOS-specific kludges back; if someone has a plan for rescuing osxfuse, you'll need to match Linux behavior more closely before I'll be re-adding support.

Complaints can be directed to Apple, and refunds will be processed at the customer service desk.

And for reference, ain't nobody paying me either for this, https://www.theregister.co.uk/2019/12/16/fuse_macos_closed_source/

[MikaelSmith]

I'd complain, but not sure it'd do any good at this point. I was going to just stay on the version that supported it, but if OSXFUSE stops working, I'll have to adapt more drastically.

[MikaelSmith]

I don't have a ton of time to put into it either. I lean towards branching off a legacy version that continues to work with OSXFUSE support, which I may be able to help backport fixes to occasionally. Then master can leave it behind.

From looking at the last visible state of OSXFUSE, I don't see it using any of the deprecated kernel extensions. So after looking into it, I don't think OSXFUSE will stop working any time soon.

[tv42]

OSXFUSE is a kernel extension. Making an up-to-date macOS load it requires a significant amount of Apple approval. Back several years ago, I used to be able to compile the kext myself and debug it; now I don't even see the source code for it.

The situation is not ideal for sure, but I really can't justify putting much volunteer effort into something so hostile.

The nice thing about Git and open source is that "branching off a legacy version" is something anyone can do at any time. My volunteer labor is spread too thin already, even with just Linux (and there's BSD too).

[MikaelSmith]

At WWDC19, we announced the deprecation of kernel extensions as part of our ongoing effort to modernize the platform, improve security and reliability, and enable more user-friendly distribution methods. Kernel programming interfaces (KPIs) will be deprecated as alternatives become available, and future OS releases will no longer load kernel extensions that use deprecated KPIs by default.

My reading of that is that they'll stop automatically loading kernel extensions that use specifically deprecated Kernel programming interfaces (listed here). Others will continue to work.

I'll check back if I get to the point where I need to make fixes for whether I should maintain my own fork.

[tv42]

macOS support has been removed.

The macOS kludges were a significant amount of code, about
25% of the remaining non-test lines, and the primary source of
complexity and alternate code paths.

The API definitions will remain for a short while, with deprecation
markers. This should let multiplatform callers work without changes.
Everything deprecated will be removed soon, so please adjust
your code.

[tv42]

@MikaelSmith Perhaps the osxfuse kext will continue working for a while longer; it's Apple's walled garden, and the writing is definitely on the wall that there will be less of this sort of stuff in the future.

The signing requirement alone means osxfuse can't be maintained with just drive-by interest. I used to build it myself, read the source and report bugs, but after the osxfuse author made it proprietary I have no personal interest in doing that, and there were a ton of lingering bugs still around (see issues referring to this for a quick sampler). It's not worth it for me to try to drag our macOS support uphill through the mud by myself, at least not until there's a better maintained platform to aim toward. The write-up at https://colatkinson.site/macos/fuse/2019/09/29/osxfuse/ is a good summary.

I think the best summary I can offer is: FUSE on macOS was so weird it caused a 25% lines-of-code tax on this library, and was the sole culprit of most of the tricky concurrency issues and weird alternate code paths. Maintaining that and debugging all the random oddities and races was just barely doable when I could do it in the free software community spirit; when it's just enabling other people's proprietary projects, the work is not interesting at all. Especially when that proprietary project has a track record of not even trying to behave like the FUSE reference implementation.

In contrast, the FreeBSD support is about 200 lines total, and extremely straightforward.

[tv42]

Latest macOS has a userspace filesystem boundary of some sort, but Apple is keeping it proprietary: https://threedots.ovh/blog/2022/06/quick-look-at-user-mode-file-systems-on-macos-ventura/

[GwynethLlewelyn]

All right, I know that this issue is closed and locked, and there will never be a bazil/fuse implementation for macOS again. That's perfectly understandable, given the time spent by @tv42 to hack at the code just to support macOS, and the constant hurdles imposed by Apple upon the poor developers who try desperately to work around Apple's limitations in order to provide useful services.

It's no surprise that bazil/fuse is the de facto reference Go library for FUSE, although there are others; nevertheless, most software providing a way to mount special filesystems using FUSE, and doing it in Go, are using bazil/fuse, because, well, it still is the 'golden standard'.

There are alternatives, sure, but they almost always require refactoring one's own code.

On the flip side of the coin, you're welcome to hate Apple and their idiosyncrasies as much as you wish (I certainly hate a lot of things at the lower levels, i.e. beneath the shiny bright GUI), but it remains a fact that about a third of all devices connected to the Internet in the world use some derivative of Darwin (a billion alone use iOS). That's way more than Windows users, although, of course, much less than Linux/Android/other embedded OSes using a Linux kernel, which is, by far, the operating system family with the largest number of world-wide users (and will only continue to grow, as fridges and toasters are coming online — yay IoT, which will be 90% driven by Linux).

Taking that into account, chopping off a third of your user base is not necessarily a bright idea, no matter how 'hard' it might be, and how annoying that key components of that ecosystem are closed-source (either owned by Apple or other, third-party developers, who aren't giving away their work for free).

Last but not least...

On many discussions around this topic, I see a constant and persistent insistence on the same argument: 'Until macOS does things the Linux way I will not support it'.

Well, I'm sorry, but that's a fallacious argument. You can certainly express that wish, but you're basing that argument under a false assumption: that, somehow, due to Apple's malevolence, they deliberately make things more confusing and unappealing for poor Linux developers.

(They do, but that's besides the point!)

While most tools used by FreeBSD, Solaris, Linux, and Darwin/macOS are POSIX-compliant (I'm not being exhaustive here, there are more operating systems relying on POSIX compliance, such as Microsoft's own Linux distro, and IBM's AIX, just to give a few more examples), that does not mean that they do everything the same way at the kernel level. Rather the contrary: those kernels are radically different and work on totally different assumptions! It's just at the application level (say, libc) that there is a rough correlation between the developer's API, which, in turn, means that some degree of portability can be achieved with tools that rely on POSIX compliance to comply.

I could go on (and in fact I did, but this was getting too long), but I hope you understand the point: no, macOS/Darwin will never be 'like Linux' because it has a completely different Unix lineage.

Anyway, I'm just bumping this closed discussion, because I stumbled by chance upon zegl/fuse, a fork by @zegl who managed to easily support the more recent versions of macFUSE that allow mounting using the 'new' system — what I believe you consider the 'right' way of doing things. @zegl, unfortunately, did little else but make the necessary changes, over two years ago, and gave up on his own project (I guess it was just to make a point that it wasn't that hard to change). Master Anacrolix, a Go wizard of legendary fame (so long as it has to do with Torrents...), managed to pick up where @zegl left his project, and kept it up to date with the latest bazil/fuse commits. It works, and it's available at anacrolix/fuse as a drop-in replacement for bazil/fuse.

Maybe you could reach out to him and get him to support the effort of keeping bazil/fuse compatible with macOS?

FYI the relevant changes are mostly on commit 61ef775

[tv42]

POSIX and the general UNIX userspace APIs have very little to do with the FUSE the kernel-userpace protocol. In the time I attempted to use it, OSXFUSE never implemented the FUSE protocol to a degree where it would survive a few hours of stress testing. Changing just the mount dance to match current macOS conventions doesn't make the actual runtime behavior of OSXFUSE any more robust. And since then the OSXFUSE maintainer has removed my ability and motivation to look for bugs in his code. Some of the hangs and bad behavior were also caused by the mismatch of internal workings of filesystems between macOS and Linux, and looked pretty much unfixable by design.

I really, really, don't see a way forward with the general concept of filesystems in userspace on macOS without involving Apple, and using whatever mechanisms Apple provides to e.g. Dropbox and Google Drive. I have not followed that space closely, as I personally do not use macOS and haven't been externally motivated to do that work either. Last I looked, File Provider https://developer.apple.com/documentation/fileprovider seemed to be what Apple wanted you to use, and Dropbox was putting more of their own logic into a kext with Project Infinite https://dropbox.tech/infrastructure/going-deeper-with-project-infinite (but 3rd party kexts are going to have a tough time in the Apple ecosystem).

The kernel design of macOS is inherently at an impedance mismatch with the kernel design of Linux -- really, comes down to microkernel vs monolith, plus different designs on e.g. what is a file handle -- and macOS's driver design just doesn't implement things the way that FUSE exposes them. macOS is better doing whatever Apple allows you to do (if any), not trying to talk the FUSE protocol which it seems fundamentally unable to do properly. And I believe the Apple stuff won't look enough like FUSE to be able to share a filesystem implementation, beyond the most trivial of hello world examples. And thus I believe that deserves its own project, with APIs that suited to the Apple world.

Just because you, or someone else, repeats the "but I want it" mantra doesn't change the fundamental mismatch of macOS vs Linux.

I'd personally rather push FUSE support toward newer FUSE features such as eBPF acceleration.