On Thu, Sep 11, 2025 at 1:08 AM Cedric Blancher
<cedric.blancher@xxxxxxxxx> wrote:
>
> CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@xxxxxxxxxxx.
>
> On Wed, 10 Sept 2025 at 15:38, Rick Macklem <rick.macklem@xxxxxxxxx> wrote:
> >
> > On Wed, Sep 10, 2025 at 3:47 AM Roland Mainz <roland.mainz@xxxxxxxxxxx> wrote:
> > >
> > > On Tue, Sep 9, 2025 at 9:32 PM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
> > > >
> > > > On 9/9/25 12:33 PM, Cedric Blancher wrote:
> > > > > On Tue, 9 Sept 2025 at 18:12, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
> > > > >>
> > > > >> On 9/9/25 12:06 PM, Cedric Blancher wrote:
> > > > >>> Due lack of a VFS interface and the urgend use case of needing to
> > > > >>> export a case-insensitive filesystem via NFSv4.x, could we please get
> > > > >>> two /etc/exports options, one setting the case-insensitive boolean
> > > > >>> (true, false, get-default-from-fs) and one for case-preserving (true,
> > > > >>> false, get-default-from-fs)?
> > > > >>>
> > > > >>> So far LInux nfsd does the WRONG thing here, and exports even
> > > > >>> case-insensitive filesystems as case-sensitive. The Windows NFSv4.1
> > > > >>> server does it correctly.
> > > >
> > > > As always, I encourage you to, first, prototype in NFSD the hard-coding
> > > > of these settings as returned to NFS clients to see if that does what
> > > > you really need with Linux-native file systems.
> > >
> > > If Cedric wants just case-insensitive mounts for a Windows NFSv4
> > > (Exceed, OpenText, ms-nfs41-client, ms-nfs42-client, ...), then the
> > > only thing needed is ext4fs or NTFS in case-insensitive mode, and that
> > > the Linux NFSv4.1 server sets FATTR4_WORD0_CASE_INSENSITIVE==true and
> > > FATTR4_WORD0_CASE_PRESERVING==true (for FAT
> > > FATTR4_WORD0_CASE_PRESERVING==false). Only applications using ADS
> > > (Alternate Data Streams) will not work, because the Linux NFS server
> > > does not support "OPENATTR"&co ops.
> > >
> > > If Cedric wants Windows home dirs:
> > > This is not working with the Linux NFSv4.1 server, because it must support:
> > > - FATTR4_WORD1_SYSTEM
> > > - FATTR4_WORD0_ARCHIVE
> > > - FATTR4_WORD0_HIDDEN
> > > - Full ACL support, the current draft POSIX-ACLs in Linux NFSv4.1
> > > server&&{ ext4fs, btrfs, xfs etc. } causes malfunctions in the Windows
> > > "New User" profile setup (and gets you a temporary profile in
> > > C:\Users\*.temp+lots of warnings and a note to log out immediately
> > > because your user profile dir has been "corrupted")
> > >
> > > Windows home dirs with NFSv4 only work so far with the
> > > Solaris&&Illumos NFS servers, and maybe the FreeBSD >= 14 NFS server
> > > (not tested yet).
> > I'll just note that the named attribute support (the windows client
> > folk like the name)
> > along with Hidden and System are in 15 only.
> > And Archive is not supported because it is listed as "deprecated" in the RFC.
> > (If this case really needs it, someone should try to get it "undeprecated" on
> > nfsv4@xxxxxxxx. I could add Archive easily. All of these are for ZFS only.
> > ZFS also knows case insensitive, although I have not tried it.)
>
> Who (name!) had the idea to declare fattr4_archive as "deprecated"? It
> was explicitly added for Windows and DOS compatibility in NFSv4, and
> unlike Windows EAs (which are depreciated, and were superseded by
> "named streams") the "archive" attribute is still in use.
I have no idea who would have done this, but here is the snippet from
RFC5661 (which started being edited in 2005 and was published in 2010,
so it has been like this for a long time). The same words are in RFC8881
and currently in the RFC8881bis draft. Can this be changed?
I'd say yes, but it will take time and effort on someone's part.
Posting to nfsv4@xxxxxxxx, noting that this attribute is needed
by the Windows client (and at least a suggestion that time_backup
is not a satisfactory replacement) would be a good start.
5.8.2.1. Attribute 14: archive
TRUE, if this file has been archived since the time of last
modification (deprecated in favor of time_backup).
The problem has been a serious lack of Windows expertise in the NFSv4
working group. Long ago (20+ years) the Hummingbird developers were
actively involved (Hummingbird became Open Network Solutions, which
became a division of OpenText, if I recall it correctly).
But there has been no one with Windows expertise involved more recently.
My suggestion (I'll repeat it) is to have someone participate in the Bakeathon
testing events (the next one is in about one month and can be attended
remotely using a tailscale VPN). When someone tests at the event and
finds an issue, the server developers are there and can discussion what
it takes to fix it.
Also, participation on the nfsv4@xxxxxxxx mailing list (some working group
members will not be reading this Linux list) and attendance at working
group meetings would help. (The working group meetings can
also be attended remotely and there is an automatic fee waiver for
remote attendance if you, like me, are not funded to do the work.)
With no involvement from people with Windows expertise, the testing
has become basically a bunch of servers being tested against by
various versions of the Linux client (with me being at outlier, testing
the FreeBSD client).
rick
>
> Ced
> --
> Cedric Blancher <cedric.blancher@xxxxxxxxx>
> [https://plus.google.com/u/0/+CedricBlancher/]
> Institute Pasteur
>
