fattr4_hidden and fattr4_system r/w attributes in Linux NFSD?

fattr4_hidden and fattr4_system r/w attributes in Linux NFSD?

[Sebastian Feld]

I've been debating with Opentext support about their Windows NFS4.0
client about a problem that the Windows attributes HIDDEN and SYSTEM
work with a Solaris NFSD, but not with a Linux NFSD.

Their support said it's a known bug in LInux NFSD that "fattr4_hidden
and fattr4_system, specified in RFC 3530, are broken in Linux NFSD".

Is there a fix, or workaround?

Sebi
-- 
Sebastian Feld - IT security consultant

Re: fattr4_hidden and fattr4_system r/w attributes in Linux NFSD?

[Chuck Lever]

Hi Sebastian -

On 4/28/25 7:06 AM, Sebastian Feld wrote:
> I've been debating with Opentext support about their Windows NFS4.0
> client about a problem that the Windows attributes HIDDEN and SYSTEM
> work with a Solaris NFSD, but not with a Linux NFSD.
> 
> Their support said it's a known bug in LInux NFSD that "fattr4_hidden
> and fattr4_system, specified in RFC 3530, are broken in Linux NFSD".

RFC 7530 updates and replaces RFC 3530.

Section 5.7 lists "hidden" and "system" as RECOMMENDED attributes,
meaning that NFSv4 servers are not required to implement them.

So that tells me that both the Solaris NFS server and the Linux NFS
server are spec compliant in this regard. This is NOTABUG, but rather it
is a server implementation choice that is permitted by RFC.

It is more correct to say that the Linux NFS server does not currently
implement either of these attributes. The reason is that native Linux
file systems do not support these attributes, and I believe that neither
does the Linux VFS. So there is nowhere to store these, and no way to
access them in filesystems (such as the Linux port of NTFS) that do
implement them.

We want to have a facility that can be used by native applications
(such as Wine), Samba, and NFSD. So implementing side-car storage
for such attributes that only NFSD can see and use is not really
desirable.


> Is there a fix, or workaround?

There was recent discussion on linux-fsdevel@ about how the community
might introduce support for attributes that Windows has but POSIX does
not [1]. I'm not sure how far along that got, but there does seem to
be some interest in getting Linux native file systems (and the VFS) to
be able to store and access the attributes. Once that is available, then
it should be straightforward to add such support to NFSD.

Until then, I am not aware of a workaround.


-- 
Chuck Lever

[1]
https://lore.kernel.org/linux-fsdevel/20241227121508.nofy6bho66pc5ry5@pali/

Re: fattr4_hidden and fattr4_system r/w attributes in Linux NFSD?

[Sebastian Feld]

On Mon, Apr 28, 2025 at 4:15 PM Chuck Lever <chuck.lever@oracle.com> wrote:
>
> Hi Sebastian -
>
> On 4/28/25 7:06 AM, Sebastian Feld wrote:
> > I've been debating with Opentext support about their Windows NFS4.0
> > client about a problem that the Windows attributes HIDDEN and SYSTEM
> > work with a Solaris NFSD, but not with a Linux NFSD.
> >
> > Their support said it's a known bug in LInux NFSD that "fattr4_hidden
> > and fattr4_system, specified in RFC 3530, are broken in Linux NFSD".
>
> RFC 7530 updates and replaces RFC 3530.
>
> Section 5.7 lists "hidden" and "system" as RECOMMENDED attributes,
> meaning that NFSv4 servers are not required to implement them.
>
> So that tells me that both the Solaris NFS server and the Linux NFS
> server are spec compliant in this regard. This is NOTABUG, but rather it
> is a server implementation choice that is permitted by RFC.
>
> It is more correct to say that the Linux NFS server does not currently
> implement either of these attributes. The reason is that native Linux
> file systems do not support these attributes, and I believe that neither
> does the Linux VFS. So there is nowhere to store these, and no way to
> access them in filesystems (such as the Linux port of NTFS) that do
> implement them.
>
> We want to have a facility that can be used by native applications
> (such as Wine), Samba, and NFSD. So implementing side-car storage
> for such attributes that only NFSD can see and use is not really
> desirable.

I did a bit of digging, that debate started in 2002.

23 years later, nothing happened. No Solution.
Very depressing.

Sebi
-- 
Sebastian Feld - IT security consultant

Re: fattr4_hidden and fattr4_system r/w attributes in Linux NFSD?

[Chuck Lever]

On 4/29/25 9:10 AM, Sebastian Feld wrote:
> On Mon, Apr 28, 2025 at 4:15 PM Chuck Lever <chuck.lever@oracle.com> wrote:
>>
>> Hi Sebastian -
>>
>> On 4/28/25 7:06 AM, Sebastian Feld wrote:
>>> I've been debating with Opentext support about their Windows NFS4.0
>>> client about a problem that the Windows attributes HIDDEN and SYSTEM
>>> work with a Solaris NFSD, but not with a Linux NFSD.
>>>
>>> Their support said it's a known bug in LInux NFSD that "fattr4_hidden
>>> and fattr4_system, specified in RFC 3530, are broken in Linux NFSD".
>>
>> RFC 7530 updates and replaces RFC 3530.
>>
>> Section 5.7 lists "hidden" and "system" as RECOMMENDED attributes,
>> meaning that NFSv4 servers are not required to implement them.
>>
>> So that tells me that both the Solaris NFS server and the Linux NFS
>> server are spec compliant in this regard. This is NOTABUG, but rather it
>> is a server implementation choice that is permitted by RFC.
>>
>> It is more correct to say that the Linux NFS server does not currently
>> implement either of these attributes. The reason is that native Linux
>> file systems do not support these attributes, and I believe that neither
>> does the Linux VFS. So there is nowhere to store these, and no way to
>> access them in filesystems (such as the Linux port of NTFS) that do
>> implement them.
>>
>> We want to have a facility that can be used by native applications
>> (such as Wine), Samba, and NFSD. So implementing side-car storage
>> for such attributes that only NFSD can see and use is not really
>> desirable.
> 
> I did a bit of digging, that debate started in 2002.
> 
> 23 years later, nothing happened. No Solution.
> Very depressing.

It's a hard problem.

Focus on the recent work. It appears to be promising and there have
been few objections to it.


-- 
Chuck Lever

Re: fattr4_hidden and fattr4_system r/w attributes in Linux NFSD?

[Sebastian Feld]

On Tue, Apr 29, 2025 at 3:45 PM Chuck Lever <chuck.lever@oracle.com> wrote:
>
> On 4/29/25 9:10 AM, Sebastian Feld wrote:
> > On Mon, Apr 28, 2025 at 4:15 PM Chuck Lever <chuck.lever@oracle.com> wrote:
> >>
> >> Hi Sebastian -
> >>
> >> On 4/28/25 7:06 AM, Sebastian Feld wrote:
> >>> I've been debating with Opentext support about their Windows NFS4.0
> >>> client about a problem that the Windows attributes HIDDEN and SYSTEM
> >>> work with a Solaris NFSD, but not with a Linux NFSD.
> >>>
> >>> Their support said it's a known bug in LInux NFSD that "fattr4_hidden
> >>> and fattr4_system, specified in RFC 3530, are broken in Linux NFSD".
> >>
> >> RFC 7530 updates and replaces RFC 3530.
> >>
> >> Section 5.7 lists "hidden" and "system" as RECOMMENDED attributes,
> >> meaning that NFSv4 servers are not required to implement them.
> >>
> >> So that tells me that both the Solaris NFS server and the Linux NFS
> >> server are spec compliant in this regard. This is NOTABUG, but rather it
> >> is a server implementation choice that is permitted by RFC.
> >>
> >> It is more correct to say that the Linux NFS server does not currently
> >> implement either of these attributes. The reason is that native Linux
> >> file systems do not support these attributes, and I believe that neither
> >> does the Linux VFS. So there is nowhere to store these, and no way to
> >> access them in filesystems (such as the Linux port of NTFS) that do
> >> implement them.
> >>
> >> We want to have a facility that can be used by native applications
> >> (such as Wine), Samba, and NFSD. So implementing side-car storage
> >> for such attributes that only NFSD can see and use is not really
> >> desirable.
> >
> > I did a bit of digging, that debate started in 2002.
> >
> > 23 years later, nothing happened. No Solution.
> > Very depressing.
>
> It's a hard problem.
>
> Focus on the recent work. It appears to be promising and there have
> been few objections to it.

Do you have any reference to that work? Are there status updates?

Sebi
-- 
Sebastian Feld - IT security consultant