Nobody:nobody

Home » CentOS » Nobody:nobody
CentOS 7 Comments

Hey Y’all,

For the last week or more I’ve been trying to get NFS and openLDAP to play nice with each other. I’ve pretty much worn the Google machine out trying to find a solution. I’ve found several that said “Solved” but none of those solutions solved my nobody:nobody problem.

In the past I’ve used NFS in conjunction with NIS to share home directories from my NFS server but I read that NIS is deprecated in favor of LDAP so, being a sucker for new ideas, I decided I would use LDAP too like the big boys do. I think I’m regretting this decision. Now the question:

Is there something I need to configure on the client side of the relationship that all the Google wisdom has failed to mention? All the guides/tutorial/etc… talk extensively about configuring the server, many giving conflicting information, but have nothing to say about the client. I’ve even found a couple that talk about configuring CentOS 6
but contain commands found only in CentOS 7. Makes one go hmmm?

Here’s the basic details:
Server:
CentOS 6
openLDAP-2.4.40-16.el6.i686
openLDAP-clients-2.4.40-16.el6.x86_64
perl-LDAP-0.40-3.el6.noarch sssd-ldap-1.13.3-60.el6_10.2.x86_64
openLDAP-2.4.40-16.el6.x86_64
openLDAP-servers-2.4.40-16.el6.x86_64
python-ldap-2.3.10-1.el6.x86_64
apr-util-ldap-1.3.9-3.el6_0.1.x86_64
smbldap-tools-0.9.6-4.el6.noarch nfs-utils-lib-1.1.5-13.el6.x86_64
nfs4-acl-tools-0.3.3-8.el6.x86_64
nfs-utils-1.2.3-78.el6_10.1.x86_64

Client:
CentOS 7 KVM VM running on the server sssd-ldap-1.16.2-13.el7_6.5.x86_64
python-ldap-2.4.15-2.el7.x86_64
openLDAP-2.4.44-21.el7_6.x86_64
nfs4-acl-tools-0.3.3-19.el7.x86_64
nfs-utils-1.3.0-0.61.el7.x86_64
libnfsidmap-0.25-19.el7.x86_64

Both machines are fully updated.

Would you like to see any of the myriad of configuration files for these applications? Just ask and you shall receive. Please be sure to tell me if you want the file from the server or the client hey.


_
°v°
/(_)\
^ ^ Mark LaPierre Registered Linux user No #267004
https://linuxcounter.net/
****

7 thoughts on - Nobody:nobody

  • That is usually caused by idmapd. Make sure that the idmapd is running on both sides and have the identical domain configured.

    Or switch back to NFSv3. This is not so bad if you have (through LDAP)
    the same UIDs on both sides.

    Best regards Ulf

  • Content of idmapd.conf:
    Server:
    [General]
    #Verbosity = 0
    # The following should be set to the local NFSv4 domain name
    # The default is the host’s DNS domain name.
    #Domain = local.domain.edu Domain = peach.patch.mylan

    Client:
    [General]
    #Verbosity = 0
    # The following should be set to the local NFSv4 domain name
    # The default is the host’s DNS domain name.
    #Domain = local.domain.edu Domain = poppy.patch.mylan

    Now one more question. The imap daemon is a mail server. How is it that I need a mail server running to make LDAP and NFS work? Doesn’t seem to make sense to me.


    _
    °v°
    /(_)\
    ^ ^ Mark LaPierre Registered Linux user No #267004
    https://linuxcounter.net/
    ****

  • As long as idmapd is *running* it typically doesn’t need to be configured specifically.

    idmapd is not imapd.  idmapd (aka rpc.idmapd) is a helper for NFSv4
    which should be run on the server.  It shouldn’t be required on the client.

    A couple of points: 1) Your original message isn’t specific about the problem that you’re seeing, but if idmapd is involved, then the problem isn’t related to LDAP.   NFSv4 will work the same way whether you’re using NIS or LDAP.  Pretty much everything other than NSS and PAM will, in fact.  2) I don’t recommend rolling your own LDAP services.  It’s very easy to let sensitive information leak.  Using FreeIPA for LDAP and KRB5 is much easier and a lot more secure.

  • […]

    […]

    That will fail. Set both to patch.mylan.

    We are talking about the idmapd, not imapd. The idmapd will map UIDs between clients and server for NFS.

    Best regards Ulf

  • Thank you for your reply to my incompetent query.

    Okay, I’m a bit dyslectic. I see that I should have seen idmap but I
    saw imap. I missed the “d”. That leads me to another question:

    I don’t see a package that contains idmapd. When I try to install it I get:
    No package idmapd available. No package idmap available.

    I don’t see idmapd in the Service Configuration GUI.

    rpm -qa | grep idmap libsss_idmap-1.13.3-60.el6_10.2.x86_64

    How might one install a daemon by the name idmapd on CentOS 6?


    _
    °v°
    /(_)\
    ^ ^ Mark LaPierre Registered Linux user No #267004
    https://linuxcounter.net/
    ****

  • NFSv4 in RHEL/CentOS 6.x uses libnfsidmap as a sort of add-on module. I
    believe the package you need is nfs-utils-lib.

    [root@x ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.6 (Santiago)
    [root@x ~]# ll /etc/idmapd.conf
    -rw-r–r– 1 root root 3601 Dec 6 2012 /etc/idmapd.conf
    [root@pollux2 ~]# rpm -qf /etc/idmapd.conf nfs-utils-lib-1.1.5-9.el6.x86_64
    [root@x ~]# rpm -ql nfs-utils-lib
    /etc/idmapd.conf
    /usr/lib64/libnfsidmap.so.0
    /usr/lib64/libnfsidmap.so.0.3.0
    /usr/lib64/libnfsidmap/nsswitch.so
    /usr/lib64/libnfsidmap/static.so
    /usr/lib64/libnfsidmap/umich_ldap.so
    /usr/lib64/librpcsecgss.so.3
    /usr/lib64/librpcsecgss.so.3.0.0
    /usr/share/doc/nfs-utils-lib-1.1.5
    /usr/share/doc/nfs-utils-lib-1.1.5/libnfsidmap-0.24
    /usr/share/doc/nfs-utils-lib-1.1.5/libnfsidmap-0.24/AUTHORS
    /usr/share/doc/nfs-utils-lib-1.1.5/libnfsidmap-0.24/ChangeLog
    /usr/share/doc/nfs-utils-lib-1.1.5/libnfsidmap-0.24/NEWS
    /usr/share/doc/nfs-utils-lib-1.1.5/libnfsidmap-0.24/README
    /usr/share/doc/nfs-utils-lib-1.1.5/librpcsecgss-0.18
    /usr/share/doc/nfs-utils-lib-1.1.5/librpcsecgss-0.18/AUTHORS
    /usr/share/doc/nfs-utils-lib-1.1.5/librpcsecgss-0.18/ChangeLog
    /usr/share/doc/nfs-utils-lib-1.1.5/librpcsecgss-0.18/NEWS
    /usr/share/doc/nfs-utils-lib-1.1.5/librpcsecgss-0.18/README
    /usr/share/man/man3/nfs4_uid_to_name.3.gz
    /usr/share/man/man5/idmapd.conf.5.gz

    Regards, Ben

    Benjamin Hauger SysAdmin/CSDC-DMO
    Rm. 94
    x8371