[willscott]

Wasn't expecting to see this here!

This turned out easier than i was expecting it to be. It's nice to be able to mount a VFS without needing privileges on the server side. The main intention for this code is to eventually use it to replace fuse on mac, since nfs is a valid mount time for mac clients to consume.

[_prometheus]

This is great! SOOO useful to be able to do mounts w/o fuse, w/o kernel extension, w/o root. This is a HUGE UX thing, specially for macs.

Fuse is a really great idea & project, but sadly today impls require a lot of install steps in some platforms, and some have painful bugs/UX. Amazing if we can mount VFSes from Go without those hurdles.

[jchw]

Just to lay them out, some notable other options:

- Under Linux and FreeBSD, bazil fuse offers a nice low dependency path to supporting FUSE. It is all pure Go code.

- Under Windows, you can use WinFSP, which is a rock solid usermode filesystem driver with FUSE support. Despite its name, you can use this with Cgofuse to get FUSE on Windows without CGo.

Combining the two above gets you pretty far already (though if you want to actually avoid a CGo dependency you do need to explicitly disable it.)

I think the next level would be to have a general filesystem interface (there are several options in the ecosystem already) that can be used as a common ground between different usermode filesystem and network filesystem server implementations. Then ideally, a magic Go library can exist that gives you the best possible setup with switchable backends depending on the platform and build configuration.

Right now Go itself is possibly standardizing a read-only filesystem interface, an extension of this with write support might serve as a decent jumping point for getting toward an idealized pluggable filesystem library.

[yencabulator]

> I think the next level would be to have a general filesystem interface

That's starting to take shape: https://old.reddit.com/r/golang/comments/hv976o/qa_iofs_draf...

It won't be enough for the likes of FUSE, though. Some extensions might be enough to bridge that gap, it's too early to tell. FUSE is pretty particular about things like rename(2) preserving node identity.

[adinisom]

Another option:

Fairmount, an app DVD ripping on MacOS, uses WebDAV: https://github.com/BoxOfSnoo/Fairmount

[azinman2]

The fuse replacement is super interesting. So you’d basically have a user space utility that provides NFS<->fs bridging? Would you support the existing fuse API? What does NFS not allow that Fuse would, if anything?

Thanks for your contribution!

[willscott]

one of the major attractions of the fuse abstraction layer is that once you have fuse you can interact with more exotic file system types without having to deal with new kernel drivers each time.

Instead though, you can translate the exotic file system types to nfs, and use the existing kernel drivers that already exist for mounting an NFS mount.

[azinman2]

Would you support the existing fuse API? What does NFS not allow that Fuse would, if anything?

[est31]

Very cool! With "only" 3.2k lines of code for a NFS implementation I was indeed surprised that it was so easy. As for the privileges, how do you deal with the issue of port 111 being a privileged port?

[willscott]

It defaults to a high port. when mounting, you can pass options to set both NFS and MOUNT port and skip the portmapper.

[Galanwe]

> With "only" 3.2k lines of code for a NFS implementation I was indeed surprised that it was so easy.

Not criticizing the projet here, which is very cool. But don't get too hasty.

This is an _untested_ (per the docs), _unoptimized_, _read only_, _server only_, NFS v3 only, implementation.

[willscott]

it is read-write and shares types with the existing https://github.com/vmware/go-nfs-client for the client side implementation.

optimization and testing are ongoing :)

[jdub]

That's awesome – better update the README. :-)