Man Linux: Main Page and Category List


       nfs4_acl - NFSv4 Access Control Lists


       An ACL is a list of permissions associated with a file or directory and
       consists of one or more Access  Control  Entries  (ACEs).   NFSv4  ACLs
       provide   finer   granularity  than  typical  POSIX  read/write/execute
       permissions and are similar to CIFS ACLs.

       A sample NFSv4 file ACL might look like  the  following  (see  the  ACL
       FORMAT section for detailed information):


       Some observations:

       -  In  the example output above, the user ‘’ has the
          equivalent of "read" and "execute" permissions,  ‘’
          has  "read"  and  "write",  and  both  ‘GROUP@’ and ‘EVERYONE@’ have

       -  NFSv4 ACLs are "default-deny"; that  is,  if  a  permission  is  not
          explicitly  granted by an Allow ACE, it is denied.  Because of this,
          the two Deny ACEs above are superfluous and could be excluded by the
          server.   See  the  A  WARNING  ABOUT  DENY  ACES  section  for more

       -  NFSv4 servers may return an ACL slightly different than one you set.
          For example, a server that always allows reading the attributes of a
          file may silently turn on  the  read-attributes  permission,  and  a
          server  that  does  not  support separate write-data and append-data
          permissions, e.g., may choose to turn off both if you set only  one.
          In  extreme cases the server may also reorder or combine ACEs.  As a
          general rule, however, servers will attempt to ensure that the  ACLs
          they return are no more permissive than the ones you set.


       An  NFSv4  ACL  is  written  as  an  acl_spec,  which  is  a  comma- or
       whitespace-delimited string consisting of one  or  more  ace_specs.   A
       single NFSv4 ACE is written as an ace_spec, which is a colon-delimited,
       4-field string in the following format:


       There are four types of ACEs, each represented by a  single  character.
       An ACE must have exactly one type.

       A      Allow   -   allow   principal   to   perform  actions  requiring

       D      Deny -  prevent  principal  from  performing  actions  requiring

       U      Audit  -  log  any  attempted access by principal which requires
              permissions.  Requires one or both of the successful-access  and
              failed-access  flags.   System-dependent;  not  supported by all

       L      Alarm - generate a system  alarm  at  any  attempted  access  by
              principal  which  requires permissions.  Requires one or both of
              the  successful-access   and   failed-access   flags.    System-
              dependent; not supported by all servers.

       There   are   three   kinds  of  ACE  flags:  group,  inheritance,  and
       administrative.  An Allow or Deny ACE may contain zero or  more  flags,
       while  an  Audit  or  Alarm  ACE  must  contain  at  least  one  of the
       successful-access and failed-access flags.

       Note that ACEs are inherited from the parent  directory’s  ACL  at  the
       time a file or subdirectory is created.  Accordingly, inheritance flags
       can be used only in ACEs  in  a  directory’s  ACL  (and  are  therefore
       stripped  from  inherited  ACEs  in  a new file’s ACL).  Please see the
       INHERITANCE FLAGS COMMENTARY section for more information.

       GROUP FLAG - can be used in any ACE

       g      group - indicates that principal represents a group instead of a

       INHERITANCE FLAGS - can be used in any directory ACE

       d      directory-inherit  -  newly-created  subdirectories will inherit
              the ACE.

       f      file-inherit - newly-created files will inherit the  ACE,  minus
              its   inheritance   flags.   Newly-created  subdirectories  will
              inherit the ACE; if directory-inherit is not also  specified  in
              the parent ACE, inherit-only will be added to the inherited ACE.

       n      no-propagate-inherit - newly-created subdirectories will inherit
              the ACE, minus its inheritance flags.

       i      inherit-only  - the ACE is not considered in permissions checks,
              but it is heritable; however, the inherit-only flag is  stripped
              from inherited ACEs.

       ADMINISTRATIVE FLAGS - can be used in Audit and Alarm ACEs

       S      successful-access  -  trigger  an  alarm/audit when principal is
              allowed to perform an action covered by permissions.

       F      failed-access  -  trigger  an  alarm/audit  when  principal   is
              prevented from performing an action covered by permissions.

       A  principal  is  either a named user (e.g., ‘’) or
       group (provided the group flag is also set), or one  of  three  special
       principals:   ‘OWNER@’,   ‘GROUP@’,   and   ‘EVERYONE@’,   which   are,
       respectively, analogous to the POSIX user/group/other distinctions used
       in, e.g., chmod(1).

       There  are a variety of different ACE permissions (13 for files, 14 for
       directories), each represented by a single character.   An  ACE  should
       have one or more of the following permissions specified:

       r      read-data (files) / list-directory (directories)

       w      write-data (files) / create-file (directories)

       a      append-data (files) / create-subdirectory (directories)

       x      execute (files) / change-directory (directories)

       d      delete  -  delete the file/directory.  Some servers will allow a
              delete to  occur  if  either  this  permission  is  set  in  the
              file/directory  or  if the delete-child permission is set in its
              parent direcory.

       D      delete-child - remove a file or  subdirectory  from  within  the
              given directory (directories only)

       t      read-attributes - read the attributes of the file/directory.

       T      write-attributes - write the attributes of the file/directory.

       n      read-named-attributes   -  read  the  named  attributes  of  the

       N      write-named-attributes -  write  the  named  attributes  of  the

       c      read-ACL - read the file/directory NFSv4 ACL.

       C      write-ACL - write the file/directory NFSv4 ACL.

       o      write-owner - change ownership of the file/directory.

       y      synchronize  -  allow  clients  to  use synchronous I/O with the


       Inheritance flags can be divided into two categories: "primary"  (file-
       inherit  and  directory-inherit); and "secondary" (no-propagate-inherit
       and inherit-only), which are significant only insofar  as  they  affect
       the two "primary" flags.

       The  no-propagate-inherit  and  inherit-only  flags  can  be  tricky to
       remember: the former determines whether or not a new child  directory’s
       inherited  ACE  is  itself  heritable by a grandchild subdirectory; the
       latter determines whether or not a heritable  ACE  affects  the  parent
       directory  itself  (in  addition to being heritable).  They can be used

       When a subdirectory inherits an ACE from its  parent  directory’s  ACL,
       this  can  happen in one of two different ways, depending on the server

       -  In the simple case, that exact same ACE is set in the subdirectory’s

       -  In  the  other  case,  two different ACEs will instead be set in the
          subdirectory’s ACL: one with all inheritance flags removed, and  one
          with  the  inherit-only  flag  added.  The former is the "effective"
          inherited ACE (used in the subdirectory’s own  permissions  checks);
          the  latter  is the "heritable" inherited ACE (when the subdirectory
          has directories created within it, they inherit it).  This  approach
          makes  it  easier to modify access rights to the subdirectory itself
          without modifying its heritable ACEs.


       Deny ACEs should be avoided whenever possible.   Although  they  are  a
       valid  part  of NFSv4 ACLs, Deny ACEs can be confusing and complicated.
       This stems primarily from the fact that, unlike  POSIX  ACLs  and  CIFS
       ACLs,  the  ordering  of  ACEs  within  NFSv4 ACLs affects how they are

       First, it is important to note that (despite some unfortunate ambiguity
       in  RFC3530)  NFSv4 ACLs are "default-deny" in practice.  That is, if a
       permission is not explicitly granted, it is denied.

       In general, when a principal is attempting to perform  an  action  over
       NFSv4  which  requires  one  or  more  permissions,  an access check is
       performed.  The NFSv4 ACL (assuming one is present) is  evaluated  ACE-
       by-ACE  until  every  one  of  those permissions has been addressed, or
       until the end of the ACL is reached.  If every requisite permission was
       granted  by  Allow  ACEs  and  was not forbidden by Deny ACEs (see next
       paragraph), the action is allowed to proceed.  Otherwise, the action is

       Note  that each requisite permission is only addressed once -- that is,
       after a permission has been explicitly Allowed or Denied once during an
       access  check,  any  subsequent  ACEs  in  the  ACL  which  affect that
       permission are no longer considered.  This often introduces problematic
       ordering issues when Deny ACEs are present.

       Additionally,  in  some  cases Group-Deny ACEs can be difficult (if not
       impossible) to enforce, since a server might not know about  all  of  a
       given principal’s memberships in remote groups, e.g.

       Because  NFSv4  ACLs  are "default-deny", the use of Deny ACEs can (and
       should) be avoided entirely in most cases.


       Tools  for  viewing  and  manipulating  NFSv4  ACLs,  nfs4_getfacl  and
       nfs4_setfacl,   were   written  by  people  at  CITI,  the  Center  for
       Information Technology Integration  (   This
       manpage was written by David Richter and J. Bruce Fields.


       Please   send   bug   reports,   feature   requests,  and  comments  to


       nfs4_getfacl(1),  nfs4_setacl(1),  RFC3530  (NFSv4.0),  NFSv4.1   Minor
       Version Draft.