I'd think this is a coreutils issue rather than a glibc issue.

Presumably the NFS acls are layered on top of traditional ACLs, in which case all the routines from libacl should be usable.

If you run getacl on files/directories with NFSv4 ACLs, are any ACLs reported?

Jeff

No, getfacl command won't show them. I have to use nfs4_getfacl to display them.
Submitted RFE against coreutils package:
https://bugzilla.redhat.com/show_bug.cgi?id=767584

Ondrej

Both ls(1) and getfacl(1) use libacl to check ACLs.  libacl uses getxattr() to read the raw data.  getxattr() belongs to glibc, but there is only a trivial wrapper around the getxattr syscall.  As far as I understand the problem, there is nothing to fix or improve in glibc.

Actually, libacl uses a getxattr syscall wrapper from libattr.  This issue is  completely unrelated to glibc:

$ gdb -q --args getfacl .
(gdb) break getxattr
(gdb) run
Breakpoint 1, getxattr (path=0x7fffffffd1b0 ".", name=0x3316405db7 "system.posix_acl_access", value=0x7fffffffce30, size=132) at syscalls.c:223
223     {

(gdb) info sym getxattr
getxattr in section .text of /lib64/libattr.so.1

(gdb) list
218             return SYSCALL(__NR_fsetxattr, filedes, name, value, size, flags);
219     }
220
221     ssize_t getxattr (const char *path, const char *name,
222                                     void *value, size_t size)
223     {
224             return SYSCALL(__NR_getxattr, path, name, value, size);
225     }
226
227     ssize_t lgetxattr (const char *path, const char *name,

I am closing this out...