fedfs-map-nfs4 (8) - Linux Manuals
fedfs-map-nfs4: generate automounter program map entries for FedFS
NAMEfedfs-map-nfs4 - generate automounter program map entries for FedFS
INTRODUCTIONRFC 5716 introduces the Federated File System (FedFS, for short). FedFS is an extensible standardized mechanism by which system administrators construct a coherent namespace across multiple file servers using file system referrals. For further details, see fedfs(7).
DESCRIPTIONThe fedfs-map-nfs4(8) command provides a FedFS program map for the local system's automounter. Although it is typically intended to be invoked by the automounter, it is also safe to invoke directly for scripting or debugging purposes. See autofs(5) for information about how program maps work.
OperationThe fedfs-map-nfs4(8) command locates FedFS domains by looking for DNS SRV records that advertise file servers exporting FedFS domain root replicas. The domainname argument determines what FedFS domain is to be mounted.
It retrieves and sorts the domain root replica records according to SRV record sorting rules outlined in RFC 2782. It then generates a sun format map entry on stdout representing the set of servers contained in the SRV record, a standard export path to the domain root, and appropriate NFS mount options. Error messages are output on stderr.
Globally useful namesAcross all FedFS-enabled file system clients, a unique file object in a FedFS domain is always accessed via the same pathname. Such pathnames are referred to as globally useful names. See fedfs(7) for a full discussion.
The top-level directory of a globally useful name is always the networked file system type (NFS version 4, CIFS, and so on). A fedfs-map-nfs4(8) program map entry is used with the NFS version 4 top-level directory to provide globally useful names via the NFS version 4 protocol.
EXAMPLESTypically, a fedfs-map-nfs4(8) entry in /etc/auto.master looks like this:
After configuring and restarting autofs, to access files in the example.net FedFS domain, for instance, you can start with:
$ cd /nfs4/example.net
If the fedfs-map-nfs4(8) command cannot find the requested domain, no local directory is created and no mount operation is performed. Applications receive an ENOENT error in this case.
While these mounted domains remain active on the local system, the mounted-on directories remain visible. After a period of inactivity, the automounter automatically unmounts a FedFS domain.
Mount option inheritanceThe Linux NFS client treats an NFS referral as a server-initiated mount request. The referring fileserver provides only a list of server names and export paths. The mount options for this new mount are inherited from the new mount point's parent directory on the client.
As applications proceed deeper into a domain's namespace, they can encounter both file sets to which they have read-only access, and file sets to which they have read-write access. To allow applications proper access to both types of file sets, typically file-access clients mount domain root directories in read-write mode. All submounts of the domain root are then mounted read-write as well. Write access is controlled by fileservers.
For example, a domain root may contain an NFS version 4 referral to an export containing user home directories. The domain root may be exported read-only so file-access clients cannot update it, but user home directories would not be very useful if they could not be written to by their owners. The fileserver continues to employ user credentials to limit access as appropriate.
Network file system clients follow file system referrals as applications encounter them, which is similar to how an automounter works. Consider the initial mount of the domain root as if you are mounting a single whole file system, even though underneath, additional NFS mounts come and go as needed.
- master automounter map
COLOPHONThis page is part of the fedfs-utils package. A description of the project and information about reporting bugs can be found at http://wiki.linux-nfs.org/wiki/index.php/FedFsUtilsProject.
AUTHORChuck Lever <chuck.lever [at] oracle.com>
SEE ALSOfedfs(7), nfs(5), autofs(5),
RFC 2782 for a discussion of DNS SRV records