I have an nfs export: /mnt/Backup Hostname(no_root_squash,ro,mp) It exports this drive, LABEL=Backup /mnt/Backup btrfs noatime,compress-force=zstd:99 I have a locally mounted drive, /mnt/Mirror (LABEL=Mirror /mnt/Mirror btrfs compress-force=zstd:99,noatime,nofail) I mount the nfs share: mount Hostname:/mnt/Backup /mnt/Backup. I cp a file from one to the other, cp -av /mnt/Backup/snaps/elden/90/info.xml /mnt/Mirror/snaps/elden/90/info.xml. Under coreutils-9.1-r2 I get no error. Under coreutils-9.2-r2 I get cp: preserving permissions for ‘/mnt/Mirror/snaps/elden/90/info.xml’: Operation not supported In both cases the resulting copy looks like this: # ls -l /mnt/*/snaps/elden/90/info.xml -rw------- 1 root root 184 Apr 17 10:52 /mnt/Backup/snaps/elden/90/info.xml -rw------- 1 root root 184 Apr 17 10:52 /mnt/Mirror/snaps/elden/90/info.xml I git bisected with coreutils-9999 # first bad commit: [28a85116feef1f9a6f31c5ab8cfe50d7aa8d6fc4] build: update gnulib submodule to latest Thought I'd check it isn't something Gentoo-specific, before I consider upstream. Will attach emerge --info. System is stable keyworded for the most part (first spotted due to stab of 9.3-r1 which also has same issue). Reproducible: Always
Created attachment 863051 [details] emerge info
(In reply to Peter from comment #0) [...] > I git bisected with coreutils-9999 > # first bad commit: [28a85116feef1f9a6f31c5ab8cfe50d7aa8d6fc4] build: update > gnulib submodule to latest > > Thought I'd check it isn't something Gentoo-specific, before I consider > upstream. Thank you for doing the legwork already! I can't think of this being anything on our end. Would you mind reporting it upstream and giving us the link here?
(In reply to Sam James from comment #2) > Thank you for doing the legwork already! I can't think of this being > anything on our end. Would you mind reporting it upstream and giving us the > link here? Of course, Sam, just got the link through now, thanks for looking into it: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63856
Many thanks!
Not fixed in 9.4. :(
(In reply to Holger Hoffstätte from comment #5) > Not fixed in 9.4. :( I'm assuming the RH bug is similar but different given https://bugzilla.redhat.com/show_bug.cgi?id=2160675#c17, or I'm misunderstanding it (it implies 9.4 should be fine...?)
(In reply to Sam James from comment #6) > (In reply to Holger Hoffstätte from comment #5) > > Not fixed in 9.4. :( > > I'm assuming the RH bug is similar but different given > https://bugzilla.redhat.com/show_bug.cgi?id=2160675#c17, or I'm > misunderstanding it (it implies 9.4 should be fine...?) Well, it does not work (I'm back to 9.1). I read the discussion in https://lists.gnu.org/archive/html/bug-gnulib/2023-05/msg00097.html which seems to conclude that it was a kernel bug (or maybe both kernel and coreutils??, and that it should have been fixed in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/xattr.c?id=3a7bb21b6f49b4d1695d4ba8ff31e9619cbcebe3 which is in 6.4, which I'm running. No idea what's going on there, that entire thread is full of confusion.
Would you mind posting an update on the upstream bug?
(In reply to Sam James from comment #8) > Would you mind posting an update on the upstream bug? Done.
So this is a series of unfortunate misunderstandings - please see my comment at https://bugzilla.redhat.com/show_bug.cgi?id=2160675#c25 for details. The gist of it is that the warning is apparently expected when copying from an NFSv4 mount to a non-NFSv4 mount because of the settings in /etc/xattr.conf: # Actions: # permissions - copy when trying to preserve permissions. # skip - do not copy. system.nfs4_acl permissions system.nfs4acl permissions .. This means that cp tries to copy nfsv4 ACLs, which fails when the destination is not NFSv4 as well. The warning goes away - as expected - qhen you copy from NFS to NFS. For people who don't need to preserve NFSv4 ACLs the easiest thing is to set the system.nfsv4* entries to "skip", as described in the comment. I'm not sure what we can or should do here. Maybe they will end up patching the error message out of cp since it's too confusing.
