Objective:
To equip students with the practical knowledge to configure Linux boxes for file sharing using Network File System Protocol
Scope:
The student will be able to know the following at the end of this lab:
• Installing NFS
• Configuring NFS on The Client
• Configuring NFS on The Server
• Accessing NFS Server Directories from the Client
• Activating Modifications To The /etc/exports File
• Troubleshooting NFS Useful Concepts:
The virtual filesystem (VFS)
Mechanism used by NFS to transparently and automatically redirect all access to NFS-mounted files to the remote server.
Stateless Operation
Programs that read and write to files on a local filesystem rely on the operating system to track their access location within the file with a pointer. As NFS is a network-based file system, and networks can be unreliable, it was decided that the NFS client daemon would act as a failsafe intermediary between regu-lar programs running on the NFS client and the NFS server.
Normally, when a server fails, file accesses timeout and the file pointers are reset to zero.
With NFS, the NFS server doesn't maintain the file pointer information, the NFS client does. This means that if an NFS server suddenly fails, the NFS client can precisely restart the file access once more after patiently waiting until the server returns online.
Caching
NFS clients typically request more data than they need and cache the results in memory locally so that further sequential access of the data can be done locally versus over the network. This is also known as a read ahead cache. Data that's to be written to the NFS server is cached with the data being written to the server when the cache becomes full.
Caching therefore helps to reduce the amount of network traffic while simultaneously improving the speed of some types of data access.
The NFS server caches information too, such as the directory information for the most recently accessed files and a read ahead cache for recently read files.
NFS and Symbolic Links
You have to be careful with the use of symbolic links on exported NFS directories. If an absolute link points to a directory on the NFS server that hasn't been exported, then the NFS client won't be able to access it. Unlike absolute links, relative symbolic links are interpreted relative to the client's filesystem.
Consider an example where the /data1 directory on the server is mounted on the /data1 directory. If there is a link to the ../data2 directory on the NFS server and a directory corresponding to ../data2 doesn't exist on the NFS client, then an error will occur.
Also, mounting a filesystem on a symbolic link actually mounts the filesystem on the target of the sym-bolic link. You'll have to be careful not to obscure the contents of this original directory in the process.
Plan carefully before doing this.
NFS Background Mounting
NFS clients use the remote procedure call (RPC) suite of network application helper programs to mount remote filesystems. If the mount cannot occur during the default RPC timeout period, then the client re-tries the mount process until the NFS number of retires has been exceeded. The default is 10,000 minutes, which is approximately a week. The difficulty here is that if the NFS server is unavailable, the mount command will hang for a week until it returns online. It is possible to use a bg option spawn the retries off as a subprocess so that the main mount command can continue to process other requests.
Hard and Soft Mounts
The process of continuous retrying, whether in the background or foreground, is called a hard mount.
NFS attempts to guarantee the consistency of your data with these constant retries. With soft mounts, re-peated RPC failures cause the NFS operation to fail not hang and data consistency is therefore not guaran-teed. The advantage is that the operation completes quickly, whether it fails or not. The disadvantage is that the use of the soft option implies that you are using an unreliable NFS server; if this is the case it is best not to place critical data that needs to be updated regularly or executable programs in such a location.
Exercise-1:- This exercise illustrates NFS Installation
RedHat Linux installs nfs by default, and also by default nfs is activated when the system boots. You can determine whether you have nfs installed using the RPM command in conjunction with the grep com-mand to search for all installed nfs packages.
[root@bigboy tmp]# rpm -qa | grep nfs redhat-config-nfs-1.1.3-1
nfs-utils-1.0.1-3.9 [root@bigboy tmp]#
A blank list means that you'll have to install the required packages.
You also need to have the RPC rpcbind package installed, and the rpm command can tell you whether it's on your system already. When you use rpm in conjunction with grep, you can determine all the rpcbind applications installed:
[root@bigboy tmp]# rpm -q rpcbind rpcbind-4.0-57
[root@bigboy tmp]#
A blank list means that you'll have to install the required packages.
If nfs and rpcbind are not installed, they can be added fairly easily once you find the nfsutils and rpcbind RPMs. (Remember that RPM filenames usually start with the software's name and a version number, as in nfs-utils-1.1.3-1.i386.rpm.)
Using yum or apt-get is a suitable option.
Exercise-2:- This exercise illustrates Scenario Based NFS configuration
Scenario
A small office has an old Linux server that is running out of disk space. The office cannot tolerate any down time, even after hours, because the server is accessed by overseas programmers and clients at nights and local ones by day.
Budgets are tight and the company needs a quick solution until it can get a purchase order approved for a hardware upgrade. Another Linux server on the network has additional disk capacity in its /data partition and the office would like to expand into it as an interim expansion NFS server.
Configuring NFS on the Server
Both the NFS server and NFS client have to have parts of the NFS package installed and running. The server needs rpcbind, nfs, and nfslock operational, as well as a correctly configured /etc/exports file.
Here's how to do it.
The /etc/exports File
The /etc/exports file is the main NFS configuration file, and it consists of two columns.
The first column lists the directories you want to make available to the network. The second column has two parts. The first part lists the networks or DNS domains that can get access to the directory, and the second part lists NFS options in brackets.
For the scenario you need:
• Read-only access to the /data/files directory to all networks
• Read/write access to the /home directory from all servers on the 192.168.1.0 /24 network, which is all addresses from 192.168.1.0 to 192.168.1.255
• Read/write access to the /data/test directory from servers in the my-site.com DNS domain
• Read/write access to the /data/database directory from a single server 192.168.1.203.
In all cases, use the sync option to ensure that file data cached in memory is automatically written to the disk after the completion of any disk data copying operation.
#/etc/exports /data/files *(ro,sync)
/home 192.168.1.0/24(rw,sync) /data/test *.my-site.com(rw,sync)
/data/database 192.168.1.203/32(rw,sync)
After configuring your /etc/exports file, you need to activate the settings, but first make sure that NFS is running correctly.
Starting NFS on the Server
Configuring an NFS server is straightforward:
1) Use the chkconfig command to configure the required nfs and RPC rpcbind daemons to start at boot.
You also should activate NFS file locking to reduce the risk of corrupted data.
[root@bigboy tmp]# chkconfig --level 35 nfs on [root@bigboy tmp]# chkconfig --level 35 nfslock on [root@bigboy tmp]# chkconfig --level 35 rpcbind on
2) Use the init scripts in the /etc/init.d directory to start the nfs and RPC rpcbind daemons. The examples use the start option, but when needed, you can also stop and restart the processes with the stop and restart options.
[root@bigboy tmp]# service rpcbind start
[root@bigboy tmp]# service nfs start [root@bigboy tmp]# service nfslock start
3) Test whether NFS is running correctly with the rpcinfo command. You should get a listing of running RPC programs that must include mountd, portmapper, nfs, and nlockmgr.
[root@bigboy tmp]# rpcinfo -p localhost program vers proto port
100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100003 2 udp 2049 nfs
100003 3 udp 2049 nfs 100021 1 udp 1024 nlockmgr 100021 3 udp 1024 nlockmgr 100021 4 udp 1024 nlockmgr 100005 1 udp 1042 mountd 100005 1 tcp 2342 mountd 100005 2 udp 1042 mountd 100005 2 tcp 2342 mountd 100005 3 udp 1042 mountd 100005 3 tcp 2342 mountd [root@bigboy tmp]#
Configuring NFS on the Client
NFS configuration on the client requires you to start the NFS application; create a directory on which to mount the NFS server's directories that you exported via the /etc/exports file, and finally to mount the NFS server's directory on your local directory, or mount point. Here's how to do it all.
Starting NFS on the Client
Three more steps easily configure NFS on the client.
1) Use the chkconfig command to configure the required nfs and RPC rpcbind daemons to start at boot.
Activate nfslock to lock the files and reduce the risk of corrupted data.
[root@smallfry tmp]# chkconfig --level 35 netfs on [root@smallfry tmp]# chkconfig --level 35 nfslock on [root@smallfry tmp]# chkconfig --level 35 rpcbind on
2) Use the init scripts in the /etc/init.d directory to start the nfs and RPC rpcbind daemons. As on the server, the examples use the start option, but you can also stop and restart the processes with the stop and restart options.
[root@smallfry tmp]# service rpcbind start [root@smallfry tmp]# service netfs start [root@smallfry tmp]# service nfslock start
3) Test whether NFS is running correctly with the rpcinfo command. The listing of running RPC pro-grams you get must include status, portmapper, and nlockmgr.
[root@smallfry root]# rpcinfo -p program vers proto port
100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 32768 status 100024 1 tcp 32768 status 100021 1 udp 32769 nlockmgr 100021 3 udp 32769 nlockmgr 100021 4 udp 32769 nlockmgr 100021 1 tcp 32769 nlockmgr
100021 3 tcp 32769 nlockmgr 100021 4 tcp 32769 nlockmgr 391002 2 tcp 32770 sgi_fam [root@smallfry root]#
NFS and DNS
The NFS client must have a matching pair of forward and reverse DNS entries on the DNS server used by the NFS server. In other words, a DNS lookup on the NFS server for the IP address of the NFS client must return a server name that will map back to the original IP address when a DNS lookup is done on that same server name.
This is a security precaution added into the nfs package that lessens the likelihood of unauthorized servers from gaining access to files on the NFS server. Failure to correctly register your server IPs in DNS can result in "fake hostname" errors:
Nov 7 19:14:40 bigboy rpc.mountd: Fake hostname smallfry.my-site.com for 192.168.1.1 - forward lookup do
Accessing NFS Server Directories from the Client
In most cases, users want their NFS directories to be permanently mounted. This requires an entry in the /etc/fstab file in addition to the creation of the mount point directory.
The /etc/fstab File
The /etc/fstab file lists all the partitions that need to be auto-mounted when the system boots. Therefore, you need to edit the /etc/fstab file if you need the NFS directory to be made permanently available to us-ers on the NFS. For the example, mount the /data/files directory on server bigboy (IP address 192.16801.100) as an NFS-type filesystem using the local /mnt/nfs mount point directory.
#/etc/fstab
#Directory Mount Point Type Options Dump FSCK 192.168.1.100:/data/files /mnt/nfs nfs soft,nfsvers=2 0 0
This example used the soft and nfsvers options; Table 29.1 outlines these and other useful NFS mounting options you may want to use. See the NFS man pages for more details.
Possible NFS Mount Options
Option Description
bg Retry mounting in the background if mounting initially fails fg Mount in the foreground
soft Use soft mounting hard Use hard mounting
rsize=n The amount of data NFS will attempt to access per read operation. The default is dependent on the ker-nel. For NFS version 2, set it to 8192 to assure maximum throughput.
wsize=n The amount of data NFS will attempt to access per write operation. The default is dependent on the ker-nel. For NFS version 2, set it to 8192 to assure maximum throughput.
nfsvers=n The version of NFS the mount command should attempt to use
tcp Attempt to mount the filesystem using TCP packets: the default is UDP.
intr If the filesystem is hard mounted and the mount times out, allow for the process to be aborted using the usual methods such as CTRL-C and the kill command.
The steps to mount the directory are fairly simple, as you'll see.
Permanently Mounting the NFS Directory
You'll now create a mount point directory, /mnt/nfs, on which to mount the remote NFS directory and then use the mount -a command activate the mount. Notice how before mounting there were no files visi-ble in the /mnt/nfs directory, this changes after the mounting is completed:
[root@smallfry tmp]# mkdir /mnt/nfs making this a permanent NFS mount.
Note: There are multiple versions of NFS, the most popular of which is version 2, which most NFS clients use. Newer NFS servers may also be able to handle NFS version 4. To be safe, it is best to force the NFS server to export directories as version 2 using the nfsvers=2 option in the /etc/fstab file as shown in the example. Failure to do so may result in an error message.
[root@probe-001 tmp]# mount -a
mount to NFS server '192.168.1.100' failed: server is down.
[root@probe-001 tmp]#
Exercise-3:- This exercise illustrates NFS Troubleshooting
A basic NFS configuration usually works without problems when the client and server are on the same network. The most common problems are caused by forgetting to start NFS, to edit the /etc/fstab file, or to export the /etc/exports file. Another common cause of failure is the iptables firewall daemon running on either the server or client without the administrator realizing it.
When the client and server are on different networks, these checks still apply, but you'll also have to make sure basic connectivity has been taken care of. Sometimes a firewall being present on the path between the client and server can cause difficulties.
As always, no troubleshooting plan would be complete without frequent reference to the /var/log/messages file when searching for additional clues. Following Table shows some common NFS errors you'll encounter.
Some Common NFS Error Messages
Error Description
Too many levels of remote in path Attempting to mount a filesystem that has already been mounted.
Permission denied User is denied access. This could be the client's root user who has unprivi-leged status on the server due to the root_squash option. Could also be because the user on the client doesn't exist on the server.
No such host Typographical or DNS configuration error in the name of the server.
No such file or Directory Typographical error in the name of the file or directory: they don't exist.
NFS server is not responding The server could be overloaded or down.
Stale file handle A file that was previously accessed by the client was deleted on the server before the client closed it
Fake hostname Forward and reverse DNS entries don't exist for the NFS client.
The showmount Command
When run on the server, the showmount -a command lists all the currently exporte directories. It also shows a list of NFS clients accessing the server; in this case one client has an IP address of 192.168.1.102.
[root@bigboy tmp]# showmount -a All mount points on bigboy:
*:/home
192.168.1.102:*
[root@bigboy tmp]#
The "df" Command
The df command lists the disk usage of a mounted filesystem. Run it on the NFS client to verify that NFS mounting has occurred. In many cases, the root_squash mount option will prevent the root user from doing this, so it's best to try it as an unprivileged user.
[nfsuser@smallfry nfsuser]$ df -F nfs
Filesystem 1K-blocks Used Available Use% Mounted on 192.168.1.100:/home/nfsuser
1032056 346552 633068 36% /home/nfsuser [nfsuser@smallfry nfsuser]$
The nfsstat Command
The nfsstat command provides useful error statistics. The -s option provides NFS server stats, while the -c option provides them of for clients. Threshold guidelines are provided in the Table.
[root@bigboy tmp]# nfsstat -s Server rpc stats:
calls badcalls badauth badclnt xdrcall 1547 0 0 0 0
Server nfs v2:
null getattr setattr root lookup readlink 244 100% 0 0% 0 0% 0 0% 0 0% 0 0%
read wrcache write create remove rename 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
link symlink mkdir rmdir readdir fsstat 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
Server nfs v3:
null getattr setattr lookup access readlink 251 19% 332 25% 0 0% 265 20% 320 24% 0 0%
read write create mkdir symlink mknod 39 2% 14 1% 1 0% 1 0% 0 0% 0 0%
remove rmdir rename link readdir readdirplus
0 0% 0 0% 0 0% 0 0% 0 0% 31 2%
fsstat fsinfo pathconf commit 1 0% 34 2% 0 0% 14 1%
[root@bigboy tmp]#
Error Thresholds For The "nfsstat" Command
Value Threshold Description
readlink > 10% Excessive numbers of symbolic links slowing performance.
Try to replace them with a directory and mount the filesystem directly on this new mount point.
getattr > 50% File attributes, like file data, is cached in NFS. This value tracks the percen-tage of file attribute reads that are not from cache refresh requests. Usually caused by the NFS "noac" mount option which prevents file attribute cach-ing.
badcalls > 0 Bad RPC requests. Could be due to poorly configured authentication, the root user attempting to access data governed by the "root_squash" directive or having a user in too many groups.
retrans > 5% Percentage of requests for service that the client had to retransmit to the servers. Could be due to slow NFS servers or poor network conditions.
writes > 10% Writes are slow due to poor caching values. Check the "noac" and "wsize"
mount options.
Exercises for lab
Exercise 1:- This exercise illustrates NFS Installation
Exercise 2:-create a directory named 'shared' and configure the NFS server for sharing the newly created directory 'shared' with other systems.
Home Work
Configure an NFS server for the scenario given below:
A home user has a Linux server with low disk space. S(he) has another linux system in the house with some extra space in /home filesystem. Keeping the budget aspect in mind the user wants to share the free space on /home filesystem on the other system. Help him/her in configuring an NFS
1)
2) a Read-only access to the /data/files directory to all networks
3) Read/write access to the /home directory from all servers on the 192.168.1.0 /24 network, which is all addresses from 192.168.1.0 to 192.168.1.255
4) Read/write access to the /data/test directory from servers in the my-site.com DNS domain 5) Read/write access to the /data/database directory from a single server 192.168.1.203.
6)