There are three major protocols in the filesystem sharing world. The most common is of course SMB, that which is used between most Windows systems. There is AFP, Apple’s equivalent, and finally there is my personal favorite, NFS. NFS is used primarily on UNIX-like systems, and fortunately Mac OS X falls into that category. For Mac users, AFP is usually the best choice just because of how well-integrated into the OS the protocol is. However, the demise of resource forks that corresponded with the advent of Mac OS X has made the advantages of AFP on the Mac platform a bit more muted.
NFS lacks some important things that AFP and SMB both provide. Security is probably the most immediately concerning issue, as there is no user authentication. While AFP and SMB both establish a TCP connection that first requires interactive authentication, NFS instead uses UDP, which as a stateless protocol doesn’t even have connections. Packets just get passed back and forth between the hosts, there’s no “connected” state between them. (Version 4 of the NFS standard does add TCP support, but that doesn’t help my soon-to-be-mentioned problem.) Authentication is host-based, meaning you tell the server what hosts can access what shares and with what privileges.
NFS’s use of stateless UDP can simultaneously be a virtue. In my home, all my work gets done on a MacBook Pro. I like to move my computer around, but also need high-speed access to large amounts of data. I keep a sizable iTunes library on a file server, along with my Parallels virtual machines and a variety of other large pieces of data. So, I have an 802.11n wireless network in addition to gigabit Ethernet. I keep the gigabit plugged in when I’m at my desk, then switch to wireless when I want to move elsewhere. However, this solution of dual interfaces introduces a new problem: when I switch interfaces, it kills most of my connections. This means that, if I’m using an AFP or SMB file server, I have to disconnect from it before I physically disconnect. This means quitting iTunes, stopping any video encodes I have going in the background, stopping all my virtual machines, etc. It’s not the end of the world, but it definitely disrupts my workflow. It would be really nice to avoid this hassle, and fortunately NFS provides a way to do just that.
To explain how, it helps to understand a few basic things about how traffic moves via TCP and UDP. When you establish a TCP connection, it is between two IP addresses. Each network interface has its own IP address, so TCP connections are bound to particular interfaces. For example, if I’m connected to both Ethernet and wireless, let’s say my Ethernet interface has the IP 10.0.0.10 and my wireless interface has 10.0.0.11. I of course have my interface priority set to prefer Ethernet over wireless, so if I start downloading something in my web browser (which uses TCP), it will start doing so over the Ethernet. Let’s pretend the server I’m downloading from is 10.0.0.20. So, the TCP connection is established between 10.0.0.10 and 10.0.0.20. Now, if part-way through this download I disconnect my Ethernet cable, the connection will be lost and the download will abort. The fact that I also have a simultaneous wireless connection doesn’t matter, since that interface has a different IP address and the connection does not involve that address. I could, however, attempt the download again immediately after its failure and it would work, this time with a connection established via the wireless interface.
Now, let’s start the example over, but instead of downloading a file via the web, let’s transfer a file via NFS. First, in order for this to work, the NFS server has to be configured to allow access from both the Ethernet and wireless interfaces’ IP addresses. Now, I mount the NFS server, start copying a large file, then disconnect the Ethernet. There is a brief pause as my OS adjusts to the change, then the progress resumes, albeit at a slower pace. Sure enough, the data is now moving over wireless. Why? Well, let’s look at what happens when you disconnect an interface. The computer notices that you’ve lost a link so it brings down the interface, killing all TCP connections (like your web download). Any NFS data en route from the server to that interface gets lost along the way, but your computer notices it hasn’t arrived and re-requests it. This request now goes out the wireless interface, and the NFS server sees the request coming from a different IP than before, but given that NFS is using stateless UDP it doesn’t really care so it sends the data along to the new IP. And lo, your NFS transfer continues as if nothing happened (albeit slower due to the wireless’s lower speed).
And that is why I love NFS.
Geek Foibles 