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..