Perform uniform mounting with generic NFS

Automatically consolidate many different NFS versions into a uniform mount

To efficiently achieve uniform mounting in the presence of multiple, simultaneous NFS version exports, you need a generic NFS mount utility. Learn how a generic NFS mount utility can help reduce handling multiple NFS versions and simplify the management of those versions. The article describes the concept of the generic NFS mount, outlines the advantages and applications of the system, and gives some overall design details.


Abhidnya P. Chirmule (, System Software Engineer, IBM

author photoAbhidnya Chirmule works as a System Software Engineer for the Network File System Team at the IBM Software Labs in Pune, India on Open Network Computing technologies such as RPC and NFS on the AIX platform. Abhidnya holds a bachelor's degree in computer engineering from the College of Engineering, Pune, India.

Chinmay Soman (, Associate Software Engineer, IBM

author photoChinmay Soman is a software engineer with IBM Systems and Technology Labs in Pune, India. He is currently involved in CTDB/Panache research activities. He has worked with the NFS team on the development and management of NFS on AIX. He holds a bachelor's degree in Computer Science and Engineering.

11 February 2009

Also available in Russian Japanese

The Network File System (NFS) is a well-used distributed file system that enables file operations to be performed on a server from remote clients. The server makes its directories or filesystems available to the rest of the world using an operation known as export. To access these directories, the client mounts the exported directories or filesystems to its local directory hierarchy. Inside the mounted directory, clients access the remote files as if they were stored locally on the machine. Currently, NFS sports three available versions for exporting and mounting of directories or filesystems: versions 2, 3, and 4.

In this article, we show you how to use a generic NFS mount to consolidate exporting and mounting of all existing NFS version into a single, seamless mechanism. Let's consider a scenario where the server has exported directory entries for all three versions of NFS. Currently, for the client to access all these entries, it has to separately mount each of these entries at different mount points. Although NFS version 4 provides a pseudo-tree mechanism that enables a single mount of all NFSv4 exported entries, it is applicable only to the entries made by that version. The client has to separately mount version 2 and 3 entries along with a single mount for version 4 (in case the pseudo-tree exists).

The generic NFS mount utility is essentially a wrapper for the mount command that enables the user to mount all possible exported entries from a particular server using a single command. Since any change on the NFS server is not desirable, internally this wrapper performs separate mounts on the client machine that are transparent to the user.

Consider the directory hierarchy on the NFS server as shown in Figure 1:

Figure 1. Directory hierarchy on the server
Directory hierarchy on the server

In this current scenario, the following mounts are required on the client machine:

  • One NFSv4 mount: This mounts the NFSv4 pseudo-tree (Fileset1 and Fileset2). The NFSv4 pseudo-tree feature allows the NFSv4 client to perform only one mount operation for all exported entries in the pseudo-tree.
  • Two NFSv3 mounts: This mounts Tools and Docs.
  • One NFSv3 mount: This mounts Binaries.

Using the generic NFS mount utility, these mounts are reduced to a single mount. Here is the command:

gennfsmount <NFS server>         <mountpoint>

The advantages of using the generic NFS mount include:

  • Users need to do only one mount operation to access all the information from the server; this was not previously supported.
  • Consider a server that exports old installation filesets in versions 2 and 3 and new filesets in version 4. Clients can access all these filesets and perform installations using a single operation.
  • Searching a file on a particular server and in a particular export directory/filesystem can be enhanced using this generic utility.
  • Because the utility handles automatic segregation of version-based NFS exports, it reduces the users' efforts to manage these different mount points.
  • NFS administrators can retain the old NFS version exports on the server since they would be available along with the newer version data items in a single mount command.

Similar output can be obtained using the automount utility, but it requires administrative overhead to configure the automount map files for the desired NFS mounts. The hostmap feature of automount claims to mount all exported entries from a server without necessitating any administrative configuration, but problems have been identified when it comes to mounting NFSv4 entries using hostmap. In addition, this operation is performed for all the servers listed in the /etc/hosts file. No solution exists for mounting all exported entries of one particular server at a single point.

Overall, the generic NFS mount mechanism is convenience for the user. Next, let's look at some of the design decisions when implementing a generic NFS mounter.

Design implementation details

Let's look at the basic architecture of a generic NFS mount system. The generic NFS mounter internally sends a request to the server asking for all the exported entries.

Figure 2. Generic NFS mount requests all exported entries
Generic NFS mount requests all exported entries

On receiving a reply from the server, the algorithm in Listing 1 is followed:

Listing 1. Algorithm for generic NFS mount
	Create temporary directories for all versions.

	Initialize list of mount security flavors. 
	Embed this list in each internal mount operation.

	For each item in the export-list
		Mount internally for every NFSv2 and NFSv3 export
		Update internal log
	End for
	Mount internally only once for NFSv4 export.
	Update internal log

The security flavors is a comma-separated list of security methods (sys, krb5, krb5i, and so on) used during read/write operations under the mount point. The list is used to match the security method supported by the server and employed during subsequent system calls under this mount point. A similar mechanism can be employed for the NFS version of the corresponding exported entry.

When all the internal mounts are completed, a unification of these internal directories is done using UnionFS as shown in Listing 2.

Listing 2. Unifying internal directories with UnionFS
mount -t unionfs -o dirs=<temp_dir1>[:<temp_dir2>...] none <mount-point>


UnionFS is a file system service for Linux® and FreeBSD that implements a union mount for other file systems by allowing files and directories of separate file systems (known as branches) to be transparently overlaid so that they form a single coherent file system. Contents of directories with the same path will be seen together in a single merged directory in the resultant file system. UnionFS for Linux has two versions:

  • Version 1.x is a standalone that can be built as a module.
  • Version 2.x is newer; it has been redesigned and reimplemented and is included in Andrew Morton's Linux -mm tree (so it should get into the main source tree).

Remember the previous scenario? The one NFSv4 mount for v4 pseudo-tree/two NFSv3 mounts for Tools and Docs/one NFSv3 mount for Binaries were on the client machine and we used the generic NFS mount utility—gennfsmount <NFS server> <mountpoint>—to reduce them to a single mount. Now in this case, the following temporary directories are created:

  • /tmp/NFSv4
  • /tmp/NFSv3/Tools
  • /tmp/NFSv3/Docs
  • /tmp/NFSv2/Binaries

These are then combined using unionfs as in Listing 3:

Listing 3. Merging using unionfs
mount -t unionfs -o dirs=/tmp/NFSv4:/tmp/NFSv3:/tmp/NFSv2 none /mnt

This results in the following directory hierarchy:

Figure 3. Hierarchy resulting from unionfs
Hierarchy resulting from unionfs

Next, let's look at how we can use the system.

Using the system

In this scenario, the NFS server exports different entries of different NFS versions. At the client side though, only one mount is performed: the generic NFS mount. Figure 4 shows exported entries at the server.

Figure 4. Exports at the server
Exports at the server

Here the server exports five NFS entries with different NFS versions. nfs4_A and nfs4_B form a NFSv4 pseudo-tree (/nfs4_A and /nfs4_A/nfs4_B). The remaining are versions 2 and 3 NFS exports.

Figure 5 shows files existing at the server.

Figure 5. Files existing at the server
Files existing at the server

In the current scenario, all these files would be available to the client under different mounted directories through individual mount operations. However, the proposed system enables the user to access all these files in a single hierarchy with a single mount operation.

Figure 6 shows the scenario as seen from the client after the generic NFS mount:

Figure 6. Output of generic NFS mount
Output of generic NFS mount

As you can see, Figure 6 shows multiple internal mounts performed by the generic NFS mounter. The directory where all the NFS mounts are merged is /mnt.


We've shown you the architecture and the mechanism behind a generic NFS mounter, a utility that will undoubtedly help the NFS clients by providing easier, one-point access to the files on the NFS server and by offering a more consolidated view of the NFS space.



Get products and technologies

  • With IBM trial software, available for download directly from developerWorks, build your next development project on Linux.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Linux on developerWorks

Zone=Linux, AIX and UNIX, Open source
ArticleTitle=Perform uniform mounting with generic NFS