Unix/Linux Go Back    

RedHat 9 (Linux i386) - man page for exports (redhat section 5)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)

EXPORTS(5)									       EXPORTS(5)

       exports - NFS file systems being exported (for Kernel based NFS)


       The  file  /etc/exports	serves	as  the access control list for file systems which may be
       exported to NFS clients.  It is used by exportfs(8) to give information to  mountd(8)  and
       to the kernel based NFS file server daemon nfsd(8).

       The  file  format is similar to the SunOS exports file. Each line contains an export point
       and a whitespace-separated list of clients allowed to mount the file system at that point.
       Each listed client may be immediately followed by a parenthesized, comma-separated list of
       export options for that client. No whitespace is permitted between a client and its option

       Blank  lines are ignored.  A pound sign ("#") introduces a comment to the end of the line.
       Entries may be continued across newlines using a backslash. If  an  export  name  contains
       spaces  it  should  be  quoted  using  double quotes. You can also specify spaces or other
       unusual character in the export name using a backslash followed by the character  code  as
       three octal digits.

   Machine Name Formats
       NFS clients may be specified in a number of ways:

       single host
	      This  is	the  most  common format. You may specify a host either by an abbreviated
	      name recognized be the resolver, the fully qualified domain name, or an IP address.

	      NIS netgroups may be given as @group.  Only the host part of each netgroup  members
	      is  consider  in	checking  for membership.  Empty host parts or those containing a
	      single dash (-) are ignored.

	      Machine names may contain the wildcard characters * and ?.  This	can  be  used  to
	      make the exports file more compact; for instance, *.cs.foo.edu matches all hosts in
	      the domain cs.foo.edu. However, these wildcard characters do not match the dots  in
	      a domain name, so the above pattern does not include hosts such as a.b.cs.foo.edu.

       IP networks
	      You  can	also  export  directories to all hosts on an IP (sub-) network simultane-
	      ously. This is done by specifying an IP address and netmask pair as address/netmask
	      where  the  netmask  can	be specified in dotted-decimal format, or as a contiguous
	      mask length (for example, either `/' or `/22' appended to the  network
	      base  address result in identical subnetworks with 10 bits of host). Wildcard char-
	      acters generally do not work on IP addresses, though they may work by accident when
	      reverse DNS lookups fail.

   General Options
       exportfs understands the following export options:

       secure This  option  requires  that  requests  originate  on  an  internet  port less than
	      IPPORT_RESERVED (1024). This option is on by default. To turn it off, specify inse-

       rw     Allow  both  read and write requests on this NFS volume. The default is to disallow
	      any request which changes the filesystem.  This can also be made explicit by  using
	      the ro option.

       async  This option allows the NFS server to violate the NFS protocol and reply to requests
	      before any changes made by that request have been committed to stable storage (e.g.
	      disc drive).

	      Using  this  option  usually  improves performance, but at the cost that an unclean
	      server restart (i.e. a crash) can cause data to be lost or corrupted.

	      In releases of nfs-utils upto and including 1.0.0, this option was the default.  In
	      this and future releases, sync is the default, and async must be explicit requested
	      if needed.  To help make system adminstrators aware of this change, 'exportfs' will
	      issue a warning if neither sync nor async is specified.

	      This option has no effect if async is also set.  The NFS server will normally delay
	      committing a write request to disc slightly if it  suspects  that  another  related
	      write  request  may  be in progress or may arrive soon.  This allows multiple write
	      requests to be committed to disc with the one operation which can  improve  perfor-
	      mance.   If  an NFS server received mainly small unrelated requests, this behaviour
	      could actually reduce performance, so no_wdelay is available to turn it  off.   The
	      default can be explicitly requested with the wdelay option.

       nohide This  option  is	based  on the option of the same name provided in IRIX NFS.  Nor-
	      mally, if a server exports two filesystems one of which is mounted  on  the  other,
	      then  the  client  will  have to mount both filesystems explicitly to get access to
	      them.  If it just mounts the parent, it will see an empty directory  at  the  place
	      where the other filesystem is mounted.  That filesystem is "hidden".

	      Setting the nohide option on a filesystem causes it not to be hidden, and an appro-
	      priately authorised client will be able to move from the parent to that  filesystem
	      without noticing the change.

	      However, some NFS clients do not cope well with this situation as, for instance, it
	      is then possible for two files in the one apparent  filesystem  to  have	the  same
	      inode number.

	      The  nohide option is currently only effective on single host exports.  It does not
	      work reliably with netgroup, subnet, or wildcard exports.

	      This option can be very useful in some situations, but it should be used	with  due
	      care,  and  only	after  confirming that the client system copes with the situation

	      The option can be explicitly disabled with hide.

	      This option disables subtree checking, which has mild  security  implications,  but
	      can improve reliability is some circumstances.

	      If  a subdirectory of a filesystem is exported, but the whole filesystem isn't then
	      whenever a NFS request arrives, the server must check not only  that  the  accessed
	      file  is	in  the appropriate filesystem (which is easy) but also that it is in the
	      exported tree (which is harder). This check is called the subtree_check.

	      In order to perform this check, the server must include some information about  the
	      location	of  the  file  in the "filehandle" that is given to the client.  This can
	      cause problems with accessing files that are renamed while a client has  them  open
	      (though in many simple cases it will still work).

	      subtree  checking  is also used to make sure that files inside directories to which
	      only root has access can only be	accessed  if  the  filesystem  is  exported  with
	      no_root_squash (see below), even the file itself allows more general access.

	      As  a general guide, a home directory filesystem, which is normally exported at the
	      root and may see lots of file renames, should be	exported  with	subtree  checking
	      disabled.   A  filesystem  which	is mostly readonly, and at least doesn't see many
	      file renames (e.g. /usr or /var) and for	which  subdirectories  may  be	exported,
	      should probably be exported with subtree checks enabled.

	      The default of having subtree checks enabled, can be explicitly requested with sub-


	      This option (the two names are synonymous) tells the  NFS  server  not  to  require
	      authentication  of  locking  requests  (i.e.  requests which use the NLM protocol).
	      Normally the NFS server will require a lock request to hold a credential for a user
	      who  has	read  access  to  the file.  With this flag no access checks will be per-

	      Early NFS client implementations did not send credentials with lock  requests,  and
	      many  current  NFS  clients still exist which are based on the old implementations.
	      Use this flag if you find that you can only lock files which are world readable.

	      The default behaviour of requiring authentication for NLM requests can  be  explic-
	      itly requested with either of the synonymous auth_nlm, or secure_locks.

   User ID Mapping
       nfsd  bases  its access control to files on the server machine on the uid and gid provided
       in each NFS RPC request. The normal behavior a user would expect is that  she  can  access
       her  files on the server just as she would on a normal file system. This requires that the
       same uids and gids are used on the client and the server machine. This is not always true,
       nor is it always desirable.

       Very  often, it is not desirable that the root user on a client machine is also treated as
       root when accessing files on the NFS server. To this end, uid 0 is normally  mapped  to	a
       different  id: the so-called anonymous or nobody uid. This mode of operation (called `root
       squashing') is the default, and can be turned off with no_root_squash.

       By default, exportfs chooses a uid and gid of -2 (i.e. 65534) for squashed  access.  These
       values  can  also  be overridden by the anonuid and anongid options.  Finally, you can map
       all user requests to the anonymous uid by specifying the all_squash option.

       Here's the complete list of mapping options:

	      Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply
	      to any other uids that might be equally sensitive, such as user bin.

	      Turn off root squashing. This option is mainly useful for diskless clients.

	      Map  all	uids  and  gids to the anonymous user. Useful for NFS-exported public FTP
	      directories, news spool directories, etc. The  opposite  option  is  no_all_squash,
	      which is the default setting.

       anonuid and anongid
	      These options explicitly set the uid and gid of the anonymous account.  This option
	      is primarily useful for PC/NFS clients, where you might want all requests appear to
	      be  from	one  user.  As an example, consider the export entry for /home/joe in the
	      example section below, which maps all requests to uid 150 (which is supposedly that
	      of user joe).

       # sample /etc/exports file
       /	       master(rw) trusty(rw,no_root_squash)
       /projects       proj*.local.domain(rw)
       /usr	       *.local.domain(ro) @trusted(rw)
       /home/joe       pc001(rw,all_squash,anonuid=150,anongid=100)
       /pub	       (ro,insecure,all_squash)

       The  first  line exports the entire filesystem to machines master and trusty.  In addition
       to write access, all uid squashing is turned off for host trusty.  The  second  and  third
       entry  show  examples for wildcard hostnames and netgroups (this is the entry `@trusted').
       The fourth line shows the entry for the PC/NFS client discussed above. Line 5 exports  the
       public  FTP  directory to every host in the world, executing all requests under the nobody
       account. The insecure option in this entry also allows clients  with  NFS  implementations
       that don't use a reserved port for NFS.


4.2 Berkeley Distribution		 28 October 1999			       EXPORTS(5)
Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums

All times are GMT -4. The time now is 01:24 AM.