Hmm, interesting. First of all, I do not quite understand where this:
"GNU coreutils upstream says that NFS-related entries should be removed from the default /etc/xattr.conf to make copying of NFSv4 ACLs work:" ...comes from. Do we know who told Kamil to remove "system.nfs4acl" entries from /etc/xattr.conf? Because when removed, then "cp -p" is calmed down indeed - simply because it will no longer be able to copy NFSv4 ACLs The example Ross mentioned is quite clear as you are trying to copy NFSv4 filesystem with a non-trivial ACLs to ext4 mount. Since ext4 filesystem is unable to store these ACLs, then "cp -p" fails with message "Operation not supported" As Padraig says, on Linux, this operation will currently (sadly enough) only succeed when copying NFSv4->NFSv4. In my view, the commit to xattr.conf should be reverted - yes people might scream about that message, but that's a not a bug, it is a new feature! Ondrej ________________________________ From: Pádraig Brady <pixelb...@gmail.com> on behalf of Pádraig Brady <p...@draigbrady.com> Sent: Tuesday, September 24, 2024 3:28 PM To: Ross Burton <r...@burtonini.com>; coreutils@gnu.org <coreutils@gnu.org> Cc: Ondrej Valousek <ondrej.valousek...@renesas.com> Subject: Re: cp --preserve=mode and NFS4 ACLs On 24/09/2024 13:31, Ross Burton wrote: > 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://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsrc.fedoraproject.org%2Frpms%2Fattr%2Fblob%2Frawhide%2Ff%2F0003-attr-2.4.48-xattr-conf-nfs4-acls.patch&data=05%7C02%7Condrej.valousek.xm%40renesas.com%7C8e88e29999af4effb01c08dcdca53760%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C638627849375073436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=RJw5SFiSz1RPrae5bOcVad0u6H5ytfBOyPzPhqOTIGo%3D&reserved=0)<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? I'm not sure what's going on here. Note NFS -> NFS may be better supported than NFS -> EXT4 where some translation may be needed. See for example: https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnu.org%2Farchive%2Fhtml%2Fbug-coreutils%2F2015-06%2Fmsg00101.html&data=05%7C02%7Condrej.valousek.xm%40renesas.com%7C8e88e29999af4effb01c08dcdca53760%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C638627849375092593%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=QvVHrhO%2FcE6TTn8krFvHVJRAyP2%2B8t3%2F55up1z0jgOA%3D&reserved=0<https://lists.gnu.org/archive/html/bug-coreutils/2015-06/msg00101.html> It would be good to see what's happening on the "working" system. I.e. does Fedora 40 (+ coreutils 9.4) do the fsetxattr(4, "system.nfs4_acl", ...) successfully? Note Fedora coreutils links with libacl, which may do some of the lifting here. Does Ubuntu also use libacl? I don't think there were coreutils specific changes in this area, but there were related gnulib changes: https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcoreutils%2Fgnulib%2Fcommit%2Feb6a8a4dfb&data=05%7C02%7Condrej.valousek.xm%40renesas.com%7C8e88e29999af4effb01c08dcdca53760%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C638627849375103668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=o7JlWG6XYdkaBAFGSG9zxhwdVesOImBZsTcn9kxvUXc%3D&reserved=0<https://github.com/coreutils/gnulib/commit/eb6a8a4dfb> (included in coreutils 9.4) https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcoreutils%2Fgnulib%2Fcommit%2F47947855dd&data=05%7C02%7Condrej.valousek.xm%40renesas.com%7C8e88e29999af4effb01c08dcdca53760%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C638627849375114444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=4ykkTYfG%2F3aroM4cmBscOAxpGlYdGbsFv%2BtkcdA5ez8%3D&reserved=0<https://github.com/coreutils/gnulib/commit/47947855dd> (not yet released) cheers, Pádraig
