Bug 907710 – >=sys-apps/coreutils-9.2-r2 cp: preserving permissions: Operation not supported when copying from no_root_squash nfs export

• Product: Gentoo Linux
• Status: UNCONFIRMED ---

[Description Peter 2023-06-02 15:20:04 UTC]

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

[Comment 1 Peter 2023-06-02 15:22:47 UTC]

Created attachment 863051 [details]
emerge info

[Comment 2 Sam James 2023-06-02 15:46:28 UTC]

(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?

[Comment 3 Peter 2023-06-02 18:02:29 UTC]

(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

[Comment 4 Sam James 2023-06-03 01:07:37 UTC]

Many thanks!

[Comment 5 Holger Hoffstätte 2023-08-29 19:33:33 UTC]

Not fixed in 9.4. :(

[Comment 6 Sam James 2023-08-29 19:35:25 UTC]

(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...?)

[Comment 7 Holger Hoffstätte 2023-08-29 20:04:06 UTC]

(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.

[Comment 8 Sam James 2023-08-31 07:54:51 UTC]

Would you mind posting an update on the upstream bug?

[Comment 9 Holger Hoffstätte 2023-08-31 08:40:30 UTC]

(In reply to Sam James from comment #8)
> Would you mind posting an update on the upstream bug?

Done.

[Comment 10 Holger Hoffstätte 2023-08-31 18:13:52 UTC]

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.