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.
Looks like this is not only either back/still a problem in 9.6, it got worse since the /etc/xattr workaround (#10) no longer works either. Copying from NFSv4 to local XFS: holger>cp -a /Developer/Source/Java/h2o-playground/pom.xml . cp: preserving permissions for ‘./pom.xml’: Operation not supported holger>strace cp -a /Developer/Source/Java/h2o-playground/pom.xml . execve("/bin/cp", ["cp", "-a", "/Developer/Source/Java/h2o-playg"..., "."], 0x7fff0eca4028 /* 76 vars */) = 0 brk(NULL) = 0x560c19e68000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb04c091000 mprotect(0x7fb04c091000, 4096, PROT_READ|PROT_EXEC) = 0 munmap(0x7fb04c091000, 4096) = 0 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=108582, ...}) = 0 mmap(NULL, 108582, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb04c077000 close(3) = 0 openat(AT_FDCWD, "/usr/lib64/libacl.so.1", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=38768, ...}) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb04c075000 mmap(NULL, 41008, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb04c06a000 mmap(0x7fb04c06c000, 20480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fb04c06c000 mmap(0x7fb04c071000, 8192, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7fb04c071000 mmap(0x7fb04c073000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0x7fb04c073000 close(3) = 0 openat(AT_FDCWD, "/usr/lib64/libattr.so.1", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=26480, ...}) = 0 mmap(NULL, 28696, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb04c062000 mmap(0x7fb04c064000, 12288, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fb04c064000 mmap(0x7fb04c067000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5000) = 0x7fb04c067000 mmap(0x7fb04c068000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5000) = 0x7fb04c068000 close(3) = 0 openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360a\2\0\0\0\0\0"..., 832) = 832 pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784 fstat(3, {st_mode=S_IFREG|0755, st_size=2389384, ...}) = 0 pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784 mmap(NULL, 2051544, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb04be6d000 mmap(0x7fb04be91000, 1478656, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x24000) = 0x7fb04be91000 mmap(0x7fb04bffa000, 348160, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18d000) = 0x7fb04bffa000 mmap(0x7fb04c04f000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e1000) = 0x7fb04c04f000 mmap(0x7fb04c055000, 52696, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb04c055000 close(3) = 0 mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb04be6a000 arch_prctl(ARCH_SET_FS, 0x7fb04be6a740) = 0 set_tid_address(0x7fb04be6aa10) = 26586 set_robust_list(0x7fb04be6aa20, 24) = 0 rseq(0x7fb04be6b060, 0x20, 0, 0x53053053) = 0 mprotect(0x7fb04be91000, 1008, PROT_READ|PROT_WRITE) = 0 mprotect(0x7fb04be91000, 1008, PROT_READ|PROT_EXEC) = 0 mprotect(0x7fb04c04f000, 16384, PROT_READ) = 0 mprotect(0x7fb04c068000, 4096, PROT_READ) = 0 mprotect(0x7fb04c073000, 4096, PROT_READ) = 0 mprotect(0x560c04ac9000, 4096, PROT_READ) = 0 mprotect(0x7fb04c0cc000, 8192, PROT_READ) = 0 prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 munmap(0x7fb04c077000, 108582) = 0 getrandom("\xf9\x9c\x06\xfd\xbb\xa1\x63\x5a", 8, GRND_NONBLOCK) = 8 brk(NULL) = 0x560c19e68000 brk(0x560c19f69000) = 0x560c19f69000 openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=4405664, ...}) = 0 mmap(NULL, 4405664, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb04ba00000 close(3) = 0 geteuid() = 1000 newfstatat(AT_FDCWD, "/Developer/Source/Java/h2o-playground/pom.xml", {st_mode=S_IFREG|0644, st_size=6124, ...}, AT_SYMLINK_NOFOLLOW) = 0 newfstatat(AT_FDCWD, "pom.xml", {st_mode=S_IFREG|0644, st_size=6124, ...}, 0) = 0 openat(AT_FDCWD, "/Developer/Source/Java/h2o-playground/pom.xml", O_RDONLY|O_NOFOLLOW) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=6124, ...}) = 0 openat(AT_FDCWD, "pom.xml", O_WRONLY|O_TRUNC) = 4 ioctl(4, BTRFS_IOC_CLONE or FICLONE, 3) = -1 EXDEV (Invalid cross-device link) fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0 uname({sysname="Linux", nodename="ragnarok", ...}) = 0 copy_file_range(3, NULL, 4, NULL, 9223372035781033984, 0) = -1 EXDEV (Invalid cross-device link) mmap(NULL, 1056768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb04b8fe000 read(3, "<?xml version=\"1.0\"?>\n<project x"..., 1048576) = 6124 write(4, "<?xml version=\"1.0\"?>\n<project x"..., 6124) = 6124 read(3, "", 1048576) = 0 utimensat(4, NULL, [{tv_sec=1687727633, tv_nsec=319570991} /* 2023-06-25T23:13:53.319570991+0200 */, {tv_sec=1736986108, tv_nsec=570320720} /* 2025-01-16T01:08:28.570320720+0100 */], 0) = 0 flistxattr(3, NULL, 0) = 16 flistxattr(3, "system.nfs4_acl\0", 16) = 16 openat(AT_FDCWD, "/etc/xattr.conf", O_RDONLY) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=653, ...}) = 0 read(5, "# /etc/xattr.conf\n#\n# Format:\n# "..., 4096) = 653 read(5, "", 4096) = 0 close(5) = 0 openat(AT_FDCWD, "/usr/lib64/gconv/gconv-modules.cache", O_RDONLY|O_CLOEXEC) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=27012, ...}) = 0 mmap(NULL, 27012, PROT_READ, MAP_SHARED, 5, 0) = 0x7fb04c08b000 close(5) = 0 futex(0x7fb04c05472c, FUTEX_WAKE_PRIVATE, 2147483647) = 0 fchmod(4, 0100644) = 0 flistxattr(3, NULL, 0) = 16 flistxattr(3, "system.nfs4_acl\0", 16) = 16 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\26\1\207\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\26\1\207\0\0\0\6OWNER@\0\0\0\0\0", 80, 0) = -1 EOPNOTSUPP (Operation not supported) fcntl(1, F_GETFL) = 0x80002 (flags O_RDWR|O_CLOEXEC) write(2, "cp: ", 4cp: ) = 4 write(2, "preserving permissions for \342\200\230./"..., 42preserving permissions for ‘./pom.xml’) = 42 write(2, ": Operation not supported", 25: Operation not supported) = 25 write(2, "\n", 1 ) = 1 close(4) = 0 close(3) = 0 munmap(0x7fb04b8fe000, 1056768) = 0 lseek(0, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) close(0) = 0 close(1) = 0 close(2) = 0 exit_group(1) = ? +++ exited with 1 +++ NFS to NFS or without -a works fine.
I managed to track the latest breakage in 9.6 to this commit in gnulib (sorry for the GH link but GNU git/cgit is constantly timing out/aborting): https://github.com/coreutils/gnulib/commit/47947855dda53fd12bbae2a0fccecb2280577a60 Reverting that makes 9.6 cp observe the /etc/xattr.conf settings again.
