FEDFS-MAP-NFS4(8)					      System Manager's Manual						 FEDFS-MAP-NFS4(8)

NAME

       fedfs-map-nfs4 - generate automounter program map entries for FedFS

SYNOPSIS

       fedfs-map-nfs4 domainname

INTRODUCTION

       RFC  5716  introduces the Federated File System (FedFS, for short).  FedFS is an extensible standardized mechanism by which system adminis-
       trators construct a coherent namespace across multiple file servers using file system referrals.  For further details, see fedfs(7).

DESCRIPTION

       The 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.

   Operation
       The 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 names
       Across  all FedFS-enabled file system clients, a unique file object in a FedFS domain is always accessed via the same pathname.	Such path-
       names 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 proto-
       col.

EXAMPLES

       Typically, a fedfs-map-nfs4(8) entry in /etc/auto.master looks like this:

	      /nfs4  /usr/sbin/fedfs-map-nfs4

       Under the /nfs4 directory on the local system, the automounter uses fedfs-map-nfs4(8) to convert a FedFS domain name to a  set  of  servers
       and an export path, which are then passed to mount.nfs(8).  The automounter mounts this FedFS domain on the directory /nfs4/domainname.

       After configuring and restarting autofs, to access files in the example.net FedFS domain, for instance, you can start with:

	      $ cd /nfs4/example.net

       The automounter uses the fedfs-map-nfs4(8) command to look up the file servers that provide the domain root for the example.net domain.	It
       then mounts one of these servers on /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.

       Local applications browsing the top-level directory do not see all available FedFS domains.  They see only the ones that  are  mounted  and
       active.

   Mount option inheritance
       The  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.

FILES

       /etc/auto.master  master automounter map

SEE ALSO

       fedfs(7), nfs(5), autofs(5),

       RFC 2782 for a discussion of DNS SRV records

       RFC 5716 for FedFS requirements and overview

COLOPHON

       This  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.

AUTHOR

       Chuck Lever <chuck.lever@oracle.com>

								  3 February 2014						 FEDFS-MAP-NFS4(8)