Posted by: Mangesh_Linux_Administrator | September 6, 2010

NFS (Network File System)


NFS


Topics:
Setting the Exports
Starting and Testing
Selecting the Server Version
Imports and Mounting
NFS Version 4

The Network File System (NFS) was originally developed by SUN Microsystems as a protocol that allowed communications between different computing environments. The NFS enables a UNIX workstation to mount an exported share from the server into its own filesystem, thus giving the user and the client the appearance that the sub filesystem belongs to the client; it provides a seamless network mount point.

The NFS protocol has been around for a few years now and has undergone many advancements and revisions. The initial NFS server implementations only supported UDP packets, while the later versions support stateful TCP connections; there are pros and cons for using both protocols. NFS support has been compiled into the Linux kernel now for a while, with NFS versions 2, 3 (RFC 1813) and 4 (RFC 3530) being supported by the 2.6 kernel for both UDP and TCP protocols.

This chapter will describe how to prepare and export shares for users and workstations from the Linux server, it will also cover the steps needed for the Linux client to view and mount those exports into its own filesystem. NFS Versions 2 and 3 are similar in implementation, while Version 4 is slightly different and detailed further in its own section.

The following list of man pages can provide further information to assist with configuration or debugging requirements.

Man Pages:
nfs
mount
fstab
mountd
exports
rpcinfo
exportfs
rpc.nfsd
portmap     rpc.mountd

Setting the Exports
When a user and client workstation connect to an NFS server, the server firstly checks to ensure that a connection can be established from the workstation. If the connection is allowed, then the user that is logged onto the workstation is then authenticated against their account located on the server to determine if they are an authorised user. If both checks confirm valid access, then they will be granted their normal permissions which also include any restrictions placed on the exported share. The users UID and GID must match between the client and the server.

The “/etc/exports” file contains the configuration settings for the servers exports, it may need to be created if it does not already exist. The following example displays a listing of the exported filesystems and the access restrictions that apply to each export.

[bash]# vi /etc/exports
1.
2.
3.
4.
5.
/home             linuxwkstn*(rw,sync)
/tmp/fileswap     *(rw,no_root_squash,async)
/filestore        192.168.1.0/24(rw,no_root_squash,sync)
/var/ftp          192.168.1.0/24(ro,all_squash,async)
/home/alice       admin(rw,all_squash,sync,anonuid=567,anongid=567)

The following details examine each of the entries which have been specified in the above exports file.

1.   The “/home” directory is accessible from ALL workstations whose hostnames start with “linuxwkstn”. The export has read / write permissions and the data transfer is synchronous in nature.

2.   The “/tmp/fileswap” directory is accessible from ALL workstations (regardless of name). The export has read / write permissions and data transfer is asynchronous. The root account on the local workstation will have root permission on the remote servers filesystem through the export.

3.   The “/filestore” directory is accessible to all hosts in the 192.168.1.0/24 subnet. The export has read / write permissions and data transfer is synchronous. The root account on the local workstation will have root permission on the remote servers filesystem through the export.

4.   The “/var/ftp” directory is accessible to all hosts in the 192.168.1.0/24 subnet. The export is read only, and all connecting users will be forced to connect as the “nobody” account (squashed). Data transfers are asynchronous.

5.   Alice’s home directory “/home/alice” is only accessible from the “admin” host workstation. The export has read / write permissions and data transfers are synchronous. All connecting users will be forced to connect as the UID and GID 567. This assumes the account in Alice’s name on the server is UID/GID 567.

The following are some of the basic exporting options, type “man exports” to see more information.

Options:
Description:
rw
Allows read and write access to the share
ro
Only allows read access, writing is blocked
all_squash
Forces all connecting users to “nobody” account and permissions
no_root_squash
Allows root account on client to access export share on server as the root account
anonuid
Forces all anonymous connections to predefined UID on server
anongid
Forces all anonymous connections to predefined GID on server

After the exports have been defined, the changes need to be passed through to the NFS mounting daemon (mountd) which stores a list of available exports in the /var/lib/nfs/etab (or xtab) file. Any adjustments are added or removed to synchronise the files.

[bash]# exportfs -rv
1.
2.
3.
4.
5.     exporting linuxwkstn*:/home
exporting *:/tmp/fileswap
exporting 192.168.1.0/24:/filestore
exporting 192.168.1.0/24:/var/ftp
exporting admin.example.com:/home/alice

Caution !!     Both the nfs and portmap services need to be restarted for new exports to be available to the client.

Starting and Testing
The nfs and portmap services should be set and checked for the appropriate runlevels. The portmap service should already be running on most standard Linux installations, but its save to check.

[bash]# chkconfig –level 345 nfs on
[bash]# chkconfig –level 345 portmap on
[bash]# chkconfig –list nfs
[bash]# chkconfig –list portmap

Although the export settings can be pushed through to the mounting daemon using the exportfs command, the nfs and portmap initscripts handle other important functions, so the services should both be restarted before trying to use the exported filesystem.

[bash]# /etc/init.d/nfs restart
[bash]# /etc/init.d/portmap restart

The available list of exports can be seen using the “showmount -e” command (for local or remote use).

[bash]# showmount -e galaxy

1.
2.
3.
4.
5.     Export list for galaxy:
/home         linuxwkstn*
/tmp/fileswap *
/filestore    192.168.1.0/24
/var/ftp      192.168.1.0/24
/home/alice   admin.example.com

The system logs should also be checked for any initialisation errors or events. The system log will normally contain any mounting or disconnecting calls and should be checked regularly to debug any NFS connections errors.

[bash]# tail -n 50 /var/log/messages

Setting the Server Versions
In the chapter’s opening, I mentioned that the Linux kernel has built-in support for NFS versions 2, 3 and 4. The rpcinfo command can be used to query the server which will return a listing of RPC details, most important are the nfs and mountd entries.

The following query of the “galaxy” server tells us that it is running NFS versions 2, 3 and 4 and connections are available using either the UDP and TCP protocols, it also identifies the server is accepting connections on port 2049; the default for NFS.

The lower part of the query tells us that mountd is accepting connections for versions 1, 2, and 3 of the NFS protocol, NFSv4 is handled differently and will be covered later.

[bash]# rpcinfo -p galaxy
program vers proto   port
100003    2   udp   2049  nfs
100003    3   udp   2049  nfs
100003    4   udp   2049  nfs
100003    2   tcp   2049  nfs
100003    3   tcp   2049  nfs
100003    4   tcp   2049  nfs
.
.   ### EXCESS REMOVED ###
.
100005    1   udp    997  mountd
100005    1   tcp   1000  mountd
100005    2   udp    997  mountd
100005    2   tcp   1000  mountd
100005    3   udp    997  mountd
100005    3   tcp   1000  mountd

The NFS mounting daemon can be configured to ignore calls from clients that are trying to connect with certain NFS versions. The following details in the “/etc/sysconfig/nfs” file instructs the mounting daemon to ignore versions 1 and 2. Type “man rpc.mountd” at the command prompt for further details on the mounting daemon.

[bash]# vi /etc/sysconfig/nfs
RPCMOUNTDOPTS=”-N 1 -N 2″

Warning !!     When you disable mountd versions 1 and 2, then the “showmount -e galaxy” command will fail with an error similar to: “rpc mount export: RPC: Program/version mismatch; low version = 3, high version = 3”. This can be alleviated by leaving all NFS versions running on the server and then forcing “nfsvers=3” in your “/etc/fstab” file on the remote client.

This is the “rpcinfo” output after making the above changes (nfs daemon not displayed).

[bash]# rpcinfo -p galaxy
program vers proto   port
.
.   ### EXCESS REMOVED ###
.
100005    3   udp    997  mountd
100005    3   tcp   1000  mountd

Caution !!     If you intend running NFSv4, then mountd must at least handle support for version 3; you can not disable all versions.

Imports and Mounting
Now that the server has been configured with the exported filesystem, the Linux workstations need to be configured so they can connect to the remote resources for mounting. The portmap service handles the call between the client and server, so the service should be running; the portmap service should already be active in a standard installation.

The rcpinfo command can be used on the Linux client to confirm that portmap service is running.

[bash]# rpcinfo -p linuxwkstn01
program vers proto   port
100000    2   tcp    111  portmapper
100000    2   udp    111  portmapper

Now that the portmap service is running, the “showmount -e galaxy” command can be executed on the client to query the server for any available exported resources.

[bash]# showmount -e galaxy

The exports that have been made available on the server need to be mounted on the client, this occurs in the same fashion that your partitions are mounted throughout the rest of your filesystem; with the use of mount points.

The workstation needs to have the mount point directories prepared for the exports to connect, creating the directories as required.

[bash]# mkdir /shared
[bash]# mkdir /workfiles
[bash]# mkdir /media/ftp
[bash]# mkdir /media/alice

The file system table (fstab) is a configuration file that details the static mounting details and different types of the filesystems that are configured on the host computer. The configurations may also specify any additional mounting options that should be associated with each entry.

The following entries in fstab list the mounting details for the local workstation that where declared earlier on the NFS server. The filesystem type declared is “nfs” which handles versions 2 and 3 of the protocol. The default version (depending on the server) is version 2, so the entries labeled 2 and 5 below have explicitly defined they are connecting to the server using version 3 (nfsvers=3).

[bash]# cp /etc/fstab /etc/fstab.original
[bash]# vi /etc/fstab
1.
2.
3.
4.
5.
galaxy:/home          /home          nfs    defaults 0 0
galaxy:/tmp/fileswap  /shared        nfs    defaults,nfsvers=3,tcp 0 0
galaxy:/filestore     /workfiles     nfs    defaults,rsize=8192,wsize=8192 0 0
galaxy:/var/ftp       /media/ftp     nfs    sync,auto,ro,noexec,hard,intr 0 0
galaxy:/home/alice    /media/alice   nfs    defaults,nfsvers=3,tcp,retry=30,rsize=8192,wsize=8192 0 0

Now that the file system table has been populated with the details needed to connect to the server, the connections can be made by calling the “mount” command. This example says activate the “/workfiles” mount point specified in the fstab file, which is line 3. Because all the relevant details are located in the file, the system will just mount it automatically.

[bash]# mount /workfiles

All of the connections can also be made at the same time by specifying the all (-a) option, and defining all the nfs types (-t). This is a quick command for mounting all the nfs connections at once.

[bash]# mount -a -t nfs

After the connection has been established, a directory listing reveals the directories located on the remote server. It appears seamless to the user and client workstation.

[bash]# ls -l /workfiles
drwxrwx—  4 root financial  4096 Jan  1 06:07 financial
drwxrwx—  3 root adminstaff 4096 Jan  1 06:07 adminstaff
drwxrwxrwx  4 root root       4096 Jan  1 06:07 shared

The connections can also be typed manually on the command line using the following example.

[bash]# mount -t nfs galaxy:/var/ftp /tmp/ftp -o ro,sync,auto,hard,intr

To see which connections have been established, the full mount listing can be displayed.

[bash]# mount -l

To disconnect the remote connection, the unmount command can be issued specifying the connection point (mount point).

[bash]# umount /media/ftp
[bash]# umount /workfiles

If the connections are configured correctly but appear to be problematic, then restarting the portmap service can normally assist; though this is rare.

[bash]# /etc/init.d/portmap restart

NFS Version 4
Version:     – kernel 2.6

Version 4 of the NFS brings a new range of advancements to the networking protocol, with access control lists, sophisticated security mechanisms, and better interoperability with firewall and NAT applications to name a few. To the average user the main difference will be in the configuration and its implementation.

Are You NFS4 Ready
If you are using a standard installed Linux distribution, you can easily check to see if it supports version 4. Assuming the nfs service is running on the server, the following “rcpinfo” command can be issued which returns the version numbers and protocols supported by the servers kernel; in this case version 4 is supported with both UDP and TCP (other versions have been removed from the display).

[bash]# rpcinfo -p galaxy
program vers proto   port
100003    4   udp   2049  nfs
100003    4   tcp   2049  nfs
.
.   ### EXCESS REMOVED ###

On the server the following mount command displays the running nfs daemon and also the ID to name mapping daemon (new to version 4).

### ON THE SERVER ###
[bash]# mount -l
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)

On the client the ID to name mapping daemon must also be present.

### ON THE CLIENT ###
[bash]# mount -l
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

Assuming these small checks are satisfied, your systems should be capable of implementing NFSv4.

Preparing The Server
The earlier versions (2 and 3) of NFS map anonymous users to the nobody account on the server. Depending on your distribution it may already have an account that is configured specifically for NFS anonymous access, in this case the “nfsnobody” account. If not, leave the default as the standard “nobody” account.

[bash]# grep nfs /etc/passwd
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin

The ID to name mapping daemon is a new enhancement to the NFSv4 protocol, it passes usernames between the client and server after mapping them from (and back to) UID and GID.

[bash]# vi /etc/idmapd.conf
[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = example.com

[Mapping]
Nobody-User = nfsnobody
Nobody-Group = nfsnobody

[Translation]
Method = nsswitch

The ID name mapping settings that are defined on the server also need to be replicated to the client workstations.

Setting Up The Server
The exports for an NFSv4 server are handled very much differently to the earlier versions of the protocol. For a version 4 server, all of the exports are handled through one export point (the pseudofilesystem), with all other exports grouped underneath the master export. Sounds confusing? All of the exports must be put into the one master directory, even if the original directories are located elsewhere in the filesystem.

In our example below, we are going to export several sections of the servers filesystem, however we need to create a master export point (pseudofilesystem), then place all of the exports we intend to share into that one master directory, then we export everything.

The “/NFS4exports” directory will hold all of our local filesystem resources that will be made available as exports, the three sub directories are the actual exported resources which need to be mapped back to the real resources.

[bash]# mkdir /NFS4exports
[bash]# mkdir /NFS4exports/ftp
[bash]# mkdir /NFS4exports/home
[bash]# mkdir /NFS4exports/filestore

The “/NFS4exports” directory and other three sub directories are empty so we need to create the links to the actual areas we are exporting.

Using mount and the fstab file, we are able to “bind” one section of the filesystem to another. This works similar in functionality to a symbolic link, however it is configured as a bind and the files are fully accessible in both sections of the filesystem, not just linked to the original location.

The following configuration is bind mounting the original directories (left) into the main “/NFS4exports” directory. Note the filesystem type is defined as “none” and the only options defined is the “bind” method.

[bash]# vi /etc/fstab
## BIND Mounting The Filesystem ##
/var/ftp         /NFS4exports/ftp         none     bind    0 0
/home            /NFS4exports/home        none     bind    0 0
/filestore       /NFS4exports/filestore   none     bind    0 0

After the fstab file has been configured, the mounts can be binded using the following command.

[bash]# mount -a -t none

The active mounts can be checked to confirm the successful mounting of the bind directories. At this point the filesystems have two access points to the same locations, this should not be confused with a symbolic link (although it is similar in understanding).

[bash]# mount -l | grep bind
/var/ftp on /NFS4exports/ftp type none (rw,bind)
/home on /NFS4exports/home type none (rw,bind)
/filestore on /NFS4exports/filestore type none (rw,bind)

Doing a directory listing of the “/NFS4exports/ftp” directory displays the “pub” directory that is actually located in “/var/ftp”. This indicates a successful bind.

[bash]# ls -l /NFS4exports/ftp
drwxr-xr-x  3 root root 4096 Dec  9 15:49 pub

The exports can now be defined for the server, similar to the examples for version 2 and 3. Be sure to check the nfs man page for NFSv4 specific export options. Type “man nfs” at the command prompt.

The most important configuration setting here is the “fsid=0” option which tells the server that this is the pseudofilesystem and that all other directories are contained within this one. Another important setting here is the anonuid and anongid values, they are set to 65534 which is the nfsbody account we identified earlier (if it exists, otherwise nobody account).

[bash]# vi /etc/exports
/NFS4exports                192.168.1.0/24(rw,insecure,sync,wdelay,no_subtree_check,no_root_squash,fsid=0)
/NFS4exports/ftp            192.168.1.0/24(ro,insecure,sync,wdelay,no_subtree_check,nohide,all_squash,anonuid=65534,anongid=65534)
/NFS4exports/filestore      192.168.1.0/24(rw,insecure,sync,wdelay,no_subtree_check,nohide,no_root_squash)
/NFS4exports/home           192.168.1.0/24(rw,insecure,sync,wdelay,no_subtree_check,nohide,no_root_squash)

Starting and Testing
As with the normal configuration, the services need to be configured at the appropriate runlevels and checked.

[bash]# chkconfig –level 345 nfs on
[bash]# chkconfig –level 345 portmap on
[bash]# chkconfig –list nfs
[bash]# chkconfig –list portmap

The services should be restarted.

[bash]# /etc/init.d/nfs restart
[bash]# /etc/init.d/portmap restart

The exports that are available from the server can be checked with the following commands.

[bash]# exportfs -v
[bash]# showmount -e localhost

Setting Up The Client
Before the client can be configured, we need to confirm the exports can be seen and are accessible to the client workstation. The following output displays the psuedofilesystem and the three subordinate exports.

[bash]# showmount -e galaxy
Export list for galaxy:
/NFS4exports           192.168.1.0/24
/NFS4exports/ftp       192.168.1.0/24
/NFS4exports/home      192.168.1.0/24
/NFS4exports/filestore 192.168.1.0/24

Similar to the servers earlier configuration, the client also needs to be configured with the ID to name mapping daemon. These settings should be the same as earlier defined on the server.

[bash]# vi /etc/idmapd.conf
[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = example.com

[Mapping]
Nobody-User = nfsnobody
Nobody-Group = nfsnobody

[Translation]
Method = nsswitch

The major difference for the NFSv4 client is the way the export is going to be mounted. All of the shares are located under one main export; the pseudofilesystem which is the only one that needs to be mounted.

We now need to create the mount point for our connection.

[bash]# mkdir /media/galaxy

The client needs to detail the mounting configurations and options in the fstab file. The noticeable difference below is the explicit setting for “nfs4”, if this is missed then the client will attempt to connect with an earlier NFS version.

All of the exports on the server are located under “/NFS4exports”, however when the connection is made, the configuration needs to specify the root connection of “galaxy:/” and not “galaxy:/NFS4exports”. Using the “/” (root) mount instructs the client to connect to the pseudofilesystem which was earlier configured on the server with the “fsid=0” option.

[bash]# vi /etc/fstab
galaxy:/ /media/galaxy nfs4 auto,rw,nodev,sync,_netdev,proto=tcp,retry=10,rsize=32768,wsize=32768,hard,intr 0 0

Note !!     The mounting options for NFSv4 are different to earlier versions, type “man nfs” at the command prompt to see the options available for all versions.

Now that the connection is configured on the client, the mount can be established with the following command.

[bash]# mount /media/galaxy

The mount can also be detailed and connected manually by typing a similar command at the prompt.

[bash]# mount -t nfs4 192.168.1.11:/ /mnt/testing \
-o async,auto,exec,_netdev,nodev,rw,retry=5,rsize=32768,wsize=32768,proto=tcp,hard,intr

A listing of the mounted filesystem determines whether the connection was successful.

[bash]# mount -l
galaxy:/ on /mnt/galaxy type nfs4 (rw,addr=galaxy)

Doing a directory listing of the mounted filesystem on the local client returns all of the subordinate mounts on the remote server.

[bash]# ls -l /media/galaxy
drwxr-xr-x  4 root root 4096 Jan  1 06:07 filestore
drwxr-xr-x  3 root root 4096 Jan  1 06:07 ftp
drwxr-xr-x  4 root root 4096 Jan  1 06:07 home

The systems are now all configured with the NFSv4 protocol.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

Categories

%d bloggers like this: