[Ms-nfs41-client-devel] [PATCH/RFC] Patch to fix uid/gid lookup for NFSv4 filesystems

[Roland Mainz]

On Sun, Aug 23, 2026 at 4:38 PM Dan Shelton <dan.f.shelton@gmail.com> wrote:
>
> On Fri, 21 Aug 2026 at 17:21, Lionel Cons <lionelcons1972@gmail.com> wrote:
> >
> > On Sun, 16 Aug 2026 at 19:35, Lionel Cons <lionelcons1972@gmail.com> wrote:
> > >
> > > Repost with proper [PATCH/RFC] tag.
> > >
> > > I've attached a patch
> > > (cygwin_dll_fix_uidgid4nfsv4_fs_20260709.diff.txt from the
> > > ms-nfs41-client project) that resolves an issue with uid/gid lookups
> > > on Windows NFSv4 filesystems.
> > >
> > > Currently, Cygwin assumes that all Windows NFS clients operate
> > > similarly to the Windows NFSv3 client. It expects that account names
> > > and numeric uid/gid values are identical on both the client and server
> > > sides, with LDAP acting as the sole authority for these numeric
> > > values.
> > >
> > > However, the NFSv4 protocol fundamentally changes this paradigm. As
> > > defined in RFC 7530 (Section 5.9) and expanded upon in RFC 8178 (Rules
> > > for NFSv4 Domain and ID Mapping), NFSv4 deprecates raw numeric uid/gid
> > > protocol representation in favor of string-based identifiers (e.g.,
> > > user@domain and group@domain).
> > >
> > > To handle this, all NFSv4 clients implement a local "idmapper"
> > > component that translates these string-based identities from the
> > > network side into local account data (in the case of Windows, mapping
> > > user/group names and uid/gid values via nfs3attr XATTR). Because NFSv4
> > > clients manage their own uid/gid translation locally, Cygwin's
> > > reliance on raw LDAP data fails in these environments and results in
> > > the dreaded "Unix_User+<1234>" and "Unix_Group+<5678>"-kind of
> > > owner/group output in Cygwin ls -l.
> > >
> > > The attached patch addresses this by detecting whether the underlying
> > > filesystem is NFSv4. If it is, Cygwin bypasses the LDAP assumption and
> > > performs a direct pass-through of the uid/gid values supplied by the
> > > NFSv4 client's idmapper.
> > >
> > > I have successfully tested this fix against several major clients, including:
> > > - Exceed NFSv4 client
> > > - OpenText NFSv4 client
> > > - ms-nfs41-client
> > > - ms-nfs42-client
> > > - Windows NFSv3 client (no change, it continues to use LDAP raw data)
> > >
> > > Please let me know if you have any questions or require modifications
> > > to the patch.
>
> This is the same patch as
> https://github.com/kofemann/ms-nfs41-client/blob/master/cygwin/cygwin_patches/cygwin_dll_fix_uidgid4nfsv4_fs_20260709.diff
> right? Who did auhor it - Roland Mainz or someone else? Why was that
> patch not submitted before?

That's my patch. The issue is that - while this patch is ready (and in
use by CERN&co) - I wanted to do more, but didn't had time to catch
Corinna for further debates.

The ToDo-List:
1. get this patch into Cygwin
2. Add another set of methods to delect |is_nfs()|, |is_nfs3()|,
vis_nfs4()|, |is_msnfs3()|:
- |is_nfs()| is to detect all NFS filesystems, and enable the use of
ServicesForUNIX-style attributes to lookup uid/gid/etc. and NFS-style
symlinks/etc.
- |is_nfs3() to detect NFSv3 filesystems, where uid/gid<-->name lookup
can go directly through LDAP
- |is_nfs4()| to detect NFSv4.x-filesystems, where uid/gid should be
treated-as-is (no LDAP) ... that's
"cygwin_dll_fix_uidgid4nfsv4_fs_20260709.diff.txt"
- |is_msnfs3()| to detect specifically the Microsoft NFSv3 filesystem
driver, because over many many years lots of workarounds were added
for bugs in this driver, which are not appliciable for the other NFS
filesystem drivers

IMO "cygwin_dll_fix_uidgid4nfsv4_fs_20260709.diff.txt" patch can go
into Cygwin right now, it works with Microsoft NFSv3, Hummingbird
NFSv4 and ms-nfs41-client/ms-nfs42-client ...

@Takashi Yano What do you think ?

----

Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)