A few things to add to ponder's otherwise excellent writeup:

  • Reliability
    NFS was designed to be stateless on the server side, so that clients would be nearly immune to server reboots. When I first started doing system administration, back when X11 required 10 hours to compile, I ran the compile on an NFS client (faster cpu than server) from the server's disk (faster and bigger disks than client), while reconfiguring the server. I rebooted the server a couple of times, and the compile did not get a single burp.

    So, in my view, NFS at best fails to fail and hangs the client while server is rebooting, and at worst gets an I/O error. If you didn't want your clients to hang when the server is unavailable, you should have mounted with the intr option, which lets the user SIGINT out of a NFS disk wait.

  • Security
    NFS was designed for unix to unix file sharing. Since the standard security model under unix is that root is (mostly) trusted, if you trust the client machine to mount your disk writable at all, you trust it to do the security too. No, NFS is not particularly appropriate for unix to Microsoft Windows filesharing, as the security models are different.
  • Concurrent update
    Concurrent update over NFS works about the same as concurrent update on a local unix disk -- i.e., unpredicatably when done to the same byte(s), but otherwise not a problem. The (not stateless) lockd and statd were added to assist with locking. Don't use flock--it is obsolete; use posix fcntl intead, which works fine over NFS.
  • File information
    File information under NFS is identical to file information on UFS, except that it is cached, and therefore possibly out of date.
  • Symbolic Links
    Symbolic links under NFS work exactly like they do on a normal filesystem. However, you must realize that the filesystem view over NFS may be different on different machines, as the filesystem could be mounted in a different place. Absolute links (starting with a "/") might not refer to the same file; you should use relative links (sometimes containing "../") if you want that; but be careful to not try to back up beyond the root of the export. This problem is not limited to NFS -- it also occurs if you move the filesystem's mount point, for instance, when in a miniroot or rescue disk environment.
This is not to say that NFS is flawless or that the above are not flaws; just that most of the "flaws" mentioned above are design criteria that were intended from the start. Some real flaws in NFS are:
  • Reliability
    A more serious reliability problem is the stale nfs filehandle which occurs when either the remote mount point is changed (and server rebooted) or when the file in question is deleted on the server -- but what did you expect in these cases anyway?
  • Security and statelessness
    NFS filehandles were originally based on the inode number. Unix file permissions are partly based on permissions of parent directories. Since the server is stateless, it doesn't know how the client opened the file or even if it still has it open, so all kinds of attacks can be done based on this. Workarounds include randomizing inode numbers on the parent filesystem, encrypting them, hashing them, or serializing the filehandles. Many of these solutions require the server to keep a mapping between the generated filehandle and the real filename. So much for statelessness. Despite the lack of statelessness, several schemes have been used to fix this and still keep the original design criteria of transparent server reboots..