Why is 'getxattr' querying 'system.posix_acl_access' when the 'noacl' mount option is being used on an NFSv3 mount?

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux
  • NFSv3 mounted with noacl

Issue

  • NFSv3 clients mounting with the noacl mount option are seeing getxattr overhead.
  • When stat() is issued against an NFS share mounted with the noacl mount option, ACL related operations are being ran against the share:
lgetxattr("foobar", "system.posix_acl_access", 0x0, 0) = -1 EOPNOTSUPP (Operation not supported)

Resolution

  • This is expected behavior.

Root Cause

  • The EOPNOTSUPP (Operation not supported) error appearing in this instance is a bit confusing. It is appearing because lgetxattr() is not supported when ran against an NFS share that has been mounted with the noacl mount option. The noacl mount option is working correctly in this instance as the GETACL operations are not being sent over-the-wire and are instead being blocked from being sent by the mount option.

Diagnostic Steps

  • An example can be found below. An strace of the ls -l . command has been issued against against an NFS share (mounted over loopback for easy testing) with the mount options below:
    • ACL Enabled: localhost:/home/share on /mnt/nfs type nfs (rw,vers=3,noac,addr=::1)
    • ACL Disabled: localhost:/home/share on /mnt/nfs type nfs (rw,vers=3,noac,noacl,addr=::1)

ACL Enabled

  • Here's a snippet from the 'ls -l .' command issued on the NFS share directory:
 # strace -ls -l .
 lgetxattr("foobar", "system.posix_acl_access", 0x0, 0) = -1 ENODATA (No data available)
  • In addition a tcpdump has been captured during while running the ls -l using the command:
  # tcpdump -s0 -i INTERFACE host NFS.SERVER.IP -w /tmp/tcpdump-acl.pcap
  • Notice the GETACL Call's on-the-wire, which is expected behavior:
  9   2.138568          ::1 -> ::1          NFS 200 V3 GETATTR Call, FH:0x62d40c52
 10   2.138603          ::1 -> ::1          NFS 204 V3 GETATTR Reply (Call In 9)  Directory mode:0777 uid:0 gid:0
 11   2.138660          ::1 -> ::1          NFS 224 V3 READDIRPLUS Call, FH:0x62d40c52
 12   2.138753          ::1 -> ::1          NFS 1640 V3 READDIRPLUS Reply (Call In 11) . foo foo2 foobar foobardir hi1 .. hi2 file2 hi3
 13   2.138863          ::1 -> ::1          NFSACL 212 V3 GETACL Call
 14   2.138916          ::1 -> ::1          NFSACL 276 V3 GETACL Reply (Call In 13)

ACL Disabled

  • Here's the same snippet from the 'ls -l .' command issued again with the noacl mount option used:
 # strace -ls -l .
 lgetxattr("foobar", "system.posix_acl_access", 0x0, 0) = -1 EOPNOTSUPP (Operation not supported)
  • Notice the lack of GETACL Call's on the wire, which shows that the GETACL Call's are being blocked from ever being sent client-side.
 10   3.980709          ::1 -> ::1          NFS 200 V3 GETATTR Call, FH:0x62d40c52
 11   3.980743          ::1 -> ::1          NFS 204 V3 GETATTR Reply (Call In 10)  Directory mode:0777 uid:0 gid:0
 12   3.980788          ::1 -> ::1          NFS 224 V3 READDIRPLUS Call, FH:0x62d40c52
 13   4.003144          ::1 -> ::1          NFS 1640 V3 READDIRPLUS Reply (Call In 12) . foo foo2 foobar foobardir hi1 .. hi2 file2 hi3
 14   4.003290          ::1 -> ::1          NFS 208 V3 READLINK Call, FH:0xb92ec9ca
 15   4.003366          ::1 -> ::1          NFS 220 V3 READLINK Reply (Call In 14) Path: foobardir/

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments