Moving troubleshooting informations to NFSTroubleshooting page
|Deletions are marked like this.||Additions are marked like this.|
|Line 40:||Line 40:|
|== Error Messages ==
Error: Can't read superblock :: In order to mount a NFS network file system, it is necessary to run the portmapper on the client computer. An error may occur, if an attempt is made to mount a NFS network file system without the local portmapper running:
mount scooby:/foobar /nfs/scooby/foobar mount: scooby:/foobar Can't read superblock
mount.nfs: rpc.statd is not running but is required for remote locking :: This error occurs if the portmapper has not been started on the client machine.
The Network File System (NFS) was developed to allow machines to mount a disk partition on a remote machine as if it were on a local hard drive. This allows for fast, seamless sharing of files across a network.
It also gives the potential for unwanted people to access your hard drive over the network (and thereby possibly read your email and delete all your files as well as break into your system) if you set it up incorrectly. So please read the Security section of this document carefully if you intend to implement an NFS setup.
There are other systems that provide similar functionality to NFS. ?Samba (http://www.samba.org) provides file services to Windows clients. The Andrew File System from IBM (http://www.transarc.com/Product/EFS/AFS/index.html), recently open-sourced, provides a file sharing mechanism with some additional security and performance features. The Coda File System (http://www.coda.cs.cmu.edu/) is still in development as of this writing but is designed to work well with disconnected clients. Many of the features of the Andrew and Coda file systems are slated for inclusion in the next version of NFS (Version 4) (http://www.nfsv4.org). The advantage of NFS today is that it is mature, standard, well understood, and supported robustly across a variety of platforms.
Differences Between NFS Versions
Version 1 of the NFS protocol was used in-house experimental purposes at Sun Microsystems, and it was never released to the public.
Version 2 of the NFS protocol (defined in RFC 1094, March 1989) was developed as a joint venture between Sun Microsystems and IBM. It was designed as a stateless protocol and file locking was implemented outside of the core protocol. It originally operated entirely over UDP, but several vendors later added support for the use of TCP protocol.
Version 3 of the NFS protocol (defined in RFC 1813, June 1995) added:
- support for 64-bit file sizes and offsets, to handle files larger than 4 gigabytes (GB);
- support for asynchronous writes on the server, to improve write performance;
- additional file attributes in many replies, to avoid the need to re-fetch them;
- a READDIRPLUS operation, to get filehandles and attributes along with filenames when scanning a directory
- assorted other improvements.
Version 4 of the NFS protocol (defined in RFC 3010, December 2000, and later revised in RFC 3530, April 2003), was influenced by AFS and CIFS.
Version 4 of the NFS protocol added:
- stateful protocol support
- strong security
- A byte-range advisory Network Lock Manager (NLM) protocol
- The remote quota reporting (RQUOTAD) protocol