> On Nov 20, 2023, at 6:46 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Sun, 2023-11-19 at 17:51 +0100, Cedric Blancher wrote: >> On Sat, 18 Nov 2023 at 12:56, Jeff Layton <jlayton@xxxxxxxxxx> wrote: >>> >>> On Sat, 2023-11-18 at 07:24 +0100, Cedric Blancher wrote: >>>> Good morning! >>>> >>>> NFSv4 has a "hidden" filesystem object attribute. How can I set that >>>> on a Linux NFSv4 server, or in a filesystem exported on Linux via >>>> NFSv4, so that the NFSv4 client gets this attribute for a file? >>>> >>> >>> You can't. RFC 8881 defines that as "TRUE, if the file is considered >>> hidden with respect to the Windows API." There is no analogous Linux >>> inode attribute. >> >> Can we use setfattr and getfattr to set/get the NFSv4.1 HIDDEN and >> ARCHIVE? We have Windows NFSv4 clients (and kofemann/Roland's codebase >> supports this), and that means we need to be able to set/get and >> backup/restore these flags on the NFSv4 server side. >> > > No. They would need to be stored in the inode on the server somehow and > there is no place to store them. These attributes are simply not > supported by the Linux NFS server. To be clear: these attributes are not supported within the Linux filesystems themselves. NFSD could of course handle these attributes, but there is simply no mechanism to make them persistent on Linux filesystems. NTFS might be an exception to that, but I believe Linux does not allow mounted NTFS filesystems to be modified. So again, no way to make those attributes persistent. But I do wonder how Samba on Linux handles these guys. NFSD should do something that doesn't conflict with that. -- Chuck Lever