Suppose that you're on Ubuntu 24.04, using NFS v4 filesystems mounted from a Linux NFS fileserver , and at some point you do a 'ls -l' or a 'ls -ld' of something you don't own. You may then be confused and angered:
; /bin/ls -ld ckstst /bin/ls: ckstst: Permission denied drwx------ 64 ckstst [...] 131 Jul 17 12:06 ckstst
(There are situations where this doesn't happen or doesn't repeat, which I don't understand but which I'm assuming are NFS caching in action.)
If you apply
strace
to the problem, you'll find that the failing system call is
listxattr(2)
, which is trying to list 'extended attributes'. On Ubuntu 24.04, ls comes from Coreutils , and Coreutils apparently started using listxattr() in version 9.4.
The Linux NFS v4 code supports extended attributes (xattrs), which are from RFC 8276 ; they're supported in both the client and the server since mid-2020 if I'm reading git logs correctly. Both the normal Ubuntu 22.04 LTS and 24.04 LTS server kernels are recent enough to include this support on both the server and clients, and I don't believe there's any way to turn just them off in the kernel server (although if you disable NFS v4.2 they may disappear too).
However, the NFS v4 server doesn't treat listxattr() operations the way the kernel normally does. Normally, the kernel will let you do listxattr() on an object (a directory, a file, etc) that you don't have read permissions on, just as it will let you do stat() on it. However, the NFS v4 server code specifically requires that you have read access to the object. If you don't, you get EACCES ( no second S ).
(The sausage is made in nfsd_listxattr() in fs/nfsd/vfs.c , specifically in the fh_verify() call that uses NFSD_MAY_READ instead of NFSD_MAY_NOP, which is what eg GETATTR uses.)
In January of this year, Coreutils applied a workaround to this problem, which appeared in Coreutils 9.6 (and is mentioned in the release notes ).
Normally we'd have found this last year, but we've been slow to roll out Ubuntu 24.04 LTS machines and apparently until now no one ever did a 'ls -l' of unreadable things on one of them (well, on a NFS mounted filesystem).
(This elaborates on a Fediverse post . Our patch is somewhat different than the official one.)