Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
Let The Music Play: Join EFF Today

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
Copyright Info
Terms of Use
Privacy Info
Masthead / Impressum
Your Account

Private Messages

News Archive
Submit News
User Articles
Web Links


The Web

Who's Online
There are currently, 63 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here






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

       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 con­
       tains 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.  As these char­
              acters  also  match  the dots in a domain name, the
              given pattern will also match all hosts within  any
              subdomain of cs.foo.edu.

       IP networks
       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, spec­
              ify insecure.

       rw     Allow both read and write requests on this NFS vol­
              ume.  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 speci­

              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 oper­
              ation which can improve  performance.   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

       nohide This option is based on the option of the same name
              provided  in  IRIX  NFS.   Normally,  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".

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

              The option can be explicitly disabled with hide.

              This  option  disables  subtree checking, which has
              mild security implications, but can improve  relia­
              bility 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  sub­
              tree  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 subdirec­
              tories may be exported, should probably be exported
              with subtree checks enabled.

              The  default  of having subtree checks enabled, can
              be explicitly requested with subtree_check.


              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

       no_acl This  option tells nfsd to mask off acl permissions
              so that clients will only see a subset of the  per­
              missions  on  the exported file system. This subset
              is safe for NFSv2 clients, and  for  NFSv3  clients
              that  perform  access  decisions  locally.  Current
              NFSv3 clients use the ACCESS  RPC  to  perform  all
              access  decisions  on the server. The no_acl option
              should be used for nfs  exports  with  acl  support
              that  are  exported  to  NFSv2 clients, or to NFSv3
              clients that don't use the ACCESS RPC.  This option
              is  not  needed  for recent NFSv3 clients or if the
              exported  file  system  has  no  acl  support.  The
              default  is  to  export  with  acl  support enabled
              (i.e., no_acl is off.)


       mp     This option makes it  possible  to  only  export  a
              directory  if it has successfully been mounted.  If
              no path is given (e.g.  mountpoint or mp) then  the
              export  point  must  also  be a mount point.  If it
              isn't then the export point is not exported.   This
              allows you to be sure that the directory underneath
              a mountpoint will never be exported by accident if,
              for  example, the filesystem failed to mount due to
              a disc error.

              If a  path  is  given  (e.g.   mountpoint=/path  or
              mp=/path)  then  the nominted path must be a mount­
              point for the exportpoint to be exported.

   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  squash­
       ing')   is  the  default,  and  can  be  turned  off  with

              Turn off root squashing. This option is mainly use­
              ful 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  net­
       groups  (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.



                         28 October 1999               EXPORTS(5)



Security Code
Security Code
Type Security Code

Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!

Amazon Wish List

Did You Know?
You can get all the latest Site and Linux news by checking out our news page.


Tell a Friend About Us

Bookmark and Share

Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.09 Seconds