Userspace FUSE for macOS(fuse-t.org)
fuse-t.org
Userspace FUSE for macOS
https://www.fuse-t.org/
136 comments
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.
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.
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).
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).
With it being stateless, I was referring to just the part where I wanted to point out the difference: file handles are stateless, while FUSE's equivalent (nodeids) are stateful.
Regardless of whether it's an in-memory or persistent solution, the problem remains: fuse-t has little choice but to leak resources of the underlying FUSE file system, as there is no valid point in time in which you can issue FORGET operations. This means that any file system with some form of churn rate will leak memory.
Also note that delegation is effectively optional. If a server simply always replies with OPEN_DELEGATE_NONE, the client has to interact with the file as if it's stored remotely.
There is no need to implement SEQUENCE, by the way. macOS implements NFSv4.0, while SEQUENCE is part of NFSv4.1 and later.
Regardless of whether it's an in-memory or persistent solution, the problem remains: fuse-t has little choice but to leak resources of the underlying FUSE file system, as there is no valid point in time in which you can issue FORGET operations. This means that any file system with some form of churn rate will leak memory.
Also note that delegation is effectively optional. If a server simply always replies with OPEN_DELEGATE_NONE, the client has to interact with the file as if it's stored remotely.
There is no need to implement SEQUENCE, by the way. macOS implements NFSv4.0, while SEQUENCE is part of NFSv4.1 and later.
> macOS implements NFSv4.0, while SEQUENCE is part of NFSv4.1 and later.
Whoa. That's a real mistake. v4.0 is widely considered a "oops, we shouldn't have released this". TIL!
Whoa. That's a real mistake. v4.0 is widely considered a "oops, we shouldn't have released this". TIL!
I don't understand the comment about leaking memory, nfs file handles don't have to be persistent. Besides, how many FUSE filesystems implement FORGET? Anyway this is the reason I went with NFSv4. I started the project with NFS v3 but then discovered many limitations: being stateless, no named attributes, questionable locking support, etc. So Eventually I dropped it and re-implemented everything on NVSv4.
> I don't understand the comment about leaking memory, nfs file handles don't have to be persistent.
As long as the file the NFSv4 file handle refers to is still usable (i.e., linked into the file system), the NFSv4 file handle must remain usable. Note that this is not a universal requirement, but at least one that the macOS NFSv4 client enforces. It only implements FH4_PERSISTENT. This doesn't seem to be documented explicitly, but is somewhat revealed by this printf():
https://github.com/apple/darwin-xnu/blob/main/bsd/nfs/nfs_vf...
> Besides, how many FUSE filesystems implement FORGET?
Any file system that wants to remove files in the background (meaning: not by calling unlink() through the FUSE mount) must likely do proper refcounting on such files, and provide an implementation of FORGET.
For example, a file system that can give information on live football matches may want to remove files/directories belonging to matches that have already ended. In that case you want the node IDs to remain valid, but refer to files that have already been unlinked from the file system hierarchy. The FORGET operation allows you to determine when those files can be removed from the FUSE server's bookkeeping entirely.
Here is an implementation of FORGET that I wrote for Buildbarn:
https://github.com/buildbarn/bb-remote-execution/blob/master...
As long as the file the NFSv4 file handle refers to is still usable (i.e., linked into the file system), the NFSv4 file handle must remain usable. Note that this is not a universal requirement, but at least one that the macOS NFSv4 client enforces. It only implements FH4_PERSISTENT. This doesn't seem to be documented explicitly, but is somewhat revealed by this printf():
https://github.com/apple/darwin-xnu/blob/main/bsd/nfs/nfs_vf...
> Besides, how many FUSE filesystems implement FORGET?
Any file system that wants to remove files in the background (meaning: not by calling unlink() through the FUSE mount) must likely do proper refcounting on such files, and provide an implementation of FORGET.
For example, a file system that can give information on live football matches may want to remove files/directories belonging to matches that have already ended. In that case you want the node IDs to remain valid, but refer to files that have already been unlinked from the file system hierarchy. The FORGET operation allows you to determine when those files can be removed from the FUSE server's bookkeeping entirely.
Here is an implementation of FORGET that I wrote for Buildbarn:
https://github.com/buildbarn/bb-remote-execution/blob/master...
I'm not sure I understand you point, if an inode gets removed, then GETATTR or LOOKUP would fail as it should unless you're talking about open files. In the latter case the inode will get removed when the last open handle to the file is closed
Sure, LOOKUP would obviously fail, as the object is no longer present in the file system under any name. GETATTR is a different story. Consider this sequence of operations:
I think it's important to realise that a FUSE nodeid _does not_ represent an identifier of an inode in the file system. Instead, they are identifiers of the inode in the kernel's inode cache. Every time the object is returned by LOOKUP, MKDIR, MKNOD, LINK, SYMLINK or CREATE, should their reference count be increased. FORGET is called to decrease it again.
$ mkdir foo
$ cd foo
$ rmdir ../foo
$ stat .
16777221 401089477 drwxr-xr-x 2 ed staff 0 64 "Sep 6 06:41:05 2022" "Sep 6 06:41:05 2022" "Sep 6 06:41:05 2022" "Sep 6 06:41:05 2022" 4096 0 0 .
$ touch .
$ stat .
16777221 401089477 drwxr-xr-x 2 ed staff 0 64 "Sep 6 06:45:34 2022" "Sep 6 06:45:34 2022" "Sep 6 06:45:34 2022" "Sep 6 06:41:05 2022" 4096 0 0 .
I think it's important to realise that a FUSE nodeid _does not_ represent an identifier of an inode in the file system. Instead, they are identifiers of the inode in the kernel's inode cache. Every time the object is returned by LOOKUP, MKDIR, MKNOD, LINK, SYMLINK or CREATE, should their reference count be increased. FORGET is called to decrease it again.
TIL about nfs-ganesha. I have yet to digest it all, but ignoring the wonderful usability of sshfs, it seems you should be able to get the functionality of sshfs with nfs-ganesha? Am I missing something?
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.
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).
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).
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.
Maybe, some years later, Windows' WebDAV client has improved. And I can't remember whether macOS WebDAV was better or not.
[deleted]
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.
Fair point, agreed I doubt mount_webdav ends up posix compliant.
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
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
The page appears to be hosted on the new Google Sites.
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.
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.
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
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
https://github.com/macos-fuse-t/fuse-t/blob/main/License.txt
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.)
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.)
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.
This is because Google et. al. will take the code and use it unless you do this. (In which case they’ll reimplement it and not pay you, but at least you tried I guess…)
Because the Apple developer culture just like on the Windows side has always been welcoming to commercial software, that is how one keeps a paycheck doing desktop utilities.
[deleted]
Why does everybody use tcp ports instead of file sockets for local communication?
> 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.
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.
Windows has named pipes. MacOS has UDS and they're not terribly uncommon
Windows also supports UDS now.
I've never seen the UDS acronym to refer to UNIX sockets.
Just call them UNIX sockets.
Just call them UNIX sockets.
They're called UNIX domain sockets.
Just call them UDS.
Just call them UDS.
On the most popular UNIX-like operating system, Linux, there's are literally zero references to UDS to mean UNIX domain sockets.
$ sudo mandb
$ man -K UDS
Windows 10 has support for UNIX sockets.
Wow, interesting - I didn't know that. That is very cool... no more special handling for windows in cross platform handling then it sounds like (at least for UDS).
Windows added UNIX domain sockets in recent years. They work everywhere now.
Depending on what you need to do.
Last I looked things like SCM_RIGHTS.
2 guesses: ignorance, and an assumption that using tcp allows for seamless transition to another host.
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.
But they are not (named) pipes, it’s the same api. Just speak http or whatever over the socket.
Afaik, windows also seems to support it these days
> I guess I'm ignorant then!
We all are in our own ways ;-). I pulled that comment out of my ass so I'm ok with being corrected as appropriate.
We all are in our own ways ;-). I pulled that comment out of my ass so I'm ok with being corrected as appropriate.
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
I guess full stack developers means people who can read the top 5 lines of a stack trace
> I guess full stack developers means people who can read the top 5 lines of a stack trace
C'mon. Do I really need to quote the guidelines to you?
C'mon. Do I really need to quote the guidelines to you?
Oh was not meant as a personal attack or anything. Just general state of the industry
Unix domain sockets have a severe limitation that the path must be a maximum 108 characters.
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
Agreed. It's just that UDS are hard to work with due to this limitation.
This limitation only applies to the file name, as you can chdir to the directory before bind/connect. Unfortunate but not a deal breaker
> you can chdir to the directory before bind/connect
Since working directory is per-process not per-thread, this seems a great way to introduce race condition bugs. It also basically rules it out for anything meant to be used as a library or framework.
Since working directory is per-process not per-thread, this seems a great way to introduce race condition bugs. It also basically rules it out for anything meant to be used as a library or framework.
Working directory can be changed on a per-thread basis on Mac with pthread_chdir_np, and on Linux you can create a thread with the clone syscall and without the CLONE_FS flag to avoid sharing working directory with the rest of the process. I don't know about Windows.
I think the answer on Windows is "No".
One could fork a subprocess, chdir()+socket() there, then pass the socket back to parent over another socket (opened maybe with socketpair().) Should work on any Unix-like which supports SCM_RIGHTS (which is almost everybody, apparently even obscure platforms like AIX, IBM i, z/OS). But not Windows, which doesn't (at least not yet, they may add it at some point.)
Makes one really wish there was a bindat() call:
One could fork a subprocess, chdir()+socket() there, then pass the socket back to parent over another socket (opened maybe with socketpair().) Should work on any Unix-like which supports SCM_RIGHTS (which is almost everybody, apparently even obscure platforms like AIX, IBM i, z/OS). But not Windows, which doesn't (at least not yet, they may add it at some point.)
Makes one really wish there was a bindat() call:
int bindat(int sockfd, const struct sockaddr *addr, socklen_t addrlen, int dirfd);
int funixsockat(int type, int dirfd, const char * name);
In Windows we actually have a way to set the parent directory for a UDS bind or connect, via a socket ioctl. It’s not documented yet, but it’s in the header.
Cool, did not know that. Indeed I see this in shared/afunix.h:
What does the "NOTE: setting the parent path is not thread safe" comment mean? Not thread safe if multiple threads are sharing the same socket? (Which seems like an acceptable limitation.) Or something worse than that?
#define SIO_AF_UNIX_GETPEERPID _WSAIOR(IOC_VENDOR, 256) // Returns ULONG PID of the connected peer process
#define SIO_AF_UNIX_SETBINDPARENTPATH _WSAIOW(IOC_VENDOR, 257) // Set the parent path for bind calls
#define SIO_AF_UNIX_SETCONNPARENTPATH _WSAIOW(IOC_VENDOR, 258) // Set the parent path for connect calls
// NOTE: setting the parent path is not thread safe.
What does the "NOTE: setting the parent path is not thread safe" comment mean? Not thread safe if multiple threads are sharing the same socket? (Which seems like an acceptable limitation.) Or something worse than that?
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.
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.
Linux has an extension that allows an arbitrary string that is not tied to the filesystem. This makes it easier to stay within the limit or you can crypto hash an arbitrarily long string down to 108 chars.
This can be pretty dangerous because it is basically the same as using a TCP socket on localhost (assuming you are speaking of abstract sockets).
Even though you lose the filesystem-based security, you can still use SO_PEERCRED or getpeereid and validate the caller's UID is what you expect, something which Linux doesn't support on localhost TCP sockets. Requiring the client's UID (and maybe GID too) to be the same as your own is a sane default for services intended for per-user usage.
Yeah, abstract sockets, good points about security.
That’s plenty for most applications, no? /var/run/*.sock isn’t that many characters.
For many applications it is enough. For others, such as placing a UDS in a user's home directory or temp folder, it may not be. Often times you don't know ahead of time what the path may be.
Unix sockets should definitely not be in any non-tmpfs filesystem, subdirectories of /run are the sole place they should be.
Care to justify your advice?
They are ephemeral, they hold no data after being closed and backups of them aren't useful. Only the name is needed, therefore a tmpfs is the place to store them.
The name of the socket file/the fact that it exists contains data.
As a result, it's useful to keep them in non-tmpfs paths that can survive a reboot. That way, very simple programs can use them as sort of a config file: `$XDG_HOME/myprogram/do_xyz.sock`.
Additionally, persistent sockets created once at program install time can help coordinate multiple launches of whatever uses them (e.g. by having servers flock(2) the socket or fight over binding to it as a mutex). For programs whose "server" component isn't managed by a service manager, but can instead be launched many times in response to some user action, that can simplify things.
As a result, it's useful to keep them in non-tmpfs paths that can survive a reboot. That way, very simple programs can use them as sort of a config file: `$XDG_HOME/myprogram/do_xyz.sock`.
Additionally, persistent sockets created once at program install time can help coordinate multiple launches of whatever uses them (e.g. by having servers flock(2) the socket or fight over binding to it as a mutex). For programs whose "server" component isn't managed by a service manager, but can instead be launched many times in response to some user action, that can simplify things.
And if I want to run a daemon as a user where should the socket go?
For example the OpenSSH agent uses this path:
/run/user/$UID/openssh_agent
Several things place sockets there, some other stuff places the socket in a subdirectory.
/run/user/$UID/openssh_agent
Several things place sockets there, some other stuff places the socket in a subdirectory.
Does the built-in macOS SMB client support mounting resources via file socket?
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
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
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).
Because TCP is well-known and works both locally and over the network, on just about every networked operating system?
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
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
In practice these problems occur, but more rarely than you're implying.
First, many of the systems that local-use-only-but-served-via-TCP-on-localhost apps use are not multi user. VS Code is a good example; I'd hazard that the vast majority of installs thereof are on systems that don't have simultaneous users logged in.
Second, many localhost-tcp apps do use authentication of a sort; this is simple to set up via a secret that is pre-shared at application installation time.
Third, it's easily possible to use ip[tables] to restrict loopback traffic based on conditions that include user ID or group ID. I'm not sure how many people take advantage of this capability, since doing so reliably would probably imply the "server" component having root so it could impose firewally restrictions on loopback users at startup time.
First, many of the systems that local-use-only-but-served-via-TCP-on-localhost apps use are not multi user. VS Code is a good example; I'd hazard that the vast majority of installs thereof are on systems that don't have simultaneous users logged in.
Second, many localhost-tcp apps do use authentication of a sort; this is simple to set up via a secret that is pre-shared at application installation time.
Third, it's easily possible to use ip[tables] to restrict loopback traffic based on conditions that include user ID or group ID. I'm not sure how many people take advantage of this capability, since doing so reliably would probably imply the "server" component having root so it could impose firewally restrictions on loopback users at startup time.
I cannot understand this. It may not just be me. Would you like to try again?
> it's not almost enough... to not
That is not a standard English structure and I can't unwrap all the negatives and follow it.
> i notation
(?)
> van be used like that
(?) "can be"
> vind to localhost
(?) "bind to"
> an electron is running on port
(?)
> it's not almost enough... to not
That is not a standard English structure and I can't unwrap all the negatives and follow it.
> i notation
(?)
> van be used like that
(?) "can be"
> vind to localhost
(?) "bind to"
> an electron is running on port
(?)
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.
Hopefully they’ll open those APIs up for 3rd party usage on the Mac next year.
My impression was that there were no plans to do this.
"You're gonna microkernel whether you want to or not! Only our devs are allowed to crash the system."
--Apple
--Apple
You say that like it's a bad thing.
Why not use the file provider API? https://developer.apple.com/documentation/fileprovider
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.
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.
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
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
Because your software was written against FUSE and you don't wanna spend time rewriting it to accommodate Apple users.
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.
It's impossible, see my other reply.
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.
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.
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.
Such a shame that it's not really open source. The idea of using NFSv4 is awesome though.
> 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"
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"
You're assuming that everyone's "prod" is a Linux server. I would say that MacOS needs containers for developing Darwin software.
Yes, I think that's a perfectly reasonable assumption given that (AFAIK) the only current "containerization" (as GP used that word) strategy is on Linux. BSD has jails and Solaris has something similar, but as far as "fire this thing up with its own pid, network, and fs namespacing, and allow me to constrain it easily" that's just Linux. I guess put another way: you run Darwin in production?
As for the latter, macOS actually does have what they call Containers (https://developer.apple.com/library/archive/documentation/Se...) but as best I can tell such a thing requires opt-in from the app, which kind of defeats the purpose of running untrusted software IMHO. I actually only learned about that Containers stuff from trying to find where in the hell 1Password 8 stores its actual sqlite file: `$HOME/Library/Group Containers/2BUA8C4S2C.com.1password/Library/Application Support/1Password/Data/1password.sqlite`
As for the latter, macOS actually does have what they call Containers (https://developer.apple.com/library/archive/documentation/Se...) but as best I can tell such a thing requires opt-in from the app, which kind of defeats the purpose of running untrusted software IMHO. I actually only learned about that Containers stuff from trying to find where in the hell 1Password 8 stores its actual sqlite file: `$HOME/Library/Group Containers/2BUA8C4S2C.com.1password/Library/Application Support/1Password/Data/1password.sqlite`
>BSD has jails and Solaris has something similar, but as far as "fire this thing up with its own pid, network, and fs namespacing, and allow me to constrain it easily" that's just Linux.
Nope, you get the same thing with jails, just easier. Jails weren't developed by a company living off selling support for it, you know :-)
Nope, you get the same thing with jails, just easier. Jails weren't developed by a company living off selling support for it, you know :-)
I guess put another way: you run Darwin in production?
Anyone who builds software for MacOS, iOS, or iPadOS targets Darwin as their production environment. This includes end user applications and tools used by other devs.
Anyone who builds software for MacOS, iOS, or iPadOS targets Darwin as their production environment. This includes end user applications and tools used by other devs.
Thanks for this. I have a library that uses 1Password files and have not updated for v8.
Be forewarned that (to the best of my knowledge) they haven't, and likely don't intend, to document the sqlite structure. The contents in the sqlite file seems to mirror the api responses from their new rest apis, so their Burp analyzer (https://github.com/1Password/burp-1password-session-analyzer...) may help matters, as will the absolutely essential reading (https://darthnull.org/inside-1password/) along with its code (https://github.com/dschuetz/1password#readme) and I just found this while digging up those other links: https://github.com/mickaelperrin/onepassword-local-search/bl...
> "containerization" (as GP used that word)
No one used that word
No one used that word
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.
I could probably get by with the chroot support that macOS has, but I never manage to find the motivation.
You can install multiple versions of PHP and Node alongside each other just fine using Homebrew:
brew install [email protected] [email protected] [email protected] [email protected] [email protected] # and soon [email protected]
brew install node@18 node@16 node@14 node@12 node@10Most people don't want to install and uninstall software at the system-level like that. They'd rather have nicely isolated disposable containers for individual projects.
Installing multiple versions is solved, changing the environment easily, not so much, I think
I'm not sure of the specifics with Homebrew, but with MacPorts, I have both PHP 7.4 and 8.1 running via FPM and serving sites rather trivially. The basics: Install both php74-fpm and php81-fpm, configure the former to put its socket at /var/run/php74-fpm.sock and the latter at /var/run/php81-fpm.sock, configure nginx's domain-specific config files to look for the FastCGI socket that the respective path, use MacPorts to load both daemons, and away you go. I imagine a similar approach would be possible with Homebrew.
I edit Apache’s config files and reload it every time, but I’m not pleased with that solution.
Is there not a way in Apache to specify a different path for the FastCGI socket based on the domain name? It's been a long time since I've used Apache but I'd be surprised if the functionality wasn't somewhere in its inscrutable config file syntax.
That’s a really cool idea, never though of that. I’ll investigate, thanks! Sorry for the late reply.
or just use asdf
I wasn't aware of it, thanks. I'm not it's exactly what I want though. Can it easily start and stop daemons? Can it assign different ports to different versions?
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!
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!
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.
Well I don't see how FUSE is broken, while NFS surely is (it happened to me that I had processes that were in a state that was impossible to terminate without rebooting - this was because they did set locks in the NFS filesystem that they were never released, thus not allowing the processes PID to terminate and thus generating a slow resource leak in the kernel!)
Anyway, FUSE is more efficient, since the application directly talks to the kernel, without passing trough the TCP/IP stack and the NFS driver. It cannot be possibly implemented more efficiently without implementing the FS as a proper kernel module.
Also NFS introduces a security problem: authentication is tricky to implement, and I don't think it's used in this application: that allows any user on the computer to access, via the NFS API trough an userspace implementation the filesystem, bypassing any permission of the filesystem itself.
Finally NFS cannot support (as far as I know) all the features that are possible with a FUSE filesystem. And since it's based on a network protocol (meaning client and server may be on different machines with a non reliable network connecting them) something will probably never be supported/work reliably (for example inotify).
Anyway, FUSE is more efficient, since the application directly talks to the kernel, without passing trough the TCP/IP stack and the NFS driver. It cannot be possibly implemented more efficiently without implementing the FS as a proper kernel module.
Also NFS introduces a security problem: authentication is tricky to implement, and I don't think it's used in this application: that allows any user on the computer to access, via the NFS API trough an userspace implementation the filesystem, bypassing any permission of the filesystem itself.
Finally NFS cannot support (as far as I know) all the features that are possible with a FUSE filesystem. And since it's based on a network protocol (meaning client and server may be on different machines with a non reliable network connecting them) something will probably never be supported/work reliably (for example inotify).
You’re right, a proper userspace filesystem implementation is the preferable route. I was mostly impressed by the neet hack.
While digging up a link for a separate comment, I found (https://macoscontainers.org/) which points to: https://github.com/containerd/containerd/discussions/5525
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.
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.
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
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
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.)
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.)
> 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?)
Windows has both NFS server and client. It's not enabled by default, but it can be enabled. It has supported NFSv4 since Windows 8.
Windows has both NFS server and client. It's not enabled by default, but it can be enabled. It has supported NFSv4 since Windows 8.
". It has supported NFSv4 since Windows 8."
Only as a server. https://docs.microsoft.com/en-us/windows-server/storage/nfs/...
It has never supported nfsv4 as a client.
Only as a server. https://docs.microsoft.com/en-us/windows-server/storage/nfs/...
It has never supported nfsv4 as a client.
Cool. So to update your list:
> Things that support SMB out of the box: Windows, Mac, Linux, FreeBSD, NetBSD, illumos
> Things that support NFSv4 out of the box: Windows, Mac, Linux, FreeBSD, OpenBSD, NetBSD, illumos
OpenBSD is the only real difference here. (And if "install something from ports" counts as "out of the box", there is no difference.)
There is still somewhat of a difference in ease-of-use though. For NFS, Windows users have to enable an OS feature which is not enabled by default. (I suppose one could automate that in the installer, run a PowerShell script for example.) Not sure how true that is for other platforms.
It still raises the question of why one might prefer NFSv4 vs SMB.
> Things that support SMB out of the box: Windows, Mac, Linux, FreeBSD, NetBSD, illumos
> Things that support NFSv4 out of the box: Windows, Mac, Linux, FreeBSD, OpenBSD, NetBSD, illumos
OpenBSD is the only real difference here. (And if "install something from ports" counts as "out of the box", there is no difference.)
There is still somewhat of a difference in ease-of-use though. For NFS, Windows users have to enable an OS feature which is not enabled by default. (I suppose one could automate that in the installer, run a PowerShell script for example.) Not sure how true that is for other platforms.
It still raises the question of why one might prefer NFSv4 vs SMB.
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.
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"
Also, https://github.com/macos-fuse-t/fuse-t/blob/main/License.txt appears to be "playing lawyer"
> 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)
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)
Aside from the great sibling observation, I'll pile onto that by pointing out they seem to have truncated the URL for their LGPL repo citation
IANAL-either but my mental model is that one should not "blaze trails" in making up licenses. I find it does not pass the straight-face test that no other license in the known world captures the author's intentions, so they had to make one up on the fly, typos and all
IANAL-either but my mental model is that one should not "blaze trails" in making up licenses. I find it does not pass the straight-face test that no other license in the known world captures the author's intentions, so they had to make one up on the fly, typos and all
For one thing, they copied the clauses from the BSD license, including references to “the following disclaimer”, but omitted the disclaimer itself.
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
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
A new project aims to deliver libfuse for mac without using kernel extensions.
Could this be done using DriverKit
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).
You should send feedback
Maybe?
Maybe they also shouldn't ship garbage that doesn't work and expect others to debug it?
Maybe this should also happen before you deprecate and make it essentially impossible to install kext's? (It's possible, but trying to walk users through it is a great way to lose 99% of your user base instantly)
(My experience with driverkit is identical to the parent's)
The whole "we removed it for security reasons" is also a hilarious facade.
The linux kernel has a much more expansive (heck, crazy!) driver interface and number of drivers.
Yet, the rate of system compromise due to them vs applications/servers is probably 99 to 1 in favor of applications/servers.
Maybe they also shouldn't ship garbage that doesn't work and expect others to debug it?
Maybe this should also happen before you deprecate and make it essentially impossible to install kext's? (It's possible, but trying to walk users through it is a great way to lose 99% of your user base instantly)
(My experience with driverkit is identical to the parent's)
The whole "we removed it for security reasons" is also a hilarious facade.
The linux kernel has a much more expansive (heck, crazy!) driver interface and number of drivers.
Yet, the rate of system compromise due to them vs applications/servers is probably 99 to 1 in favor of applications/servers.
That’s because applications have a bunch of easy logic bugs to exploit rather than weird memory corruption you have to wrangle with in a driver, not because the drivers are any more secure.
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
> 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
ocsmount for WebDAV is also based on a local NFS server.
https://ocsmount.com/
https://ocsmount.com/
In sore need of FUSE for macOS on Apple Silicon, without downgrading system security. Clever trick to use NFS behind the scenes.
Do binaries compiled and linked to macfuse run unmodified with FUSE-T, or should they be recompiled?
If only the 9pfs protocol was wildly implemented, we'd not want fuse at all!
Like buying a tricycle, for the price of a 250cc motorcycle, and wrenching a 20cc engine on it.
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. :-(