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
