rpc.idmapd does not see LDAP users (nfs4 server)

I can confirm this is still an issue with 8.10 server and clients and even Debian clients.

The work-around does not work normally for me in any case, neither does setting Cache=10 for idmapd.conf as suggested in the Debian bug tracker.

Further to the notes above in my case the server is also the slapd server. The server also uses libnss-ldap for name lookups.

I see there is a libnss-ldapd package in universe which is apparently a fork of the original - is that worth a shot?

Hi,

are users not defined in ldap also affected ?

I've some similar bug (except I don't have users managed by ldap) with a server running 8.04 and a client running 9.04.
It seems similar to Debian Bug#468177: nfs-common: idmapd fails mapping if started before server

Hi Jeremy,

The problem is that *all* files/directories on the NFS4 mount are owned by nobody:nogroup.

Regards/Mark

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Jeremy Vies
Sent: Monday, 15 June 2009 5:35 PM
To: <email address hidden>
Subject: [Bug 335858] Re: rpc.idmapd does not see LDAP users (nfs4 server)

Hi,

are users not defined in ldap also affected ?

I've some similar bug (except I don't have users managed by ldap) with a server running 8.04 and a client running 9.04.
It seems similar to Debian Bug#468177: nfs-common: idmapd fails mapping if started before server

--
rpc.idmapd does not see LDAP users (nfs4 server)
https://bugs.launchpad.net/bugs/335858
You received this bug notification because you are a direct subscriber
of the bug.

So the problem seems very similar to mine. If it's really the case, it is
not due to LDAP, but only to NFSV4.

It seems that nfs-kernel-server needs nfs-common to be started. And vice et
versa.
The solution found on Debian bug analysis is to restart nfs-common in
rc.local so idmapd runs correctly, and users are correctly mapped.

2009/6/16 Mark Hannon <email address hidden>

> Hi Jeremy,
>
> The problem is that *all* files/directories on the NFS4 mount are owned
> by nobody:nogroup.
>
> Regards/Mark
>
>
> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On Behalf Of
> Jeremy Vies
> Sent: Monday, 15 June 2009 5:35 PM
> To: <email address hidden>
> Subject: [Bug 335858] Re: rpc.idmapd does not see LDAP users (nfs4 server)
>
> Hi,
>
> are users not defined in ldap also affected ?
>
> I've some similar bug (except I don't have users managed by ldap) with a
> server running 8.04 and a client running 9.04.
> It seems similar to Debian Bug#468177: nfs-common: idmapd fails mapping if
> started before server
>
> --
> rpc.idmapd does not see LDAP users (nfs4 server)
> https://bugs.launchpad.net/bugs/335858
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> --
> rpc.idmapd does not see LDAP users (nfs4 server)
> https://bugs.launchpad.net/bugs/335858
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Theory is where you know everything, but nothing works; practice is where
everything works, but nobody knows why. Here we combine theory with
practice; nothing works and nobody knows why !
A.Einstein

Actually I *think* the problem has more to do with whether the ldap_nss stuff is up and running before nfs.

If you restart nfs-common on a running system then ldap_nss is well and truly running and you should be OK. However at bootup when nfs is first started then this is an issue.

Regards/Mark

PS I reverted to NFS3 mounts to avoid mucking around with this.

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Jeremy Vies
Sent: Tuesday, 16 June 2009 5:23 PM
To: <email address hidden>
Subject: Re: [Bug 335858] Re: rpc.idmapd does not see LDAP users (nfs4 server)

So the problem seems very similar to mine. If it's really the case, it is
not due to LDAP, but only to NFSV4.

It seems that nfs-kernel-server needs nfs-common to be started. And vice et
versa.
The solution found on Debian bug analysis is to restart nfs-common in
rc.local so idmapd runs correctly, and users are correctly mapped.

2009/6/16 Mark Hannon <email address hidden>

> Hi Jeremy,
>
> The problem is that *all* files/directories on the NFS4 mount are owned
> by nobody:nogroup.
>
> Regards/Mark
>
>
> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On Behalf Of
> Jeremy Vies
> Sent: Monday, 15 June 2009 5:35 PM
> To: <email address hidden>
> Subject: [Bug 335858] Re: rpc.idmapd does not see LDAP users (nfs4 server)
>
> Hi,
>
> are users not defined in ldap also affected ?
>
> I've some similar bug (except I don't have users managed by ldap) with a
> server running 8.04 and a client running 9.04.
> It seems similar to Debian Bug#468177: nfs-common: idmapd fails mapping if
> started before server
>
> --
> rpc.idmapd does not see LDAP users (nfs4 server)
> https://bugs.launchpad.net/bugs/335858
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> --
> rpc.idmapd does not see LDAP users (nfs4 server)
> https://bugs.launchpad.net/bugs/335858
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Theory is where you know everything, but nothing works; practice is where
everything works, but nobody knows why. Here we combine theory with
practice; nothing works and nobody knows why !
A.Einstein

--
rpc.idmapd does not see LDAP users (nfs4 server)
https://bugs.launchpad.net/bugs/335858
You received this bug notification because you are a direct subscriber
of the bug.

Status changed to 'Confirmed' because the bug affects multiple users.

I have this problem on every version of ubuntu to date.

My setup are two kinds of systems (we have hundreds of these systems deployed).

If we configure users with nfsv4 on systems with NIS (no kerberos. just a vanilla NIS implementation), idmapd works great.

If we configure machines identically but instead of configuring NIS we configure for our LDAP server. nfsv4 gets uids of 4294967294 . debug output of idmapd shows it idle on the ldap configuration. Meanwhile getent shows all users appropriately and users can log into the server fine.

So, in other words, coming from another angle where kerberos is not configured at all, we get a non-functioning nfs client on LDAP systems. This has been an unsolvable problem peventing us from retiring NIS for LDAP for 5 years.

The previous comparison was to explain that the NFSv4 configurations are (pretty basic) working as expected, as they're identical on both systems, the only change is whether or not the server itself is getting users from LDAP or NIS, and both LDAP and NIS configurations are also working fine, as users can log in. create local files with the correct permissions, enter passwords, etc. The missing part is that idmapd does nothing when the underlying system is using ldap instead of nis or /etc/passwd.