Linux : NFS4 Configuration
1 . FileSystem Name Space 2. NFSv4 is a Stateful Protocol 3. Delegation 4. Security
File system name space
NFSv4 provides a different model file system name-space model than did previous versions. Servers, rather than exporting multiple file systems, export a single “pseudo file system,” formed from multiple actual file systems, and potentially customized for each client.
NFSv4 as a stateful protocol
Previous NFS protocols were stateless in the sense that the NFS server maintained no information or state about its clients.NFSv4, however, is stateful; the NFSv4 server maintains information about its clients, the files they hold open, and locks.Using stateful design enhance performance and scalability.
Clients may perform operations on files with minimal interaction with the server. NFSv4 introduces file delegation. An NFSv4 server can allow an NFSv4 client to access and modify a file in it’s own cache without sending any network requests to the server, until the server indicates via a callback that another client wishes to access a file. This reduces the amount of traffic between NFSv4 client and server considerably in cases where no other clients wish to access a set of files concurrently.
A strong security model is mandated, where client/server interactions are done using the GSS-API framework. Three security mechanisms are needed: Kerberos, LIPKEY, and SPKM-3. Which one is actually used is negotiated between client and server. Security principals are now given as strings (e.g., user@domain) rather than as user IDs as was done in the earlier versions. Authorization uses both standard UNIX-like permissions as well as Windows ACLs.
There are other new features in NFSv4 besides the above, please follow Reference links.
NFSv4 is supported on 2.6 kernel. Please install latest NFS package beforehand, to do NFSv4 configuration.
# cat /boot/config-2.6.9-42.EL|grep NFS
# rpm -qa|grep nfs-utils
nfs-utils-1.0.6-70.EL4(provides a daemon for the kernel NFS server and related tools)
nfs-utils-lib-1.0.6-3(Support libaries that are needed by the commands and daemons)
NFSv4 configuration is quite simple if Security(KRB5) is not required. (Another Note to be written to introduce NFSv4 with Kerberos5 authentication).
On server side:
1.Create /export directory and assign permissions.
A NFSv4 server can only provide/export a single, hierarchical file system tree.
# mkdir /export
# chmod a+rwxt /export
fsid=0 – only export one directory with the fsid=0 option. /export folder will be the root of the NFSv4 share.
Insecure – The insecure option in this entry also allows clients with NFS implementations that don’t use a reserved port for NFS.
The /export directory will then be seen as the root directory for the NFSv4 filesystem. With NFS v4 all of the exports are contained within this filesytem and must be subdirectories of this root directory. If these were other directories/partitions that needed to be exported, directories/partitions are required to bind to /export folder.
# /etc/init.d/nfs restart
rpc.idmapd — rpc.idmapd is the NFSv4 ID <-> name mapping daemon. It provides functionality to the NFSv4 kernel client and server, to which it communicates via upcalls, by translating user and group IDs to names, and vice versa. This daemon is also started when issuing “/etc/init.d/nfs start”.
on client side:
1.Start idmap daemon
2.Mount to server
mount the root of the NFSv4 server’s share (/export) as “/”.
# mount -t nfs4 yourserver:/ /mnt/nfs4/