bug#78328: Copy fails setting system.nfs4_acl extended attribute [cp (GNU coreutils) 9.7.7-6218c]

On 09/05/2025 06:06, Ian Dall wrote:
> Here, /var/tmp is on an nfs4 filesystem and /tmp is a tmpfs filesystem.
> 
>   $ touch /var/tmp/foo
>   $ cp -p /var/tmp/foo /tmp
> 
> cp: preserving permissions for ‘/tmp/foo’: Operation not supported
> 
>    --preserve=mode has the same result
>    --no-preserve=xattr has no effect
> 
> With nfs4 filesystems, files the system.nfs4_acl extended attribute
> is always set, representing at least the traditional user, group and
> mode settings but system.nfs4_acl can not be set on other filesystems.
> 
> The copy_reg() function sets the traditional user, group and mode of
> the destination before trying to copy the acl with
> xcopy_acl(). Including system.nfs4_acl in /etc/xattr.conf has no effect
> as xcopy_acl() does not check /etc/xattr.conf.
> 
> To be clear, the destination file does get its mode set correctly (if
> there are no extra entries in the acl), but cp exits with error status
> even if system.nfs4_acl has never been explicitly set. This breaks
> scripts that check for cp exit status.
> 
> It is not clear exactly what the correct behaviour is since in some
> circumstances it would be important to fail if access control lists
> are not copied successfully. Maybe system.nfs4_acl should be parsed to
> see if there are any additional entries beyond A::OWNER@, A::GROUP@
> and A::EVERYONE@? Or at least provide a way to suppress trying to
> copying acls, perhaps --no-preserve=acl.

This is actually being looked at in:
https://bugzilla.redhat.com/2363149

There is a proposed patch there.

cheers,
Pádraig