Network File System
Network File System (NFS) is a distributed file system protocol originally developed by Sun Microsystems in 1984,allowing a user on a client computer to access files over a network in a manner similar to how local storage is accessed. NFS, like many other protocols, builds on the Open Network Computing Remote Procedure Call (ONC RPC) system. The Network File System is an open standard defined in RFCs, allowing anyone to implement the protocol.
Versions and variations
Original NFS version
The implementation details are defined in RFC 1094. Sun used version 1 only for in-house experimental purposes. When the development team added substantial changes to NFS version 1 and released it outside of Sun, they decided to release the new version as v2, so that version inter operation and RPC version fallback could be tested.
General NFS Rules
There are some general rules that need to be followed when configuring NFS.
You can only export directories beneath the “/” directory.
You cannot export a subdirectory of a directory that has already been exported. The exception being when the subdirectory is on a different physical device. Likewise, you cannot export the parent of a subdirectory unless it is on a separate device too.
You can only export local file systems.
Version 2 of the protocol (defined in RFC 1094, March 1989) originally operated entirely over UDP. Its designers meant to keep the protocol stateless, with locking (for example) implemented outside of the core protocol. People involved in the creation of NFS version 2 include Rusty Sandberg, Bob Lyon, Bill Joy, and Steve Kleiman. NFSv2 only allowed the first 2 GB of a file to be read.
Version 3 (RFC 1813, June 1995) added:
support for 64-bit file sizes and offsets, to handle files larger than 2 gigabytes (GB);
support for a synchronous 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 file handles and attributes along with file names when scanning a directory;
Assorted other improvements.
At the time of introduction of Version 3, vendor support for TCP as a transport-layer protocol began increasing. While several vendors had already added support for NFS Version 2 with TCP as a transport, Sun Microsystems added support for TCP as a transport for NFS at the same time it added support for Version 3.
Version4 became the first version developed with the Internet Engineering Task Force (IETF) after Sun Microsystems handed over the development of the NFS protocols. NFS version 4.1 aims to provide protocol support to take advantage of clustered server deployments including the ability to provide scalable parallel access to files distributed among multiple servers in RFC 3530, influenced by AFS and CIFS, includes performance improvements, mandates strong security, and introduces a stateful.
Why Upgrade to NFSv4
There are numerous advantages to using NFSv4 over previous versions to name but a few they are:
Locking and mounting is now handled directly by the NFS protocol rather than by seperate deamons.
The protocol is now stateful so crashes a rehandled more cleanly.
There is far more caching so NFS is now much faster.
Fully standardized protocol over seen by IETF.
Much more secure-introduction of RPCSEC_GSS.
Important NFS daemons
The following are the Daemons that should be running on NFSv4 Server:
A NFSv4 client communicates with corresponding NFSv4 Server via Remote Procedure Calls (RPS’s). The client sends a request and gets a reply from the server. A NFSv4 server can only provide/export a single, hierarchical file system tree. If a server has to share more than one logical file system tree, the single trees are integrated in a new virtual root directory. This construction, called pseudo file system, is the one which is provided/exported to clients.
Configure nfs server
In this example we will configure nfs server and will mount shared directory from client side. For this example we are using two systems one linux server and one linux clients.
Basic network configurations Example and Implementations ip configurations hosts files portmap xinetd services
A linux server with ip address 188.8.131.52 and hostname Server
A linux client with ip address 184.108.40.206 and hostname Client1
Updated/etc/hosts file on both linux system
Running portmap and xinetd services
Firewall should be off on server