keybase
unable to load KBFS on MacOS 26
Describe the bug When using MacOS 26 Tahoe Beta 1, the below error message is displayed:
We were unable to load KBFS (Fuse kext). This may be due to a limitation in MacOS where there aren't any device slots available. Device slots can be taken up by apps such as VMWare, VirtualBox, anti-virus programs, VPN programs and Intel HAXM.
my log id: d31257e17b5c941ed8debe1c
To Reproduce Steps to reproduce the behavior:
- Upgrade MacOS to Tahoe Beta 1
- Login to Mac
- Open Keybase
Expected behavior Keybase FS should work as expected
Screenshots
Additional numbers The number 345567
I'm experiencing the same issue.
This is likely a similar issue to #27378 from last year.
The maintainers have been reliable about fixing this each year.
Same. Created symbolic links
/Library/Filesystems/macfuse.fs/Contents/Extensions/26 /Library/Filesystems/macfuse.fs/Contents/Extensions/26.0
It did not solve the issue. Went through regular troubleshooting process, updated MacFuse and no luck thus far.
There seems to be a recurring issue every time there is an OS upgrade.
Is there a workaround that means we can use Macfuse instead?
@benrfairless well, the main issue is that the way Keybase works with FUSE requires the fully open-source version of OSXFUSE, now known as macFUSE, of which version 3.8.3 is the last one that works.
The issue here is that from 3.8.3 onwards, macFUSE uses a little snippet of proprietary code to inject FUSE into the kernel as an extension — something which Apple has made more and more difficult with each successive macOS release — and that piece is signed by someone considered to be a "very respected developer", meaning that his signature is still accepted by macOS as being valid to inject things into the kernel. Although there are far better alternatives out there, macFUSE remains the Golden Standard and has a consistent release cycle, keeping up with Apple's "latest and greatest" guidelines — a condition, I suppose, to maintain that special "elite" status and his signing superpowers.
Now, the kbfs daemon can use a different version of osxfuse if it's launched with -use-system-fuse. This is a 'developer parameter', very likely added with the purpose of comparing Keybase's port of osxfuse with the 'reference' osxfuse — the results, in theory, ought to be identical, and Keybase probably had their benchmarks to test this out. It certainly works fine, with two caveats:
- It will only work with
osxfuseup to 3.8.3 (why? I have no idea) - The automated
kbfslaunch procedure (i.e., when everything is launched from the Keybase app, as opposed to using the command line) requires a very, very ugly hack.
Given those two limitations, especially the first, what is the point in replacing Keybase's own FUSE package with one that is also as obsolete, and essentially 'the same thing' under a different wrapping? Well, there were a few good reasons for that. The first — and perhaps most important — is that the 'official' osxfuse was signed by the magic signature that still allows injecting kernel extensions in the kernel. Keybase's port, of course, is 'merely' signed with Keybase's signature, which, from the perspective of Apple, 'only' allows them to install regular applications, but never come as dangerously close to the kernel. As such, once Apple started to tighten security around what extensions could be installed without a 'proper' signature, at some point, Keybase's own solution stopped working. Even the 'old' trick of rebooting into the 'unsafe mode', inject the kernel with Keybase's extension, and then reboot again, does not work any longer. And this started to happen around the time macOS Catalina and/or Big Sur were released. Since then, the only alternative was, as said, to apply ugly hacks to get kbfs to use the installed 3.8.3 version of osxfuse. This has worked reasonably well (say, for 90% of the time or so), failing only when the old FUSE kernel extension would apply an unbreakable lock on parts of the file system, which could only be released with a system reboot.
Time passes, and Apple's getting more and more oppressive with its 'premature obsolescence' policy, and disallowing tinkering with the kernel by making it impossibly more complex. AFAIK, osxfuse 3.8.3 will not even 2work on Apple Silicon models (how would you run a kernel extension using Intel assembly code?... I don't think that even Rosetta 2 can deal with that) — at least, that's my own personal experience. And sure thing, macFUSE 5.X has been carefully redesigned to support both Intel-based and Apple Silicon-based Macs, running any version of macOS 12 (Monterey) up to 26.X (Tahoe).
But that hardly matters to Keybase's environment — it ignores the existence of any installed FUSE version except either Keybase's own or osxfuse 3.8.3, if kbfs is called with -use-system-fuse.
Now, as you can see here on GitHub, the Keybase GUI is getting an almost uninterruptible stream of changes, bug fixes, patches, and so forth; the GUI developers are very active, even compared to the pre-Zoom acquisition. Most bugs might be minor (such as, say, an avatar that loads slower than expected, or not at all), but the truth is that they're on it — all the time, at a neck-breaking pace.
Everything else is not exactly stalled, but certainly more neglected. Things seem to have settled along the lines of 'fix the security bugs or anything that might prevent Keybase from running under contemporary OSes, such as Windows 11 or macOS Tahoe'. Besides those, there hasn't been any innovative additions, nor any code refactoring beyond fixing incompatibilities with contemporary OSes.
To investigate the code that actually makes this work, it's worth looking at the getPlatformSpecificMountOptions() function (on mounter_osx.go). As you can see, it explicitly requests a 3.X.X version of osxfuse, failing otherwise. Why? I really have no idea, although it's fair to say that when this code was written, version 5 wasn't out yet.
To add a bit of additional confusion, Keybase doesn't call the FUSE extension directly. Instead, it relies upon bazil/fuse — an intermediary library, written in 100% native Go, which handles the calls, presenting them nicely in a Go-idiomatic way. Sadly, this library has also been abandoned by its creator; in particular, it's unknown if/how Keybase's own issues and suggestions have ever been implemented or not.
Alas, that required changing not only Keybase's code, but Bazil's as well. A starting point may be options.go, but I admit that this is as far as I can go...
BTW, whatever happened I cannot say, but after allowing the Keybase kernel extension to be installed (which requires lowering system security, of course), it seems that I got everything working flawlessly under Tahoe, using the 3.X.X non-Keybase osxfuse.
I'm baffled how well this works — even under Tahoe running on Apple Silicon. Amazing!
They should just do away with using FUSE for macOS, and write a File Provider instead. This is the API that Apple officially recommends and supports for systems which make remote files "appear" as part of the filesystem, and which other things like dropbox and the google/microsoft "drive" products, are now using.
If only Zoom would devote some actual resources (i.e. developer time) to this ...
