To run FUSE – and apps that depend on it – macOS security has to be ‘downgraded’ without which FUSE extension will be blocked. To run an Apple Silicon Mac with reduced security, reboot your Mac. After the chime, press and hold the power button until you see ‘loading startup options’ under Apple logo. Select Options and click Continue. May 10, 2020 — Fuse for Mac OS X installation on MAC OSX using brew cask. A simple guide with steps to install Fuse for Mac OS X on MAC using homebrew. 41 minutes ago — Use this data to select the most beneficial 2002 Chrysler Sebring Fuse Panel Diagram Wiring Schematic for just about any project you ought to. FUSE (Filesystem in Userspace) is an open-source software interface that extends the file handling capabilities of the Mac OS, with support for NTFS and many other file systems. The CentreStack Mac Client relies on FUSE to mount the cloud drive among other things. Some users have also reported FUSE errors while using a Mac through a remote session.
In few weeks of new Macs with Apple Silicon M1 processor, it’s clear that Apple has done a great job to make the transition from Intel chips smooth. Apps that are not updated to run natively on Arm architecture run smoothly using Rosetta 2 and it’s hard to tell if you are using a native app or not.
What Is Fuse For Macos Operating System
But then there are apps that are crucial for a particular (and relatively small) user-base that are neither updated to run natively on new M1 Macs nor can be run with Rosetta 2. One example that comes to mind is Parallels Desktop that allows you to run operating systems like Windows virtually on a Mac. The popular virtualisation app simply can’t run on M1 Macs – natively or otherwise – due to changes introduced in the way new Macs work.
Another app – and this one is crucial for me – is VeraCrypt. I use VeraCrypt to encrypt all my external storage and it relies on OS X FUSE to work. Although it wasn’t immediately updated for the latest macOS version, VeraCrypt works with Big Sur using old OS X FUSE version. That however, is not true while running VeraCrypt on new M1 Macs.
What Is Fuse For Macos
Now, FUSE is not really an ‘app’ on its own but rather an extension. Two encryption app I use daily – VeraCrypt and Cryptomator – rely on FUSE to work. My recommended zero-knowledge encrypted cloud provider pCloud also works thanks to FUSE. Because new Macs have changed how system-level extensions work, FUSE doesn’t work out of the box.
FUSE 4.x.x has been updated for new Apple Silicon Macs but there is a workaround involved to actually make it work. Without this workaround, FUSE will simply not work, leaving apps that depend on in useless.
Now, it’s not FUSE’s (or VeraCrypt/Cryptomator/pCloud’s) fault. That’s just how new Macs work. According to FUSE developer Benjamin Fleischer, this should change in future when Apple fixes issues that can prevent third-party kernel extensions from loading.
To run FUSE – and apps that depend on it – macOS security has to be ‘downgraded’ without which FUSE extension will be blocked.
To run an Apple Silicon Mac with reduced security, reboot your Mac. After the chime, press and hold the power button until you see ‘loading startup options’ under Apple logo. Select Options and click Continue. Choose an administrator account and enter its password.
Now go to Utilities > Startup Security Utility and choose Reduced Security. Turn on both checkboxes underneath and click OK.
Reboot and visit System Preferences > Security and Privacy > General. Click the lock icon at the bottom, enter your password and click Allow in front of the message that says System Extension by Benjamin Fleischer was blocked.
Reboot once again and now FUSE for macOS should work as intended – helping VeraCrypt (and other apps like pCloud, Cryptomator etc.) work normally.
That’s all, folks. That’s how VeraCyrpt, Cryptomator and other apps that depend on FUSE for macOS work on new Apple Silicon M1 Macs.
FUSE for macOS (or, the kernel extension formerly known as osxfuse) is a projectdating back to 2011. It in turn is based on even older projects, such asMacFUSE, the Linux FUSE module, and even some code open sourced by Apple.
Until 2017, the project was open source, released under an amalgamation of thefairly permissive licenses of its various ancestors. But its maintainer,Benjamin Fleischer, decided to change that.While several releases have been published since then, only the binary blobs areprovided, leaving Fleischer as the only person with access to the completesource. For some previous discussion, checkhere,here,and here.
Some choice moments for those without the energy for programmer drama:
The osxfuse-3.9.0 tag shows an empty directory:https://github.com/osxfuse/osxfuse/tree/osxfuse-3.9.0
Checking out with git also produces an empty directory.The archives from there releases page are also empty, i.e.https://github.com/osxfuse/osxfuse/archive/osxfuse-3.9.0.zip
That’s on purpose. If you are using FUSE for macOS for a commercial softwareproject, feel free to contact me via email. You can find my email on my GitHubpage.
– @bfleischer
Have you ever written a single line of kernel code or debugged a massivelyparallel file system? Trust me, that’s a big deal.
– @bfleischer
This is simply too much work for one person in addition to a full-time job
Then drop it and let someone else maintain it.
– @pmetzger
That’s right, we’ve got ourselves a new season of The Real Housewives ofGitHub! That being said, this actually is a pretty serious issue, and@pmetzger, as a maintainer forMacPorts, has every right to be concerned.
You may also notice that I’ve only linked to random GitHub issues and mailinglist posts. That’s because this licensing change hasn’t been noted in theREADME orLICENSE files ofthe repo–that is, the most obvious (i.e. only) places that people check forthese sorts of things.
We’ll get into why, and how, this happened. But first, some background.
FUSE stands for Filesystem in Userspace, and the name pretty much tellsthe whole story. It’s a Linux kernel module that allows developers to implementa filesystem outside of the kernel, just like a normal application. This vastlysimplifies the development process, since you have access to all of the normallibraries and utilities you use in desktop development. It was mainlined wayback in 2005, and even then it wasn’t a new concept1.
Some notable FUSEs are Google Drive’s File Stream2, sshfs, Keybase’sKBFS, and ntfs-3g. The point is, this is a piece of technology that has beenused and abused endlessly, and that a ton of projects depend on.
As I mentioned earlier, since shortly after FUSE was created, people havewanted their filesystems to run on other operating systems. Windows, bizarrelyenough, seems to get far more love here, with Dokan, Dokany, and WinFsp fillingthe void.
Support for macOS, however, has been… limited, despite the fact that it andLinux have far more similar sets of file operations thanks to POSIX. MacFUSEwas started at Google in 2007 and, from what I can tell, was abandoned sometimearound 2009. osxfuse was then forked from it around 2011, and has been the onlysolution for running your FUSE on macOS since then.
osxfuse is, by necessity, a kernel module (or “kext” in Apple land). Using theBSD VFS interface, it presents itself as a traditional filesystem driver, andthen forwards filesystem operations across the kernel boundary to the FUSE. Atthis high level, it operates very similarly to FUSE on Linux, though obviouslythere are some differences at the lower levels. Since it’s a kext, shipping itto users requires some special provisions.
Now this may come as a shock to some of you, but Apple really doesn’t seem tolike it when third party developers change just about anything about their UX.For instance, they only added an API for adding badge icons to Finder in2014–and that was only because Dropbox just kept reverse engineering itanyway.
Deploying a kext requires it be signed using a special Kernel Extension SigningCertificate, which can only be acquired from Apple. Getting one of these certsrequires going through a fairly rigorous application process. And of course, atthe end of it all, you can be denied with no real recourse. Basically, yourproject lives and dies at the will of Apple–a markedly different approach fromwhat you’re used to if you’re used to the Linux and Windows approaches tothird-party kernel modules.
Now here’s the kicker: Benjamin Fleischer has one of these certificates forosxfuse. In fact, if you google his name, the vast majority of the results areconfused users asking why they’re being prompted about installing software byol’ Benny. What can I say, the man’s a celebrity.
So to quickly summarize:
- osxfuse is used by tons of companies,
- and essentially none of them push fixes upstream.
- Fleischer has been the sole maintainer for years.
- He also hasn’t been paid a penny for this work.
- He also holds a magical, aluminum unibody certificate that prevents mostpeople from forking his module.
- The current codebase is permissively licensed, so he can do with it what hewill.
It doesn’t exactly take a rocket surgeon to see where this is going.
Apple has apparently made some pretty significant changes to kernel modules inthe upcoming macOS Catalina. And according to our subject matter expert,they’re pretty gnarly tosupport. Fortunately, osxfuse 3.10 has support for Catalina!
But there’s a catch. If you go to download thisrelease,you’ll notice a bit of text in the release notes:
The license has changed. Starting with this release, redistributions bundledwith commercial software are not allowed without specific prior writtenpermission. Please contact Benjamin Fleischer.
The last public source code release was in 2017. Now, two years later, just afew short months before the Fucking Catalina ReleaseMixer, Fleischer could finallyget his.
- Apple does Apple things and heavily restricts third-party developers.
- Fleischer, having dealt with malarkey like this for close to a decade,realizes he doesn’t get paid enough for this shit.
- He makes the repo closed source in 2017, but doesn’t mention this to anyone.
- In 2019, after making a bunch of critical changes to the code, he quietlyannounces that the licensing terms of the project are now different.
- At this stage in the proceedings, companies’ choices are to pay up or telltheir users that they can’t use the hot new version of macOS.
As far as monetization strategies go, love it or hate it, you’ve got to givethe guy props.
Uh… probably? As I mentioned, most of the code is under BSD-style licenses.The command line utility to actually mount the damn thing is under the ApplePublic Source License, which has a “soft copyleft.” But in theory, if nofurther changes are made to this part of the code, it already meets therequirements for source code distribution.
Now I’m not a lawyer (yada yada this shouldn’t be considered legal advice), butit seems like all of this is perfectly above board.
Many open source projects take the approach of dual licensing with the GPL.This seems to hit the requirements pretty closely. Noncommercial, open sourcesoftware can use the module for free. And companies or individuals who want todistribute the software in a proprietary project have to pay up. As an examplein the same space, this is the strategy used by WinFsp.
It’s possible that things get weird given Apple’s code signing requirements, soI’m not 100% sure if this strategy would work–that’s more an issue for theFSF’s lawyers than some random programmer on the internet. But the point is,there are probably other options than closing the source.
Well… nothing, really. Mr. Fleischer has come to a determination that keepingthe project open source is not a situation that benefits him. And that’sunfortunate, but at a certain point I really can’t fault him.
The software which he has maintained for the past eight or so odd years hasbeen of enormous benefit to the software community as a whole. Instead of justbeing a Linux-only thing, FUSE became a de facto standard for quicklyspinning up a filesystem that does cool and useful things for users. This wasin part due to his work, as well as the work of many others over the course ofyears.
While some of this may have come off as harsh, it’s really not Fleischer withwhom we should take issue. He wouldn’t be the first maintainer to have gripeswith the ways in which his labor is taken advantage of; nor is he likely to bethe last. Mongo created the SSPL due to similar issues, and Redis Labs added aclause to its license forbidding companies from selling (parts of) itssoftware. Now while osxfuse is in a slightly different domain than thesedatastores, the root cause is the same: companies often reap far more from FOSSthan they sow upstream.
All that aside: it would be super cool for osxfuse to be open sourced again,but I don’t know if I can see that happening in the near future.
The free and open source software movements have done amazing things for theworld, and while I respect the decisions made in this case, I certainly hopethis doesn’t become the new normal. In the meantime, consider sending a couplebucks to the maintainer of your favorite project. And maybe use a copyleftlicense next time you release some code, so that when some random company wantsto use it, you can finesse a cut of the action.
While in isolation this might seem like a minor issue, if looked at as asymptom of a deeper problem… Trust me, it’s a big deal.
Footnotes
FUSE supposedly took its inspiration from the HURD concept of translators. I found this interesting mostly as a historical oddity–the HURD was actually useful for something! ↩
Technically speaking, GDrive File Stream depends on Google’s own fork of osxfuse. But their fork was (for a while, anyway) a bit too close to the original source, and caused conflicts with other osxfuse-based filesystems. Whoopsie. ↩