Access Control List Troubleshooting

Edit online

The following information can be used for troubleshooting the Access Control List (ACL).

NFS4 Access Control List on an object failed application

You can use the return code or the trace facility to troubleshoot problems with setting an NFS4 ACL on an object, such as a file or directory. Both methods use command the aclput command and the acledit command to find the cause of the problem.

Using the Return Code for troubleshooting

To display the return code, use the echo $? command after you run the aclput command. The following lists shows the return codes and their explanations:

22 (EINVAL, defined in /usr/include/sys/errno.h)
The following are possible causes for this code:
  • Invalid textual format in any field of the 4 fields.
  • The size of the input NFS4 ACL is more than 64 KB.
  • The ACL is applied on a file that already has at least one ACE with ACE mask set to w (WRITE_DATA) but not p (APPEND_DATA) or p (APPEND_DATA) but not w (WRITE_DATA).
  • The ACL is applied on a directory that already has at least one ACE with ACE mask set to w (WRITE_DATA) but not p (APPEND_DATA) or p (APPEND_DATA) but not w (WRITE_DATA), and the ACE flag fi (FILE_INHERIT ).
  • There is at least one ACE with OWNER@ set as a special who (Identity) and one or more of the ACE masks c (READ_ACL), C (WRITE_ACL), a (READ_ATTRIBUTE) and A (WRITE_ATTRIBUTE) are being denied by ACE type d.
124 (ENOTSUP, defined in /usr/include/sys/errno.h)
The following are possible causes for this code:
  • The special who might not be any one of the three values (OWNER@, GROUP@, or EVERYONE@) in one of the ACEs.
  • There is at least one ACE with ACE type u (AUDIT) or l (ALARM).
13 (EACCES, defined in /usr/include/sys/errno.h)
The following are possible causes for this code:
  • You are not allowed to read the input file containing NFS4 ACEs.
  • You are not allowed to search the parent directory of the target object because you do not have x (EXECUTE) permission on the parent directory of the target object.
  • You might not be allowed to write or change the ACL. If the object is already associated with an NFS4 ACL ensure that you are have the privilege for the ACE mask C (WRITE_ACL).

Using the Trace facility for troubleshooting

You can also generate a trace report to find the cause of the problem. The following scenario shows how to use trace to find the cause of the problem applying an NFS4 ACL. If you have a file, /j2v2/file1 with the following NFS4 ACL: 
 s:(EVERYONE@):  a       acC
And, the following ACL is contained in the input_acl_file input file: 
s:(EVERYONE@):  a       rwxacC
Complete the following steps to troubleshoot with the trace facility:
  1. Run the trace, aclput and trcrpt using the following commands: 
    $ trace -j  478 -o trc.raw
$->!aclput -i input_acl_file -t NFS4 /j2v2/file1
$ ->quit
$ trcrpt trc.raw > trc.rpt
  2. Analyze the trace report. When the ACL is applied on a file or directory, it checks for the access to write or change the ACL, and then applies the ACL. The file contains lines similar to the following: 
    478 xxx  xxx  ACL ENGINE: chk_access entry: type=NFS4 obj_mode=33587200 size=68 ops=16384 uid=100

478 xxx  xxx  ACL ENGINE: chk_access exit: type=NFS4 rc=0 ops=16384 priv=0 against=0
478 xxx  xxx  ACL ENGINE: set_acl entry: type=NFS4 ctl_flg=2 obj_mode=33587200 mode=0 size=48

478 xxx  xxx  ACL ENGINE: validate_acl: type=NFS4 rc=22 ace_cnt=1 acl_len=48 size=12
478 xxx  xxx  ACL ENGINE: set_acl exit: type=NFS4 rc=22 obj_mode=33587200 size=68 cmd=536878912
    The second line containing, chk_access exit, indicates access is allowed (rc = 0) to write the ACL. The fourth line, containing validate_acl, and the fifth line, containing set_acl exit, indicate that the ACL is not applied successfully (rc=22 indicates EINVAL). The fourth line, containing validate_acl, indicates there is problem in the first line of the ACE (ace_cnt=1). If you refer to the first ACE, s:(EVERYONE@): a rwxacC), there is no p as the access mask. The p is needed in addition to the w when applying the ACL.

Troubleshooting access denies

A filesystem operation (for example, read or write) might fail on an object associated with an NFS4 ACL. Usually, an error message is displayed, but that message might not contain enough information to determine the access problem. You can use the trace facility to find the access problem. For example, if you have a file, /j2v2/file2 with the following NFS4 ACL: 
s:(EVERYONE@):  a       rwpx
The following command reports a "Permission denied" error: 
ls -l /j2v2/file2
Complete the following steps to troubleshoot this problem:
  1. Run the trace, ls -l /j2v2/file2 and trcrpt using the following commands: 
    $ trace -j  478 -o trc.raw
$->!ls -l /j2v2/file2
$ ->quit
$ trcrpt trc.raw > trc.rpt
  2. Analyze the trace report. The file contains lines similar to the following: 
    478  xxx  xxx   ACL ENGINE: chk_access entry: type=NFS4 obj_mode=33587711 size=68 ops=1024 uid=100
478  xxx  xxx   ACL ENGINE: nfs4_chk_access_self: type=NFS4 aceN=1 aceCnt=1 req=128 deny=0
478  xxx  xxx   ACL ENGINE: nfs4_mask_privcheck: type=NFS4 deny=128 priv=128
478  xxx  xxx   ACL ENGINE: chk_access exit: type=NFS4 rc=13 ops=1024 priv=0 against=0
    The third line indicates the access is denied for access mask = 128 (0x80) which is only READ_ATTRIBUTES (see the /usr/include/sys/acl.h file).