5 ms·

Why is anyone using NFS?

by tbrock 6y ago

dboreham 6y ago
Really. I was about to comment "don't use NFS".
- geofft 6y ago
  Can you expand on that / why not? It's certainly possible to use NFS in places where other tools would work better, but if the thing you actually want is filesystem semantics from multiple clients, NFS is definitely one of your better options, as far as I know / in my experience.
  - tryauuum 6y ago
    The authorization scheme sucks.
    - Proven 6y ago
      As opposed to what?
    - geofft 6y ago
      Can you expand on that? Which authorization scheme are you thinking of? I've run global-scale NFS deployments with sec=sys before and I wouldn't say it sucked.
      - tryauuum 6y ago
        so say if you have an NFS share (server A) on a public IP-address, and NFS client (server B), that mounts an NFS share with that sec=sys option. Doesn't that mean that a rogue server C can connect to server A and impersonate any user?
        geofft 6y ago
        If you a) run NFS on a public IP address, b) use sec=sys, and c) permit connections from any IP, then yes. I think that can't be generalized to "The authorization scheme sucks" any more than if you run sshd on a public IP address and permit root logins with a password and pick a guessable password you can conclude that SSH's authorization scheme sucks. There's a number of stronger things you could do and they're perfectly normal.
        tryauuum 6y ago
        My main grudge is that NFS authorization is pointless without external crutches like IP-address whitelisting. Maybe it's because I'm used to password-based or key-based authentication methods and when I had met NFS I became scared of that host-based authentication. Of course I agree that IP whitelisting is a good practice that solves and prevents many issues.
- ThenAsNow 6y ago
  Serious question: what alternative would you recommend for access to NAS volumes from unix-like OSes (Linux, *BSD, MacOS) over LAN? Other than doing discrete file transfers over a channel like SSH, I'm at a loss for alternatives here to NFS and SMB. Given the two, if Windows is not involved on the LAN, I don't see why SMB makes any more sense than NFS. What other options am I missing?
hknapp 6y ago
What would you recommend?
- Polylactic_acid 6y ago
  Remote file systems are the worlds biggest pain in the ass. NFS seems like the easiest option but its ancient and insecure over the network. SFTP can be mounted and is also easy while being secure but is super CPU heavy on a single thread. All of the options I looked in to would fail when a program expects to be able to set permissions on things in the remote directory.
  - duckMuppet 6y ago
    NFS using Kerberos over the network is very secure while being fast. Complaining about nfs being insecure is to be ignorant regarding how NFS was originally intended to be implemented.
  - cat199 6y ago
    > NFS seems like the easiest option but its ancient and insecure over the network. r.e. old: nfsv4 is a different beast than nfs3; r.e. secure: these things don't hold true with krb5 auth.
    - pjc50 6y ago
      It's still not link layer encrypted, IIRC?
    - Polylactic_acid 6y ago
      Wikipedia says v4 came out in 2000 and a search for encryption on the page shows no results. sftp gives you really good key based authentication and encryption over the network. I wouldn't trust NFS for anything other than a highly secure internal network.
      - yrro 6y ago
        Mount with sec=krb5p and you get encryption (the p is short for Privacy).
Spivak 6y ago
Because there aren’t too many options for the use case of a shared filesystem that has many readers and writers, support for directory authentication and untrusted/less trusted clients. You pretty much have NFSv4 and SMB.
nexuist 6y ago
Does it matter? When I walk into a building I don't get to tell their IT guys what protocols to use and which to avoid. I don't get to tell them my own preferences and make them conform to them. I don't get to start a job and demand they change everything about everything on day 1. I adapt. And if they're using NFS, I want to make sure I can use NFS too. That's why fixing this bug was important.
fishywang 6y ago
I can't remember where but I once saw an open source project provide an NFS server package. Why? Because in the cases you want to use FUSE (for example, to implement a locally mounted Google Drive/Dropbox/etc.), you could also just spin up an NFS server instead. That actually makes a lot of sense to me, because that NFS server is much easier to for example containerize (you can't actually containerize a FUSE implementation and use it on your host. Or maybe you can but at least that would be a very involved process). I'm not sure of NFS is the best protocol for this use case (maybe something like CIFS is better), but the general direction is actually interesting.
m463 6y ago
I used to have a desktop machine with my source tree (and editor and tools) on it. I had to compile the code on a machine with a different os that I would frequently wipe and rev. So I just nfs mounted my source tree and compiled on the remote machine. I also tried cifs. compiles took like 3x the time.
sildur 6y ago
Why is anyone using linux? Or mac?
tannhaeuser 6y ago
Because it's one of the few options for a sufficiently standardized file serving protocol that can be implemented on small and big sites (with dedicated servers) and doesn't require proprietary APIs and/or auth? In other words, a professional choice that keeps open engineering options going forward.
jeroenhd 6y ago
The most common alternative, SMB, has horrible performance when it comes to small file operations compared to NFS. When files get larger the performance starts improving, but when you're doing many operations on small files there's a two to three times speed improvement if you switch to NFS. There's also the fact that macOS, Linux and Windows all have official support for NFS while SMB is achieved through analysing and reverse engineering Windows' protocols. There's no stability guarantee from Microsoft that SAMBA will keep working with the next update of Windows 10 while the NFS standard does maintain a minimum level of compatibility. I can't think of another way to share files over the network outside of NFS and SMB with cross-OS support. Perhaps you know a file sharing mechanism that has similar small file performance with similar OS support?
- zokier 6y ago
  > while SMB is achieved through analysing and reverse engineering Windows' protocols SMB2 protocol is documented here explicitly for interoperability purpose: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/5606ad47-5ee0-437a-817e-70c366052962 https://docs.microsoft.com/en-us/openspecs/windows_protocols... > There's no stability guarantee from Microsoft that SAMBA will keep working with the next update of Windows 10 while the NFS standard does maintain a minimum level of compatibility. I don't think there is any difference between SMB and NFS in this regard. There is no guarantee that next version of Windows will work with any NFS implementation either
st_goliath 6y ago
> Why is anyone using NFS? I use it a lot because the Linux kernel can mount it as rootfs during boot with little more than a few boot commend line flags. This IMO comes in very handy when working on embedded systems (at least when they have Ethernet and a sane boot loader). My development setup looks pretty much like this: My workstation is connected to the board and has DHCP, DNS, TFTP & NFS servers running on that port. Outbound traffic from the board is routed across the workstation and possibly passed through tcpdump or Wireshark. The boot loader on the board would get an IP from my box, then load the kernel & device tree from the TFTP server. The kernel would then do the DHCP dance again and mount the NFS rootfs from my box. I can simply recompile the kernel, power cycle the board and have it boot into the new one with all the new/changed modules available in the rootfs; or recompile some user space software I'm working on, install it into the rootfs and have it available on the board immediately. The only other options I can think of would be 9pfs and SMB. Support for SMB as rootfs was only quite recently and 9pfs would require some initrd trickery.
peterwwillis 6y ago
You were unfairly downvoted. This is an important question. Sometimes NFS is your only option. When you have legacy applications which nobody is going to rewrite, and you need to scale some operations on a set of files over many nodes, NFS works. Its failure nodes are well documented, so you can plan for and work around them. It's also supported by most vendors as the default networked filesystem. Whether you're using a desktop PC, a million dollar NAS, or cloud storage, it supports NFS. It's also acceptable when time is of the essence and you just need to get something working now and don't have time to build something better. I rather like "good enough solutions" as a way to get teams "shipping", with an agreed-upon plan to replace it later. But as someone who's used it for nearly 20 years, internally I start screaming and throwing things whenever someone suggests using it. Externally I propose redesigning for a more efficient solution :)

Why is anyone using NFS?

by tbrock 6y ago

Why is anyone using NFS?

dboreham 6y ago

Really. I was about to comment "don't use NFS".

geofft 6y ago
Can you expand on that / why not? It's certainly possible to use NFS in places where other tools would work better, but if the thing you actually want is filesystem semantics from multiple clients, NFS is definitely one of your better options, as far as I know / in my experience.
- tryauuum 6y ago
  The authorization scheme sucks.
  - Proven 6y ago
    As opposed to what?
  - geofft 6y ago
    Can you expand on that? Which authorization scheme are you thinking of? I've run global-scale NFS deployments with sec=sys before and I wouldn't say it sucked.
    - tryauuum 6y ago
      so say if you have an NFS share (server A) on a public IP-address, and NFS client (server B), that mounts an NFS share with that sec=sys option. Doesn't that mean that a rogue server C can connect to server A and impersonate any user?
      - geofft 6y ago
        If you a) run NFS on a public IP address, b) use sec=sys, and c) permit connections from any IP, then yes. I think that can't be generalized to "The authorization scheme sucks" any more than if you run sshd on a public IP address and permit root logins with a password and pick a guessable password you can conclude that SSH's authorization scheme sucks. There's a number of stronger things you could do and they're perfectly normal.
        tryauuum 6y ago
        My main grudge is that NFS authorization is pointless without external crutches like IP-address whitelisting. Maybe it's because I'm used to password-based or key-based authentication methods and when I had met NFS I became scared of that host-based authentication. Of course I agree that IP whitelisting is a good practice that solves and prevents many issues.
ThenAsNow 6y ago
Serious question: what alternative would you recommend for access to NAS volumes from unix-like OSes (Linux, *BSD, MacOS) over LAN? Other than doing discrete file transfers over a channel like SSH, I'm at a loss for alternatives here to NFS and SMB. Given the two, if Windows is not involved on the LAN, I don't see why SMB makes any more sense than NFS. What other options am I missing?

hknapp 6y ago

What would you recommend?

Polylactic_acid 6y ago
Remote file systems are the worlds biggest pain in the ass. NFS seems like the easiest option but its ancient and insecure over the network. SFTP can be mounted and is also easy while being secure but is super CPU heavy on a single thread. All of the options I looked in to would fail when a program expects to be able to set permissions on things in the remote directory.
- duckMuppet 6y ago
  NFS using Kerberos over the network is very secure while being fast. Complaining about nfs being insecure is to be ignorant regarding how NFS was originally intended to be implemented.
- cat199 6y ago
  > NFS seems like the easiest option but its ancient and insecure over the network. r.e. old: nfsv4 is a different beast than nfs3; r.e. secure: these things don't hold true with krb5 auth.
  - pjc50 6y ago
    It's still not link layer encrypted, IIRC?
  - Polylactic_acid 6y ago
    Wikipedia says v4 came out in 2000 and a search for encryption on the page shows no results. sftp gives you really good key based authentication and encryption over the network. I wouldn't trust NFS for anything other than a highly secure internal network.
    - yrro 6y ago
      Mount with sec=krb5p and you get encryption (the p is short for Privacy).

Spivak 6y ago

Because there aren’t too many options for the use case of a shared filesystem that has many readers and writers, support for directory authentication and untrusted/less trusted clients. You pretty much have NFSv4 and SMB.

nexuist 6y ago

Does it matter? When I walk into a building I don't get to tell their IT guys what protocols to use and which to avoid. I don't get to tell them my own preferences and make them conform to them. I don't get to start a job and demand they change everything about everything on day 1. I adapt. And if they're using NFS, I want to make sure I can use NFS too. That's why fixing this bug was important.

fishywang 6y ago

I can't remember where but I once saw an open source project provide an NFS server package. Why? Because in the cases you want to use FUSE (for example, to implement a locally mounted Google Drive/Dropbox/etc.), you could also just spin up an NFS server instead. That actually makes a lot of sense to me, because that NFS server is much easier to for example containerize (you can't actually containerize a FUSE implementation and use it on your host. Or maybe you can but at least that would be a very involved process). I'm not sure of NFS is the best protocol for this use case (maybe something like CIFS is better), but the general direction is actually interesting.

m463 6y ago

I used to have a desktop machine with my source tree (and editor and tools) on it. I had to compile the code on a machine with a different os that I would frequently wipe and rev. So I just nfs mounted my source tree and compiled on the remote machine. I also tried cifs. compiles took like 3x the time.

sildur 6y ago

Why is anyone using linux? Or mac?

tannhaeuser 6y ago

Because it's one of the few options for a sufficiently standardized file serving protocol that can be implemented on small and big sites (with dedicated servers) and doesn't require proprietary APIs and/or auth? In other words, a professional choice that keeps open engineering options going forward.

jeroenhd 6y ago

The most common alternative, SMB, has horrible performance when it comes to small file operations compared to NFS. When files get larger the performance starts improving, but when you're doing many operations on small files there's a two to three times speed improvement if you switch to NFS. There's also the fact that macOS, Linux and Windows all have official support for NFS while SMB is achieved through analysing and reverse engineering Windows' protocols. There's no stability guarantee from Microsoft that SAMBA will keep working with the next update of Windows 10 while the NFS standard does maintain a minimum level of compatibility. I can't think of another way to share files over the network outside of NFS and SMB with cross-OS support. Perhaps you know a file sharing mechanism that has similar small file performance with similar OS support?

zokier 6y ago
> while SMB is achieved through analysing and reverse engineering Windows' protocols SMB2 protocol is documented here explicitly for interoperability purpose: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/5606ad47-5ee0-437a-817e-70c366052962 https://docs.microsoft.com/en-us/openspecs/windows_protocols... > There's no stability guarantee from Microsoft that SAMBA will keep working with the next update of Windows 10 while the NFS standard does maintain a minimum level of compatibility. I don't think there is any difference between SMB and NFS in this regard. There is no guarantee that next version of Windows will work with any NFS implementation either

st_goliath 6y ago

> Why is anyone using NFS? I use it a lot because the Linux kernel can mount it as rootfs during boot with little more than a few boot commend line flags. This IMO comes in very handy when working on embedded systems (at least when they have Ethernet and a sane boot loader). My development setup looks pretty much like this: My workstation is connected to the board and has DHCP, DNS, TFTP & NFS servers running on that port. Outbound traffic from the board is routed across the workstation and possibly passed through tcpdump or Wireshark. The boot loader on the board would get an IP from my box, then load the kernel & device tree from the TFTP server. The kernel would then do the DHCP dance again and mount the NFS rootfs from my box. I can simply recompile the kernel, power cycle the board and have it boot into the new one with all the new/changed modules available in the rootfs; or recompile some user space software I'm working on, install it into the rootfs and have it available on the board immediately. The only other options I can think of would be 9pfs and SMB. Support for SMB as rootfs was only quite recently and 9pfs would require some initrd trickery.

peterwwillis 6y ago

You were unfairly downvoted. This is an important question. Sometimes NFS is your only option. When you have legacy applications which nobody is going to rewrite, and you need to scale some operations on a set of files over many nodes, NFS works. Its failure nodes are well documented, so you can plan for and work around them. It's also supported by most vendors as the default networked filesystem. Whether you're using a desktop PC, a million dollar NAS, or cloud storage, it supports NFS. It's also acceptable when time is of the essence and you just need to get something working now and don't have time to build something better. I rather like "good enough solutions" as a way to get teams "shipping", with an agreed-upon plan to replace it later. But as someone who's used it for nearly 20 years, internally I start screaming and throwing things whenever someone suggests using it. Externally I propose redesigning for a more efficient solution :)