cp --preserve=mode and NFS4 ACLs

[Ross Burton]

Hi,

I've a weird divergence in behaviour and want to try and understand
what is going on and who is correct.

I have a source file on a NFS4 mount which has ACLs stuffed into
extended attributes.  I have a target directory on an ext4 mount.

In some cases this fails:

cp --preserve=mode /srv/foo ~/bar
cp: preserving permissions for ‘~/bar’: Operation not supported

Throwing an strace around it reveals that it's trying to write xattrs
to the destination:

fgetxattr(3, "system.nfs4_acl", NULL, 0) = 80
fgetxattr(3, "system.nfs4_acl",
"\0\0\0\3\0\0\0\0\0\0\0\0\0\36\1\237\0\0\0\6OWNER@\0\0\0\0\0", 80) =
80
fsetxattr(4, "system.nfs4_acl",
"\0\0\0\3\0\0\0\0\0\0\0\0\0\36\1\237\0\0\0\6OWNER@\0\0\0\0\0", 80, 0)
= -1 EOPNOTSUPP (Operation not supported)

This doesn't happen with the stock coreutils 9.1 on
fedora/suse/debian/ubuntu releases or coreutils 9.4 on fedora 40, but
breaks with coreutils 9.4 in ubuntu 24.04 or debian testing. Grabbing
a 9.1 package and running the binary on 2404 works fine, and the
reverse of running the 9.4 binaries on a 9.1 system fails so the
problem is the coreutils 9.4 upgrade and nothing else in the system.

Interestingly, /etc/xattr.conf on Fedora doesn't have system.nfs4_acl
entries (removed via
https://src.fedoraproject.org/rpms/attr/blob/rawhide/f/0003-attr-2.4.48-xattr-conf-nfs4-acls.patch)
which seems relevant but my understanding is that this was done so
that cp *could* write the flag as libattr's helper function ignores
any attributes listed in that file.

Can anyone shed some light on what is happening here?  Should debian
remove system.nfs4_acl from /etc/xattr.conf, or is there a different
issue somewhere else?

Thanks,
Ross