[Bug 335858] Re: rpc.idmapd does not see LDAP users (nfs4 server)

[aaron thomas]

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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to nfs-utils in Ubuntu.
https://bugs.launchpad.net/bugs/335858

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

Status in “nfs-utils” package in Ubuntu:
  Confirmed

Bug description:
  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)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/335858/+subscriptions