6 ms·

I hope this doesn't displace Samba. NFS is a pain to use specifically because it's compiled into the kernel, and reads config files that have to live in /etc.

I hope this doesn't displace Samba. NFS is a pain to use specifically because it's compiled into the kernel, and reads config files that have to live in /etc. That makes it very hard to run or control as an unprivileged user. It also means that a file in /etc needs to be writeable. That makes NFS servers very hard to start, stop, and configure as part of a test bench. Kernel NFS also essentially displaced all userspace NFS servers (that I'm aware of anyways). At least, I've never been able to get a userspace one to work. I like Samba specifically because it's easy to configure, start, and stop from userspace. I don't want to see it get obsoleted.

Spivak 5y ago
> That makes it very hard to run as an unprivileged user? Huh? You can't run it as an unprivileged user at all. You want NFS-Ganesha if you want a userspace NFS server. Development it active and it's the only OSS NFS implementation I've seen that can handle an Active-Active HA configuration with Kerberos.
- prpl 5y ago
  In theory you need CAP_SETUID and maybe a few other to run it with less privileges. That can also be done theoretically with another user than root if you can hack things appropriately. In practice the hacking part is hard.
KitDuncan 5y ago
what about ganesha?
slownews45 5y ago
Samba is GPLv3, this is GPLv2 so they may be serving different communities ultimately. At least where I am GPLv2 - folks are MUCH more comfortable with that. Not sure but one area would be embedded devices (think security camera with a SD card in it). This would really let them serve a file share for video browsing, without having to give out their keys to the devices themselves (GPLv3 is both viral and has all sorts of what are called anti-tivoisation provisions that means developers are more limited in what they can do with the code in terms of use).
- yjftsjthsd-h 5y ago
  > anti-tivoisation provisions that means developers are more limited in what they can do with the code in terms of use Developers are only "limited" from locking users out of their own device
  - slownews45 5y ago
    We need to be CRYSTAL clear here. Developers are the ones contributing to these open source projects. Developers are the ones picking which licenses to use (and which software to develop with). Developers or their employers etc are setting the terms of sale with their user or regulatory agencies around product sales (which duty cycle limits, thermal cutoffs, RPM governors on engines, speed limits on vehicles like scooters and the list goes on and on). Historically, open source didn't not have a restriction on use. In other words, even if Linus doesn't like military stuff, some govt contractor could use linux in a submarine. Similarly, if Linus things Trump was an idiot, he couldn't block trump from using Linux. Similarly, if a developer needed to set power emission limits on a device they shipped, or a governor or anything else they could lock the device so that user couldn't change power limits or duty cycles or other parameters. This is in many cases critical to these product sales. Especially in industrial applications (but even automotive), the mfg and their developers often DOES NOT want users messing with the duty cycles, temp limit cutouts or other issues. GPLv3 changes the calculation hugely here. Mfg's used to be basically free to use the software how they wanted, they just had to give back to other developers. Under GPLv3 all this changes. GPLv3 requires folks to unlock devices, give up encryption keys. Because it is developers deciding on the licenses being used, GPLv3 is MUCH less acceptable to a lot of developers who don't want to be blocked from using projects they contribute to in the ways they or their employer wants. So this is a very real limit on developers freedoms here. We keep on hearing from GPLv3 folks how much better the GPLv3 is - I and others disagree -it's a fundamental change to the GPL historic intent and function.
    - sa1 5y ago
      The intent of FSF was always to protect user freedoms - where users can also be developers - and not to protect developer freedoms - where developers are a separate class from users.
m45t3r 5y ago
> I hope this doesn't displace Samba. It doesn't seem to be the objective. For one, this is a very old version of SMB protocol (v3, while SMB doesn't have big releases anymore the current one is v4). Also, Samba have the user space tooling that this project explicitly doesn't want to reimplement. And it seems that both implementations are compatible with each other. It does seem to me that the main objective here is to have a very efficient implementation of SMB for embedded devices.
- ArchOversight 5y ago
  Samba versions don't correlate with the protocol versions. The latest SMB protocol versions is 3.1.1.
the_angry_angel 5y ago
If it helps, as far as I'm aware Ganesha [1] is still widely used, supported, in some cases faster than the kernel implementation, and can be pointed at an arbitrary config file. [1] https://github.com/nfs-ganesha/nfs-ganesha https://github.com/nfs-ganesha/nfs-ganesha
dheera 5y ago
Isn't NFS also dead? It basically believes you are root if you say you are. And NFSv4 apparently requires Kerberos? WTF? Was it designed only for MIT use? Why can't they support simple things like SSH keys?
- krylon 5y ago
  The default for NFSv3 is to map client-side root to server-side nobody, unless you explicitly tell it not to. (Which I had to do once to run a diskless workstation with an NFS root filesystem.)
- selfhoster11 5y ago
  NFS is what you use if you want seamless file shares on Linux. Pretty much every other option has been junky or lost me data.
  - adrian_b 5y ago
    It depends on what kind of data is important for you. In my Linux file systems (and also in my FreeBSD file systems), extended attributes are very important for me. The older NFS versions (v2, v3 and early v4, before Linux 5.9) do not support extended attributes, so I was always forced to use Samba shares, which for me worked OK, including with the sharing between Linux and FreeBSD.
    - selfhoster11 5y ago
      I'm just happy with the files themselves being intact, but IME even that was difficult to achieve with non-NFS solutions. SMB was notoriously difficult to set up, and things like WebDAV or SFTP would have severe write loss problems when I tried to use them like an interactive local filesystem. NFS is rock stable.
- chasil 5y ago
  NFSv4 uses idmapd with a defined "domain," unlike direct uid/gid mapping of earlier versions. When the idmapd daemons on either side cannot agree on the domain, all users will be "squashed" to the default NFS user. Root is always squashed, unless nosquash is specified in /etc/exports (which goes for earlier protocol versions as well). NFSv4 [cleartext] does not require kerberos. Kerberos can be used to encrypt the data stream between client and server, but this can also be accomplished with stunnel over TLS (google "nfs encryption" for details).
pantalaimon 5y ago
gatling has basic Samba support and is really minimal. If you start it without arguments it will just serve the current directory

Spivak 5y ago

> That makes it very hard to run as an unprivileged user? Huh? You can't run it as an unprivileged user at all. You want NFS-Ganesha if you want a userspace NFS server. Development it active and it's the only OSS NFS implementation I've seen that can handle an Active-Active HA configuration with Kerberos.

prpl 5y ago
In theory you need CAP_SETUID and maybe a few other to run it with less privileges. That can also be done theoretically with another user than root if you can hack things appropriately. In practice the hacking part is hard.

KitDuncan 5y ago

what about ganesha?

slownews45 5y ago

Samba is GPLv3, this is GPLv2 so they may be serving different communities ultimately. At least where I am GPLv2 - folks are MUCH more comfortable with that. Not sure but one area would be embedded devices (think security camera with a SD card in it). This would really let them serve a file share for video browsing, without having to give out their keys to the devices themselves (GPLv3 is both viral and has all sorts of what are called anti-tivoisation provisions that means developers are more limited in what they can do with the code in terms of use).

yjftsjthsd-h 5y ago
> anti-tivoisation provisions that means developers are more limited in what they can do with the code in terms of use Developers are only "limited" from locking users out of their own device
- slownews45 5y ago
  We need to be CRYSTAL clear here. Developers are the ones contributing to these open source projects. Developers are the ones picking which licenses to use (and which software to develop with). Developers or their employers etc are setting the terms of sale with their user or regulatory agencies around product sales (which duty cycle limits, thermal cutoffs, RPM governors on engines, speed limits on vehicles like scooters and the list goes on and on). Historically, open source didn't not have a restriction on use. In other words, even if Linus doesn't like military stuff, some govt contractor could use linux in a submarine. Similarly, if Linus things Trump was an idiot, he couldn't block trump from using Linux. Similarly, if a developer needed to set power emission limits on a device they shipped, or a governor or anything else they could lock the device so that user couldn't change power limits or duty cycles or other parameters. This is in many cases critical to these product sales. Especially in industrial applications (but even automotive), the mfg and their developers often DOES NOT want users messing with the duty cycles, temp limit cutouts or other issues. GPLv3 changes the calculation hugely here. Mfg's used to be basically free to use the software how they wanted, they just had to give back to other developers. Under GPLv3 all this changes. GPLv3 requires folks to unlock devices, give up encryption keys. Because it is developers deciding on the licenses being used, GPLv3 is MUCH less acceptable to a lot of developers who don't want to be blocked from using projects they contribute to in the ways they or their employer wants. So this is a very real limit on developers freedoms here. We keep on hearing from GPLv3 folks how much better the GPLv3 is - I and others disagree -it's a fundamental change to the GPL historic intent and function.
  - sa1 5y ago
    The intent of FSF was always to protect user freedoms - where users can also be developers - and not to protect developer freedoms - where developers are a separate class from users.

m45t3r 5y ago

> I hope this doesn't displace Samba. It doesn't seem to be the objective. For one, this is a very old version of SMB protocol (v3, while SMB doesn't have big releases anymore the current one is v4). Also, Samba have the user space tooling that this project explicitly doesn't want to reimplement. And it seems that both implementations are compatible with each other. It does seem to me that the main objective here is to have a very efficient implementation of SMB for embedded devices.

ArchOversight 5y ago
Samba versions don't correlate with the protocol versions. The latest SMB protocol versions is 3.1.1.

the_angry_angel 5y ago

If it helps, as far as I'm aware Ganesha [1] is still widely used, supported, in some cases faster than the kernel implementation, and can be pointed at an arbitrary config file. [1] https://github.com/nfs-ganesha/nfs-ganesha https://github.com/nfs-ganesha/nfs-ganesha

dheera 5y ago

Isn't NFS also dead? It basically believes you are root if you say you are. And NFSv4 apparently requires Kerberos? WTF? Was it designed only for MIT use? Why can't they support simple things like SSH keys?

krylon 5y ago
The default for NFSv3 is to map client-side root to server-side nobody, unless you explicitly tell it not to. (Which I had to do once to run a diskless workstation with an NFS root filesystem.)
selfhoster11 5y ago
NFS is what you use if you want seamless file shares on Linux. Pretty much every other option has been junky or lost me data.
- adrian_b 5y ago
  It depends on what kind of data is important for you. In my Linux file systems (and also in my FreeBSD file systems), extended attributes are very important for me. The older NFS versions (v2, v3 and early v4, before Linux 5.9) do not support extended attributes, so I was always forced to use Samba shares, which for me worked OK, including with the sharing between Linux and FreeBSD.
  - selfhoster11 5y ago
    I'm just happy with the files themselves being intact, but IME even that was difficult to achieve with non-NFS solutions. SMB was notoriously difficult to set up, and things like WebDAV or SFTP would have severe write loss problems when I tried to use them like an interactive local filesystem. NFS is rock stable.
chasil 5y ago
NFSv4 uses idmapd with a defined "domain," unlike direct uid/gid mapping of earlier versions. When the idmapd daemons on either side cannot agree on the domain, all users will be "squashed" to the default NFS user. Root is always squashed, unless nosquash is specified in /etc/exports (which goes for earlier protocol versions as well). NFSv4 [cleartext] does not require kerberos. Kerberos can be used to encrypt the data stream between client and server, but this can also be accomplished with stunnel over TLS (google "nfs encryption" for details).

pantalaimon 5y ago

gatling has basic Samba support and is really minimal. If you start it without arguments it will just serve the current directory