6 ms·

FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

213 points by nimish 3y ago

PlutoIsAPlanet 3y ago
Why is there a GitHub and no source code?
- fathyb 3y ago
  Does not answer your question directly, but related: https://github.com/macos-fuse-t/fuse-t/issues/1#issuecomment-1420347389 https://github.com/macos-fuse-t/fuse-t/issues/1#issuecomment... > The project consists of two components: libfuse and fuse-t server. libfuse is LGPL licensed and can be downloaded from here: macos-fuse-t/libfuse [1]. You can modify and build it as you wish, the build instructions are provided in the README file. The fuse-t server on the other hand is a proprietary component, it's written in go and doesn't link to or includes anything GPL related, all respective copyright owners are mentioned in License.txt file [...] [1] https://github.com/macos-fuse-t/libfuse https://github.com/macos-fuse-t/libfuse
  - kelnos 3y ago
    Weird that early in the issue comments the author claims they're going to release source for fuse-t, but then later in the comments changes course and says it's proprietary. Sounds like they originally wanted to release it as open source, but under a restrictive non-commercial license (which is fine, I guess), but then has gone back on that promise. I'm not gonna be one of those "proprietary software is immoral" people, but it just rubs me the wrong way to see someone take a concept/protocol that was originally developed in the open and released as open source (the Linux version of FUSE itself), and then build something proprietary.
    - PlutoIsAPlanet 3y ago
      Especially something like FUSE where it’s potentially the middle man of personal data. If there’s concern about other companies profiteering, release it under a license that prevents such and those companies can pay to license under something else. This approach could even be useful on Linux where fuse isn’t viable (e.g inside containers)
      - flakes 3y ago
        > This approach could even be useful on Linux where fuse isn’t viable (e.g inside containers) By viable do you mean secure? You can definitely use FUSE within containers, but you do have to cap-add SYS_ADMIN.
        Conan_Kudo 3y ago
        Unprivileged FUSE has been a thing for a while now: https://zameermanji.com/blog/2022/8/5/using-fuse-without-root-on-linux/ https://zameermanji.com/blog/2022/8/5/using-fuse-without-roo...
    - deleted 3y ago
      [deleted]
  - soraminazuki 3y ago
    I respect the author's choice to use a proprietary license, but I wish they'd been honest about it. I've been tracking that GitHub issue when FUSE-T came out. Initially, the author promised to open source. But then there was a long silence, after which the issue was closed as "completed" without any explanation. It's unfortunate because proprietary software requires more trust for users. The lack of communication demonstrated here is concerning.
- deleted 3y ago
  [deleted]
- rgovostes 3y ago
  There are two FUSE implementations for macOS and neither is open source, unfortunately. One reason: it’s a critical component of several profitable, commercial products, but the authors of then-open source FUSE implementations found that none of those companies were willing to financially support their work. Those authors also haven’t seemed interested in crowdfunding when it has been proposed.
  - xaerise 3y ago
    They actually tried with crowdfunding, but it didn't go well. Mostly because German laws and other things.
  - krackers 3y ago
    See https://www.theregister.com/2019/12/16/fuse_macos_closed_source/ https://www.theregister.com/2019/12/16/fuse_macos_closed_sou... for more info. I wonder why a dual-licensing approach was not pursued though, e.g. some viral license (AGPL?) for the open-source part. This could have the same benefit of getting companies to negotiate an explicit (paid) license agreement while still making source available.
- blackpanda467 3y ago
  From the author: right now fuse-t cannot be made open sourced because it won't play nice with existing contracts. You can try my other project which is open source and can be an alternative to fuse: https://github.com/macos-fuse-t/go-smb2 https://github.com/macos-fuse-t/go-smb2
nextfx 3y ago
I've been using mksquashfs to make full-system backups lately, but had to resort to using unsquashfs for recovering files. This combined with squashfuse might come in handy.
EdSchouten 3y ago
Previously discussed here: https://news.ycombinator.com/item?id=32726166 https://news.ycombinator.com/item?id=32726166
Reason077 3y ago
It’s surprising that given Apple’s war on kexts, they still haven’t come out with a proper API for implementing local user-space filesystems. It seems like this exists for remote filesystems (eg: Google Drive, Dropbox), but not for filesystems on local storage devices? This sounds like a nice workaround, though!
- rgovostes 3y ago
  Yes, an Apple-supported API is likely coming. They’ve been gradually providing userspace alternatives for kernel extensions. Their API isn’t likely to be FUSE but hopefully the community will develop a translation layer. I wonder if one of the holdups is that they don’t want a profusion of filesystems and would prefer everyone use ExFAT or APFS. Data loss/corruption ultimately results in more support calls and headaches for them, after all.
  - tambourine_man 3y ago
    It’s been coming for so long that I lost hope.
  - macshome 3y ago
    Apple started replacing their own file system (and networking) kexts with user-mode file systems in macOS 13. Right now its locked up behind some private entitlements though. Hopefully they open it up more in the future. For a quick overview check out a blog post on threedots. https://threedots.ovh/blog/2022/06/quick-look-at-user-mode-file-systems-on-macos-ventura/ https://threedots.ovh/blog/2022/06/quick-look-at-user-mode-f...
    - strangemonad 3y ago
      It’s certainly been interesting watching the multi-decade arc play out. With Mach as the origins, everything other than tasks (processes) schedule and virtual mem was out of kernel and done over Mach port comms. Then xnu via next step and later OS X linked much more in kernel and exposed specific data types using com+ in iokit. And now more and more is moving back out of the kernel. io_urging networking on Linux is another similar move out to use space
mathiasgredal 3y ago
What prevents Apple from just integrating MacFUSE(or a reimplementation) into the their kernel, and then shipping it with the next release?
- yjftsjthsd-h 3y ago
  I'd be shocked if there was any technical reason they couldn't; if they haven't, they either don't care or actively don't want to for some reason. (But yes, I think they could and a lot of people would be very happy if they did)
- pjmlp 3y ago
  Basically doesn't fit their roadmap.
- dagmx 3y ago
  Isn’t Fuse itself LGPL? Thats perhaps one reason since copyleft licenses aren’t favourable from their view. I would really love any equivalent API though as dealing with Perforce is a pain in the butt sometimes, and what Microsoft have done with the Prrforce Virtual File system is amazing.
  - arthur2e5 3y ago
    Macfuse itself has been closed source for a long time. Whether their EULA is compatible with the LGPL though, I don’t know. (Also, the old question: are APIs copyrightable?)
    - dagmx 3y ago
      But do they bundle libfuse as a dylib? If they do, they’re probably in the right. And API copyright aside, how would one prove it’s only API compatible and not using the implementation as well without also open sourcing their implementation? It would almost be better to be similar but not the same. Then everyone else can just do subtle ifdef changes to their fuse code.
- MyelinatedT 3y ago
mynegation 3y ago
I upgraded my MBP after keeping MBP 2013 for 10 years and had to go through the shamanic dance of booting Sonoma into the safe mode, changing preferences and rebooting again to get macfuse working and I would still prefer it to dealing with NFS.
- mbirth 3y ago
  Fuse-T works as a drop-in replacement for the traditional FUSE. And pretty good I must say. You don’t notice the NFS part, it’s all handled by fuse-t itself.
  - dmitrygr 3y ago
    No it doesn’t. Go try to get VeraCrypt to use it. It requires code changes and recompilation.
    - mbirth 3y ago
      For Python programs, a mere FUSE_LIBRARY_PATH=/usr/local/lib/libfuse-t.dylib is sufficient. For other binaries, overwriting the libfuse*.dylib with the libfuse-t.dylib should work in the same way.
      - dmitrygr 3y ago
        VeraCrypt will not even install. Try
Dwedit 3y ago
While using network communications is a great workaround for platforms that don't natively support user-mode filesystems, you end up with a bottleneck of data being copied a bunch of times, plus the latency overhead of waking up a thread to accept a new network connection.
devaiops9001 3y ago
After Mac OS X.9 I saw which way the wind was blowing and permanently abandoned Mac OS X (now "macOS"). But I do recognize this kext-less FUSE-T thing here as a neat work of art.
- deleted 3y ago
  [deleted]
JoshTriplett 3y ago
What's the most convenient/solid way to do network disks on macOS? Something like NVMeoTCP, NVMeoF, NBD, anything of that general family.
dmitrygr 3y ago
Sadly it is NOT a drop in replacement at all and requires recompilation of every app the uses MacFUSE. Thus, it is useful for precisely 0% of fuse-using macOS apps out there. There is a bug in veracrypt GitHub to make fuse-t an option. It has had no action since April.
OnlyMortal 3y ago
As a recent contributor to this, it’s a go based server that performs IPC to a FUSE based client.
dTal 3y ago
> With each version of macOS it's getting harder and harder to load kernel extensions. Apple strongly discourages it thus making software distributions that use 'macfuse' difficult to install. omg that's terrible, Apple is so evil > Additionally, the 'macfuse' kext is unstable, may cause frequent system crashes and kernel lock-ups. oh

213 points by nimish 3y ago

PlutoIsAPlanet 3y ago

Why is there a GitHub and no source code?

fathyb 3y ago
Does not answer your question directly, but related: https://github.com/macos-fuse-t/fuse-t/issues/1#issuecomment-1420347389 https://github.com/macos-fuse-t/fuse-t/issues/1#issuecomment... > The project consists of two components: libfuse and fuse-t server. libfuse is LGPL licensed and can be downloaded from here: macos-fuse-t/libfuse [1]. You can modify and build it as you wish, the build instructions are provided in the README file. The fuse-t server on the other hand is a proprietary component, it's written in go and doesn't link to or includes anything GPL related, all respective copyright owners are mentioned in License.txt file [...] [1] https://github.com/macos-fuse-t/libfuse https://github.com/macos-fuse-t/libfuse
- kelnos 3y ago
  Weird that early in the issue comments the author claims they're going to release source for fuse-t, but then later in the comments changes course and says it's proprietary. Sounds like they originally wanted to release it as open source, but under a restrictive non-commercial license (which is fine, I guess), but then has gone back on that promise. I'm not gonna be one of those "proprietary software is immoral" people, but it just rubs me the wrong way to see someone take a concept/protocol that was originally developed in the open and released as open source (the Linux version of FUSE itself), and then build something proprietary.
  - PlutoIsAPlanet 3y ago
    Especially something like FUSE where it’s potentially the middle man of personal data. If there’s concern about other companies profiteering, release it under a license that prevents such and those companies can pay to license under something else. This approach could even be useful on Linux where fuse isn’t viable (e.g inside containers)
    - flakes 3y ago
      > This approach could even be useful on Linux where fuse isn’t viable (e.g inside containers) By viable do you mean secure? You can definitely use FUSE within containers, but you do have to cap-add SYS_ADMIN.
      - Conan_Kudo 3y ago
        Unprivileged FUSE has been a thing for a while now: https://zameermanji.com/blog/2022/8/5/using-fuse-without-root-on-linux/ https://zameermanji.com/blog/2022/8/5/using-fuse-without-roo...
  - deleted 3y ago
    [deleted]
- soraminazuki 3y ago
  I respect the author's choice to use a proprietary license, but I wish they'd been honest about it. I've been tracking that GitHub issue when FUSE-T came out. Initially, the author promised to open source. But then there was a long silence, after which the issue was closed as "completed" without any explanation. It's unfortunate because proprietary software requires more trust for users. The lack of communication demonstrated here is concerning.
deleted 3y ago
[deleted]
rgovostes 3y ago
There are two FUSE implementations for macOS and neither is open source, unfortunately. One reason: it’s a critical component of several profitable, commercial products, but the authors of then-open source FUSE implementations found that none of those companies were willing to financially support their work. Those authors also haven’t seemed interested in crowdfunding when it has been proposed.
- xaerise 3y ago
  They actually tried with crowdfunding, but it didn't go well. Mostly because German laws and other things.
- krackers 3y ago
  See https://www.theregister.com/2019/12/16/fuse_macos_closed_source/ https://www.theregister.com/2019/12/16/fuse_macos_closed_sou... for more info. I wonder why a dual-licensing approach was not pursued though, e.g. some viral license (AGPL?) for the open-source part. This could have the same benefit of getting companies to negotiate an explicit (paid) license agreement while still making source available.
blackpanda467 3y ago
From the author: right now fuse-t cannot be made open sourced because it won't play nice with existing contracts. You can try my other project which is open source and can be an alternative to fuse: https://github.com/macos-fuse-t/go-smb2 https://github.com/macos-fuse-t/go-smb2

nextfx 3y ago

I've been using mksquashfs to make full-system backups lately, but had to resort to using unsquashfs for recovering files. This combined with squashfuse might come in handy.

EdSchouten 3y ago

Previously discussed here: https://news.ycombinator.com/item?id=32726166 https://news.ycombinator.com/item?id=32726166

Reason077 3y ago

It’s surprising that given Apple’s war on kexts, they still haven’t come out with a proper API for implementing local user-space filesystems. It seems like this exists for remote filesystems (eg: Google Drive, Dropbox), but not for filesystems on local storage devices? This sounds like a nice workaround, though!

rgovostes 3y ago
Yes, an Apple-supported API is likely coming. They’ve been gradually providing userspace alternatives for kernel extensions. Their API isn’t likely to be FUSE but hopefully the community will develop a translation layer. I wonder if one of the holdups is that they don’t want a profusion of filesystems and would prefer everyone use ExFAT or APFS. Data loss/corruption ultimately results in more support calls and headaches for them, after all.
- tambourine_man 3y ago
  It’s been coming for so long that I lost hope.
- macshome 3y ago
  Apple started replacing their own file system (and networking) kexts with user-mode file systems in macOS 13. Right now its locked up behind some private entitlements though. Hopefully they open it up more in the future. For a quick overview check out a blog post on threedots. https://threedots.ovh/blog/2022/06/quick-look-at-user-mode-file-systems-on-macos-ventura/ https://threedots.ovh/blog/2022/06/quick-look-at-user-mode-f...
  - strangemonad 3y ago
    It’s certainly been interesting watching the multi-decade arc play out. With Mach as the origins, everything other than tasks (processes) schedule and virtual mem was out of kernel and done over Mach port comms. Then xnu via next step and later OS X linked much more in kernel and exposed specific data types using com+ in iokit. And now more and more is moving back out of the kernel. io_urging networking on Linux is another similar move out to use space

mathiasgredal 3y ago

What prevents Apple from just integrating MacFUSE(or a reimplementation) into the their kernel, and then shipping it with the next release?

yjftsjthsd-h 3y ago
I'd be shocked if there was any technical reason they couldn't; if they haven't, they either don't care or actively don't want to for some reason. (But yes, I think they could and a lot of people would be very happy if they did)
pjmlp 3y ago
Basically doesn't fit their roadmap.
dagmx 3y ago
Isn’t Fuse itself LGPL? Thats perhaps one reason since copyleft licenses aren’t favourable from their view. I would really love any equivalent API though as dealing with Perforce is a pain in the butt sometimes, and what Microsoft have done with the Prrforce Virtual File system is amazing.
- arthur2e5 3y ago
  Macfuse itself has been closed source for a long time. Whether their EULA is compatible with the LGPL though, I don’t know. (Also, the old question: are APIs copyrightable?)
  - dagmx 3y ago
    But do they bundle libfuse as a dylib? If they do, they’re probably in the right. And API copyright aside, how would one prove it’s only API compatible and not using the implementation as well without also open sourcing their implementation? It would almost be better to be similar but not the same. Then everyone else can just do subtle ifdef changes to their fuse code.
MyelinatedT 3y ago

mynegation 3y ago

I upgraded my MBP after keeping MBP 2013 for 10 years and had to go through the shamanic dance of booting Sonoma into the safe mode, changing preferences and rebooting again to get macfuse working and I would still prefer it to dealing with NFS.

mbirth 3y ago
Fuse-T works as a drop-in replacement for the traditional FUSE. And pretty good I must say. You don’t notice the NFS part, it’s all handled by fuse-t itself.
- dmitrygr 3y ago
  No it doesn’t. Go try to get VeraCrypt to use it. It requires code changes and recompilation.
  - mbirth 3y ago
    For Python programs, a mere FUSE_LIBRARY_PATH=/usr/local/lib/libfuse-t.dylib is sufficient. For other binaries, overwriting the libfuse*.dylib with the libfuse-t.dylib should work in the same way.
    - dmitrygr 3y ago
      VeraCrypt will not even install. Try

Dwedit 3y ago

While using network communications is a great workaround for platforms that don't natively support user-mode filesystems, you end up with a bottleneck of data being copied a bunch of times, plus the latency overhead of waking up a thread to accept a new network connection.

devaiops9001 3y ago

After Mac OS X.9 I saw which way the wind was blowing and permanently abandoned Mac OS X (now "macOS"). But I do recognize this kext-less FUSE-T thing here as a neat work of art.

deleted 3y ago
[deleted]

JoshTriplett 3y ago

What's the most convenient/solid way to do network disks on macOS? Something like NVMeoTCP, NVMeoF, NBD, anything of that general family.

dmitrygr 3y ago

Sadly it is NOT a drop in replacement at all and requires recompilation of every app the uses MacFUSE. Thus, it is useful for precisely 0% of fuse-using macOS apps out there. There is a bug in veracrypt GitHub to make fuse-t an option. It has had no action since April.

OnlyMortal 3y ago

As a recent contributor to this, it’s a go based server that performs IPC to a FUSE based client.

dTal 3y ago

> With each version of macOS it's getting harder and harder to load kernel extensions. Apple strongly discourages it thus making software distributions that use 'macfuse' difficult to install. omg that's terrible, Apple is so evil > Additionally, the 'macfuse' kext is unstable, may cause frequent system crashes and kernel lock-ups. oh