Userspace FUSE for macOS

https://www.fuse-t.org/

by freebeer2 • 4 years ago

301 134 4 years ago

fuse-t.org

freebeer2• 4 years ago

A new project aims to deliver libfuse for mac without using kernel extensions.

keepquestioning2• 4 years ago

Could this be done using DriverKit

mdaniel9• 4 years ago

linky: https://developer.apple.com/documentation/driverkit

The drivers you build with DriverKit run in user space, rather than as kernel extensions, which improves system stability and security. You create your driver as an app extension and deliver it inside your existing app.

makes it seem like every consumer who wants to use something FUSE-y would have to ship their own impl, right?

and I shudder to think of the heartache required with signing or whatever Apple gatekeeping is going on nowadays

concerned_ctzn5• 4 years ago

The author here. DriverKit is really a no-go. A while back I was asked to do a project based on DriverKit, it took me nowhere because of countless bugs and semi-implemented features, worse yet, it caused system crashes (and it was supposed to be stable).

concerned_ctzn5• 4 years ago

https://github.com/macos-fuse-t/fuse-t

mdaniel9• 4 years ago

That "repo" appears to exist solely for housing the release artifacts, for those who came to the comments looking for "the goods"

Also, https://github.com/macos-fuse-t/fuse-t/blob/main/License.txt appears to be "playing lawyer"

TimTheTinker• 4 years ago

Also, https://github.com/macos-fuse-t/fuse-t/blob/main/License.txt appears to be "playing lawyer"

Do you have any specific concerns with the text of the license? The text seems clear enough that there don't appear to be any potential liabilities from using the software in a personal capacity.

As I understand it, the worst that could happen is that the license/software author could unknowingly incur liabilities from statutory or implied warranties - i.e. they left out some important exclusions that could be brought to bear if a plaintiff successfully construed the license as a contract.

(IANAL, but I've read a lot about software licenses over the years and have dealt with a legal challenge related to dual commercial/OSS licensing)

rgovostes2• 4 years ago

Unfortunately, like macFUSE, this is not really open source. The license appears to be BSD-like for non-commercial use only. Also like macFUSE, the project uses GitHub but the source code is not available.

https://github.com/macos-fuse-t/fuse-t/blob/main/License.txt

skissane10• 4 years ago

The developer says they will release source code soon – https://github.com/macos-fuse-t/fuse-t/issues/1#issuecomment... – although keeping the restrictive license.

Apple is introducing user-space file system technology in macOS – LiveFS/UserFS/com.apple.filesystems.lifs – some of the infrastructure turned up in Monterey, in Ventura it is actually being used for mounting FAT/exFAT filesystems.

It looks like for now Apple is keeping the API Apple-internal only (although I haven't looked at the Ventura SDK, so I could be wrong about that). But if Apple made the API public, it could be the death-knell of all these commercial FUSE-alternatives for macOS offerings. (Even if Apple's API isn't FUSE-compatible, if it is close enough, someone could easily open-source a translation layer – likely to be a lot simpler than bridging FUSE to an NFS server.)

ianlevesque• 4 years ago

They have the right to use whatever licensing they want, but it is strange that this one area - FUSE on Mac - consistently attracts developers using weird license restrictions.

EdSchouten6• 4 years ago

What a coincidence! For a project that I maintain (Buildbarn, a distributed build cluster for Bazel) I recently generalized all of the FUSE code I had into a generic VFS that can both be exposed over FUSE and NFSv4. The intent was the same: to provide a better out of the box experience on macOS. Here's a design doc I wrote on that change. Slight warning that it's written with some Buildbarn knowledge in mind.

https://github.com/buildbarn/bb-adrs/blob/master/0009-nfsv4....

Fortunately, fuse-t doesn't make any of my work unnecessary. Buildbarn uses go-fuse, which talks to the FUSE character directly instead of using libfuse. fuse-t would thus not be a drop-in replacement. Phew!

PS: A bit unfortunate that fuse-t isn't Open Source. :-(

EdSchouten6• 4 years ago

Replying to my own comment:

I do wonder how this library deals with some of the fundamental differences beween FUSE and NFSv4. For example, with FUSE the kernel and server share intimate knowledge on which part of the file system lives in the kernel's inode cache. Only when the kernel issues a FORGET call, may the server drop information corresponding to a given nodeid.

As NFSv4 is designed to be stateless, servers may need to be able to process requests containing arbitrary file handles, regardless of how long ago they were returned as part of some prior request. You therefore see that in-kernel implementations of NFS servers rely on special file system methods to resolve objects by file handle, in addition to being able to resolve by path.

This means that if you implement FUSE on top of NFSv4, you will most likely not be able to purge any state. Your FUSE file system's FORGET method will probably never be called. This means that memory usage of fuse-t will most likely just keep on growing as time progresses? Or it announces itself as using file handle mode FH4_VOLATILE_*, but UNIX-like NFSv4 clients hardly ever know how to deal with that.

boulos2• 4 years ago

Nit: NFSv3 is stateless, V4 isn't (sessionid and clientid permit stateful handling of locks and shares).

I would assume this person is just doing an in-memory "NFS server" that would keep all of that state around. So it's more like a FUSE-compatible layer that speaks NFSv4 as a "front end" (since NFS clients are better than "ha ha, surprise! This FUSE backend is networked and can fail on weird ways").

I'm not sure how they chose to translate things like DELEGATE, SEQUENCE, and so on (probably just reply with an error). But for basic OPEN, READ, WRITE, etc. it's all fairly straightforward.

I had hoped they used nfs-ganesha for the NFS server / frontend, but the attributions file suggests they probably rolled their own (and thus is going to be full of bugs and immature for quite some time).

fulafel• 4 years ago

The DB for the necessary state could also be on-disk. Maybe in practice you can expire things after a reasonably long time, like a week, even though that's not strictly spec conforming.

justsomeadvice02• 4 years ago

You might look at webdav instead, which has actual existing library implementations (unlike NFSv4), supports user/pass auth (in some cases you don't want wide-open services on loopback) and is based on HTTP; that would make the whole thing easier. Various projects offer a webdav combat layer, see cryptomator for one example: https://docs.cryptomator.org/en/latest/desktop/vault-mountin...

I went down the NFS road long ago - I somewhat (??) remember that coaxing macOS to mount_nfs on loopback is actually a PITA (I remember having to activate 127.0.0.* and mount 127.0.0.2).

skissane10• 4 years ago

I remember, around 10 years ago, mucking around with WebDAV, and discovering many WebDAV clients were extremely crapulent. Especially on Windows.

Maybe, some years later, Windows' WebDAV client has improved. And I can't remember whether macOS WebDAV was better or not.

EdSchouten6• 4 years ago

For Buildbarn I need to provide a writable file system that acts in a POSIX compliant way. I'm not convinced WebDAV could provide that.

mdaniel9• 4 years ago

I don't know what's going on with the google.com/url encoding of the links on the submitted article

Also, one will want to be aware of the currently unsupported features <https://github.com/macos-fuse-t/fuse-t/wiki#unsupported-feat...> since the submitted article appears to be aspirational

tech234a• 4 years ago

The page appears to be hosted on the new Google Sites.

HHad3• 4 years ago

This is great! I hope that this project enables those many FUSE-related applications to return to Homebrew since an open-source FUSE provider is now available again.

I am curious though why a NFSv4 server was chosen over wrapping Apple's File Provider API [1], which seems to be the native method for providing virtual file systems from user space on macOS since macOS 11.5. After glancing over the API I guess it's because FPEs are too high-level to implement FUSE properly, but I'd be glad if you can share any details to satisfy my curiosity.

[1] https://developer.apple.com/documentation/fileprovider

EDIT: Errata, I assumed it was open-source, but it is not. Too bad :( -- but at least this will eventually provide a more stable FUSE experience on macOS.

mdaniel9• 4 years ago

It seems based on the associated WWDC video (https://developer.apple.com/videos/play/wwdc2021/10182/) that API appears to be for making your own Dropbox/GDrive/OneDrive client, and not "present this totally fake filesystem" scenario

tambourine_man8• 4 years ago

macOS really needs a decent FUSE implementation. That and some sort of container story.

Such a shame that it's not really open source. The idea of using NFSv4 is awesome though.

mdaniel9• 4 years ago

That and some sort of container story.

While off-topic for this thread, I don't think that's going to do what you expect. If you snapped your fingers and XNU suddenly had cgroups and other namespace trickery required to make containers operate, you'd still have the grave problem of "containers are not virtual machines" and thus an XNU container would only run Darwin binaries, so you're back to the old days of "run one exe locally, run another in prod"

tambourine_man8• 4 years ago

Yeah, but easily switching between specific version of PHP, MySQL, Node.js, etc, without messing with /usr/local/bin and brew while having full speed disk access goes a long way.

I could probably get by with the chroot support that macOS has, but I never manage to find the motivation.

clhodapp2• 4 years ago

You're assuming that everyone's "prod" is a Linux server. I would say that MacOS needs containers for developing Darwin software.

alerighi2• 4 years ago

Awesome, to me it seems terrible, and something that can break anytime. You have two layers of translation, the actual FUSE filesystem implementation that uses the FUSE API to communicate with something that emulates a FUSE API in userspace to then talk via NFS to the kernel. NFS is broken in a lot of ways, especially with file locking, that could result in deadlocks.

Really FUSE should be implemented in the kernel itself, it was meant to do so, a kernel-side layer to allow implementing a filesystem userspace efficiently. When they created fuse NFS already existed, and if they decided to create a new protocol and add it to the kernel, rather that something on top of NFS or directly exposing a NFS server in applications, a reason maybe existed right?

Not having a stable FUSE implementation is one of the many reasons that made me abandon macOS and return to the combination of Windows and Linux. Even Windows has a mostly decent open-source FUSE implementation!

tambourine_man8• 4 years ago

You’re right, a proper userspace filesystem implementation is the preferable route. I was mostly impressed by the neet hack.

trasz2• 4 years ago

NFS4 is broken in fewer ways FUSE is, and it has the advantage of being standardised and implemented by everything. The natural way forward would be to get rid of FUSE in this stack, not NFS4.

mdaniel9• 4 years ago

While digging up a link for a separate comment, I found (https://macoscontainers.org/) which points to: https://github.com/containerd/containerd/discussions/5525

als0• 4 years ago

In sore need of FUSE for macOS on Apple Silicon, without downgrading system security. Clever trick to use NFS behind the scenes.

orangea2• 4 years ago

Why not use the file provider API? https://developer.apple.com/documentation/fileprovider

lillecarl• 4 years ago

Because your software was written against FUSE and you don't wanna spend time rewriting it to accommodate Apple users.

orangea2• 4 years ago

I meant why not make a project like this that emulates the FUSE API, but use the file provider API to present the file system to the OS instead of NFS. It would have the advantage that it would be better integrated with the OS, for example you can display upload progress indicators on files in Finder. Maybe that can also be done with NFS though, I don't know.

mathiasgredal• 4 years ago

I found the api incredibly hard to use as someone who hasn't used swift or macOS API's before. Because of the way some of the code runs as a separate plugin from the main app, you can't really use traditional logging as a debug tool. There is also a lot of split state to be handled. You have to provide sync anchors and diffed tree updates to change the folder contents, which just aren't available with most backends.

I started on a program to mount a website resource directory on your computer using this api, but I gave up due to the restrictions of the api: https://github.com/mathiasgredal/Itslearning

4ad2• 4 years ago

The File Provider API is very limited. In particular, it can't be used to implement file systems where the directory hierarchy is dynamic. It can't materialize directories on `chdir(1)`, for example.

The design was obviously tailored for providers that implement real disk files, like Dropbox and Apple's own iCloud Drive.

Btw, Apple also ships with an undocumented 9P implementation. It seems to be used for mounting the host filesystem in virtualized guests. It is unclear if it can be made to work over a normal (non-PCI) transport like TCP.

jbverschoor8• 4 years ago

Why does everybody use tcp ports instead of file sockets for local communication?

pstuart2• 4 years ago

2 guesses: ignorance, and an assumption that using tcp allows for seamless transition to another host.

jbverschoor8• 4 years ago

Api is still socket api.. AF_INET vs AF_UNIX. It takes a few lines of code to have to option to switch between. Ignorance makes sense..

I guess full stack developers means people who can read the top 5 lines of a stack trace

klabb3• 4 years ago

I guess I'm ignorant then! When I looked up domain sockets and so on it turned out to be different APIs for different OS:s, and it's significantly nicer to rely on a single API surface from the std lib. Maybe it's a habit thing as well, but to me pipes are more esoteric and harder to find docs about than network sockets.

inetknght• 4 years ago

Why does everybody use tcp ports instead of file sockets for local communication?

In my experience it's because Windows and mac developers aren't aware of local file sockets. Windows API, in particular, doesn't have a similar concept if I recall.

duped• 4 years ago

Windows has named pipes. MacOS has UDS and they're not terribly uncommon

10000truths2• 4 years ago

Windows 10 has support for UNIX sockets.

origin_path• 4 years ago

Windows added UNIX domain sockets in recent years. They work everywhere now.

searealist7• 4 years ago

Unix domain sockets have a severe limitation that the path must be a maximum 108 characters.

jbverschoor8• 4 years ago

Sure, but all these services listening on ports, sometimes not even bound to localhost is just shitty. There's no authentication. and it's actually a huge contributor to database dumped online. Besides the security, ease of selecting a path vs a free port, it's also faster

10000truths2• 4 years ago

That’s plenty for most applications, no? /var/run/*.sock isn’t that many characters.

skissane10• 4 years ago

Is anybody trying to lift that limitation? It seems like an obvious target for kernel devs to tackle.

If Linux and *BSD did it (especially if they adopted a mutually compatible implementation), the POSIX standardisation team (Austin Group) would likely be interested in adding it to POSIX, and Windows/macOS/AIX/etc will likely follow their example sooner or later.

chrismonsanto2• 4 years ago

This limitation only applies to the file name, as you can chdir to the directory before bind/connect. Unfortunate but not a deal breaker

concerned_ctzn5• 4 years ago

tcp ports are much more versatile, you can expose it to the outside world as opposed to unix sockets. Now exposing an nfs server to the outside can lead to interesting possibilities: for example you can implement a local fuse file system which can be mounted remotely through the NFS. It's highly not recommended at this moment because there's no authentication implemented

FullyFunctional2• 4 years ago

Is there any fundamental reason you couldn't do both? Presumably local sockets have less overhead (and I do prefer not to open ports unless needed).

lxgr• 4 years ago

Does the built-in macOS SMB client support mounting resources via file socket?

jbverschoor8• 4 years ago

The bsd mount_nfs code uses AF_INET. Which makes sense. But I got triggered by the fact that is yet another app listening to ip

userbinator• 4 years ago

Because TCP is well-known and works both locally and over the network, on just about every networked operating system?

jbverschoor8• 4 years ago

It’s not almost enough for all developers to not just simply bind to 0.0.0.0.

It’s not well known enough, looking at the recent thread where people are amazed that the i notation is simply a 32bit number van can be used like that. Or even http://0xd1d8e6f0

For example, even if you do vind to localhost, anyone on your system can access your service. Let’s say an electron is running on port 5555. A guest user on your system can just access the electron app. If this app happens to be vscode, you now have full access.

It’s just plain stupid. You basically nuked multi user security. Better run dos then

mrpippy• 4 years ago

macOS Ventura has moved some lesser-used file systems (FAT, exFAT) out of the kernel to user-space, I believe using a private framework developed for iOS (when that added USB mass-storage support).

Hopefully they’ll open those APIs up for 3rd party usage on the Mac next year.

saagarjha3• 4 years ago

My impression was that there were no plans to do this.

guruz• 4 years ago

ocsmount for WebDAV is also based on a local NFS server.

https://ocsmount.com/

schappim• 4 years ago

FUSE really demonstrates the unreasonable effectiveness of file systems as an interface.

junon• 4 years ago

Or perhaps the unreasonable ineffectiveness of current-day IPC mechanisms.

skissane10• 4 years ago

What advantages does NFSv4 have over SMB/CIFS for this use case?

I have had the same idea myself before, but with a more cross-platform scope (Linux and Windows too, not just macOS). Whatever it flaws, SMB/CIFS has the advantage of being supported out-of-the-box on more platforms than NFSv4 is.

chungy2• 4 years ago

Are you sure about that?

Things that support SMB out of the box: Windows, Mac

Things that support NFSv4 out of the box: Windows, Mac, Linux, FreeBSD, OpenBSD, NetBSD, illumos

skissane10• 4 years ago

The Linux kernel contains both NFS and SMB clients – so in that sense, supports both equally "out of the box". Whether either or both are compiled-in (or available as loadable modules) will depend on the distribution.

Windows has an NFS client, but it is an additional OS feature which isn't installed by default (and I believe its NFS version support is somewhat outdated?)

Whether Linux distributions install the NFS and/or SMB client support by default, or require an additional package install for either or both, is really going to depend on the distribution (and its installation options)

FreeBSD, NetBSD and Illumos also include SMB client support, but I don't know how easy it is to use them as compared to their NFS clients. (From what I understand, OpenBSD pointedly has first-class support for NFS but not SMB: NFS has an in-kernel client, for SMB you have to use a user-space NFS-to-SMB translation daemon, which is in their ports tree.)

realloc• 4 years ago

I built something similar for a personal project (though not using the FUSE API) with Samba running locally. Samba has a VFS API which isn’t terrible complicated and lets you accomplish mostly the same thing: https://wiki.samba.org/index.php/Writing_a_Samba_VFS_Module

The only problem I ran into was not being able to bind to 127.0.0.1:445, or connect to a different port, on Windows. I ended up writing a small pcap program that would look for packets going out to some other ip and replay them back at localhost on the port samba was running on, so Windows thought it was connecting to a remote machine. It was a ridiculous solution and I’m sure there’s a better way, but it worked for what I needed.

ninefathom• 4 years ago

"You're gonna microkernel whether you want to or not! Only our devs are allowed to crash the system."

--Apple

lproven2• 4 years ago

You say that like it's a bad thing.

0xedd• 4 years ago

Like buying a tricycle, for the price of a 250cc motorcycle, and wrenching a 20cc engine on it.

lvh• 4 years ago

This is super smart. I've been working on a pet project that requires a VFS, and I ended up with a FUSE impl for Linux (and macOS if so inclined) and a userspace (specifically, JVM) NFSv4 impl :D Really excited to throw out some code.

netheril96• 4 years ago

Do binaries compiled and linked to macfuse run unmodified with FUSE-T, or should they be recompiled?

opless• 4 years ago

If only the 9pfs protocol was wildly implemented, we'd not want fuse at all!

vaxman• 4 years ago

This is a Bad idea.

Do you expect Apple has any consideration that things like this are happening inside the usermode processes when its System suspends and compresses or decompresses their memory of or throttles them by flinging them back and forth to different classes of CPU cores or analyzes them to look for other efficiencies that they don’t talk about publicly (network, thermal, sandbox, etc). If Apple wants FUSE, it will build a carve-out (in the form of a framework) like it did for virtualization. If you still want to use FUSE, maybe try System76’s Pop!_OS or find The [Apple] Way to accomplish your client’s goal.

https://youtu.be/1LHuEvw56F8

Userspace FUSE for macOS

Related Stories