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

[Michael Kofler]

My setup:

Server (Ubuntu 8.04):
  Kerberos server for authentication
  OpenLDAP server for user and group data
  NFS 4 kernel server for home directories

Client (Ubuntu 8.04, 8.10, 9.04 alpha)
  libpam-krb5 for authentication
  libnss-ldap for user and group data
  nfs4 client for home directories

My problem: If I restart both server and client, at the client all nfs4 files/directories are reported to belong to nobody:nogroup

The problem disappears immediately, if I do

  server: killall rpc.idmapd && /usr/sbin/rpc.idmapd

  client: /etc/init.d/nscd restart
    (I removed nscd entirely while I was looking for a solution)

To summarize: the cause of the problem is rpc.idmapd on the server, which for some reasons can't map LDAP user/group names with uids/gids when started. Perhaps libnss-ldap is not yet active? (nfs-common has an order number of 20, slapd 19, so this should be OK.)

My workaround is a small initv script (on the server) with order number 21, which contains

  /usr/bin/killall rpc.idmapd && /usr/sbin/rpc.idmapd

I guess my problem has to do with another problem (slightly different setup, though) reported here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502292
(see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500778)

[Mark Hannon (markhannon)]

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?

[Jeremy Vies (jeremy.vies)]

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

[Mark Hannon (markhannon)]

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.

[Jeremy Vies (jeremy.vies)]

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

[Mark Hannon (markhannon)]

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.

[Launchpad Janitor (janitor)]

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

[Aaron Thomas (athomas-work)]

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.

[Aaron Thomas (athomas-work)]

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.