While mounting overlayfs with NFS as a lower directory and a local filesystem as an upper layer leads to copy_up failures because NFS4 has an extra system.nfs4_acl which cannot be copied up. This has been discussed before [1] and [2] with the suggestion that nfs4_acl is derived from posix_acls or just inode->i_mode *most* of the times and hence it can be mapped back. The problem is NFS client knows nothing about nfs4_acl and it is decoded in nfs4-acl-tools. Even if we make nfs client capable of understand nfs4_acl xattr, can it be used to perform ACL's for the system. AFAIU, it is uses user/group names as opposed uid/gid to perform id mapping. Can the client map it back to user names and derive if it is just an replica of inode's i_mode? The idea is to suppress nfs4_acl if it is the same as inode's i_mode. This means nfs4-acl-tools/nfs4_getacl would give no results when requesting for ACLs. This would break existing applications if they expect some output from nfs4_getfacl. Is there a better way to identify if nfs4_acl is just a representation of i_mode at the client end and can be safely ignored during an overlayfs copy_up? Can we include a flag for this? [1] https://www.spinics.net/lists/linux-nfs/msg61045.html [2] https://www.spinics.net/lists/linux-unionfs/msg04736.html -- Goldwyn -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
