exports man page on DigitalUNIX

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
DigitalUNIX logo
[printable version]

exports(4)							    exports(4)

NAME
       exports - Defines remote mount points for NFS mount requests

SYNOPSIS
       /etc/exports

DESCRIPTION
       The exports file specifies remote mount points for the NFS mount proto‐
       col per the NFS server specification (see Network File System  Protocol
       Specification, RFC1094).

       Each  entry in the /etc/exports file consists of a filesystem or direc‐
       tory name followed by an optional list of options or an	optional  list
       of  identifiers	or both. The identifiers define which remote hosts can
       mount that particular filesystem or directory.

       The identifiers listed beside the name of each filesystem or  directory
       can  be either host names, IP addresses, or NIS netgroups names.	 If no
       identifiers are listed, the entry is exported to all hosts.  If you are
       exporting  a  file  system to a client that has multiple network inter‐
       faces on a subnet, you must specify the host names or IP addresses  for
       all  of the interfaces; otherwise, export requests from the unspecified
       interfaces will be denied.

       A backslash character (\) in the right-most position of	a  line	 indi‐
       cates  line continuation.  A number sign (#) either at the beginning of
       a line or at the end of a syntax line marks a comment that  extends  to
       the  end	 of  that  line.  You cannot use a number sign at the end of a
       line containing a backslash character because the  backslash  nullifies
       the end of line character.

       Note  that  the	mount  command	will  touch the /etc/exports file when
       issued with the -t nfs option.  If you create a new /etc/exports	 file,
       you  should  ensure  that  its  ownership  is equivalent to that of the
       default, which is; bin:bin (3:4).

       The format of the exports file is as follows:

       pathname [option ...] [identifier ...]

       #comments

       The pathname specifies the name of a  mounted  local  filesystem	 or  a
       directory  of  a	 mounted local filesystem.  The pathname must begin in
       column 1.

       The following are valid export  file  options:  Maps  client  superuser
       access to uid 0 for all hosts mounting this path.  If you want to allow
       client superusers access to the filesystem or directory with  the  same
       permissions as a local superuser, use -root=0.  Use -root=0 only if you
       trust the superuser on the client system.  The default  is  for	client
       superusers  to  be  mapped  to uid -2, which maps a client superuser to
       nobody.	This limits access to world accessible	files.	 If  both  the
       -root=0 option and the -anon=uid option are used, the root option over‐
       rides the uid specified in anon for client superusers.  Maps the client
       superusers  on  the  specified hosts only to uid 0.  The format for the
       hostlist argument is as follows:

       client[:client]...

       The client specification can be a host name or IP address.  By default,
       client  superusers  are	mapped	to  -2.	 This option overrides the uid
       specified in -anon=uid for client superusers in hostlist.  Maps	anony‐
       mous  users  to	the  specified	uid.  Client superusers are considered
       anonymous by the NFS server, as are requests that come in without  UNIX
       authentication.	 By  default,  anonymous  users	 are mapped to uid -2.
       Setting anon to -1 disables anonymous access.  The filesystem or direc‐
       tory is exported read-only (default is read-write).  The -o option is a
       synonym for -ro for backward compatibility.  limits  read-write	access
       to the hosts specified.	All other hosts allowed to mount this path are
       granted read-only access.  The format for the hostlist argument	is  as
       follows:

       client[:client]...

       The client specification can be a host name or IP address.  If both the
       -ro and -rw=hostlist options are specified, -rw	prevails.   Exports  a
       filesystem  or  directory for WebNFS public access.  Note that only one
       exported filesystem can have this option set.

					Note
       When the -public option is set, the mount access list is ignored by the
       WebNFS server. This means that all hosts using the WebNFS protocol have
       access to this directory.

       After setting the -public option, be sure to send the mountd process  a
       HUP signal. See kill(1) for further information.
       Used  with -public option. Enables the server to look for an index.html
       file when given a directory name.  Specifies the hosts to  grant	 mount
       access to.  The format for the hostlist argument is as follows:

       client[:client]...

       The client specification can be a host name, IP address, or NIS network
       group.  This option is provided for readability and compatibility  with
       certain	export	file  formats.	 Alternatively, to identify the client
       systems who are allowed access to this export use the whitespace	 sepa‐
       rated identifier list described below.

       The options can be applied to both file system and directory entries in
       /etc/exports.

       Alternatively, you can list options using only  one  leading  dash  and
       separating them with commas as in -option[,option]....

       You  use the identifier field to specify host names, network groups, or
       both, separated by white space that specify the access  list  for  this
       export.	 Host names can optionally contain the local BIND domain name.
       A whitespace character in the left-most position of  a  line  indicates
       line continuation.

					Note
       If  no  hosts or netgroups are specified, the mount daemon exports this
       file system or directory to anyone requesting it.   See	the  mountd(8)
       reference  page	for  information  on  how to limit this scope to known
       hosts or to hosts in the same BIND domain.

       For example, suppose you enter:

       /usr -root=0 milan kuan_yin.cis.berkeley.edu  /usr/local	 555.555.55.55
       /u2	-ro	 /u3/dir1      -rw=milan:venice:florence      /u3/dir2
       -root=milan,access=venice:florence			      /u3/dir3
       -root=0,access=milan:venice:florence /u3/dir4 -root=0 milan venice flo‐
       rence /u3/dir5 -root=milan -anon=-1 /u3/dir6 -ro -public	 milan	venice
       florence

       If /usr, /u2 and /u3 are local file system mount points, this specifies
       the  following:	/usr  is  exported  read-write	to  hosts  milan   and
       kuan_yin.cis.berkeley.edu  with	root  mapped  to uid=0.	 /usr/local is
       exported read-write to host 555.555.55.55 with root mapped to -2.  (For
       security	  reasons,   this  example  uses  the  fictitious  IP  address
       555.555.55.55.)	/u2 is exported	 to  all  hosts	 read-only  with  root
       mapped  to -2.  /u3/dir1 is exported read-write to hosts milan, venice,
       and florence and read-only to all other hosts.  For all hosts, root  is
       mapped  to  -2.	 /u3/dir2  is  exported	 with root mapped to 0 to host
       milan.  Hosts milan, venice, and florence are  allowed  to  mount  this
       directory  read-write.	Root on hosts venice and florence is mapped to
       -2.  /u3/dir3 is exported read-write and with root mapped to 0 to hosts
       milan,  venice,	and florence.  /u3/dir4 is exported in the same manner
       as the previous example.	 /u3/dir5 is exported read-write to all hosts.
       Anonymous  users	 are  not  allowed  to	mount this directory, with the
       exception of the client superuser on host milan.	 Root is mapped	 to  0
       on  host	 milan	and  to	 -2 on all other hosts.	 /u3/dir6 Hosts milan,
       venice, and florence are allowed to mount this directory read-only. All
       other  hosts have read-only WebNFS access, but cannot mount this direc‐
       tory.

       Each file system that you want  to  allow  clients  to  mount  must  be
       explicitly defined.  Exporting only the root (/) will not allow clients
       to mount /usr.  Exporting only /usr will not  allow  clients  to	 mount
       /usr/local, if it is a file system.

       Duplicate  directory entries are not allowed.  The first entry is valid
       and following duplicates are ignored.

       Desired export options must be explicitly specified for	each  exported
       resource:  file	system or directory.  If a file system and subdirecto‐
       ries within it are exported, the options associated with the file  sys‐
       tem  are	 not  ``inherited.''  You do not need to export an entire file
       system to allow clients to mount subdirectories within it.

       The access list associated with each exported resource identifies which
       clients	can mount that resource with the specified options.  For exam‐
       ple, you can export an entire file system read-only, with  a  subdirec‐
       tory within it exported read-write to a subset of clients.  If a client
       that is not identified  in  the	export	access	list  of  a  directory
       attempts	 to  mount  it,	 then  access  is  checked against the closest
       exported ancestor.  If mount access is allowed at a higher level in the
       directory  tree	of the file system, the export options associated with
       the successful match will be in effect.

       To make a change to the exports file and have it	 take  effect  immedi‐
       ately,  send  the  mountd  process a HUP signal.	 Otherwise, the mountd
       process will reread the exports file the next time it receives a	 mount
       request from an NFS client or a showmount -e request.

RELATED INFORMATION
       Daemons: mountd(8), nfsd(8)

       Commands: showmount(8)

       Files: hosts(4), netgroup(4)

       Network Administration: Services delim off

								    exports(4)
[top]

List of man pages available for DigitalUNIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net