Re: nfsv4 and rpcidmapd

Tue, 30 Jun 2015 18:06:56 -0700

If your using kerberos‎ then there may be some other issues.
1) make sure that the default realm is set correctly in /etc/krb5.conf on all servers.
2) make sure that all the processes have access to keytab files readable by the user the service is running as, and that it contains the key for the principal for that service. If not then user key forwarding for the users pricipal won't work correctly‎.

From: Patrick J. LoPresti
Sent: Tuesday, June 30, 2015 17:17
To: Orion Poplawski
Cc: Eve V. E. Kovacs; [email protected]
Subject: Re: nfsv4 and rpcidmapd

Possibly related:


Assuming you are using FQDNs and the host's domain matches the Kerberos domain, it sounds like you can simply comment out the "Domain = " line in idmapd.conf.

(I vaguely recall "localdomain" having special meaning in this context and therefore being a bad idea. I always set it to something else. But I am unable to find a reference, so maybe my memory is playing tricks on me.)

 - Pat


On Tue, Jun 30, 2015 at 1:47 PM, Orion Poplawski <[email protected]> wrote:
On 06/30/2015 02:39 PM, Eve V. E. Kovacs wrote:
> Yes, kereberos is used for password authentication; account information is
> supplied by our ldap server. Passwords are not served via ldap.
> Eve
>

Perhaps something in that configuration is forcing the full domain to get
sent.  Not sure.  idmap issues always give me headaches.

> On Tue, 30 Jun 2015, Orion Poplawski wrote:
>
>> Date: Tue, 30 Jun 2015 15:30:41 -0500
>> From: Orion Poplawski <[email protected]>
>> To: Eve V. E. Kovacs <[email protected]>, [email protected]
>> Subject: Re: nfsv4 and rpcidmapd
>>
>> On 06/30/2015 01:46 PM, Eve V. E. Kovacs wrote:
>>> We have an SL6 nfsv4 file server and a number of SL6 clients.
>>> We were careful to configure idmapd.conf on both the clients and the server to
>>> have the same domain name as follows:
>>>
>>> # 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 = localdomain
>>>
>>> All of this worked until recently.
>>>
>>> Now, when I try to change the ownership of my file 'test' on one of the
>>> clients, I get an error:
>>> chown: changing ownership of test : Invalid argument
>>>
>>> On the server, I see errors in the log file:
>>>  rpc.idmapd[6092]: nss_getpwnam: name '[email protected]' does not map into
>>> domain 'localdomain'
>>>
>>> This problem has various solutions posted on the internet. Some solutions
>>> claim that all that is required is to have the same domain name on the client
>>> and server. We already have this, but still have a problem. Another solution
>>> suggests changing the local NFSv4 domain name to match the DNS domain name
>>> (which looks promising, given the error message above).
>>>
>>> Has anyone else had this problem and/or know the fix?
>>
>> I would definitely recommend using the real domain name, but it does seem like
>> the client is sending the "hep.anl.gov" domain name rather than "localdomain",
>> and I'm not sure why that would be if it is configured as you described.
>> Either way *should* work.  Is kerberos involved at all?
>>
>>
>> --
>> Orion Poplawski
>> Technical Manager                     303-415-9701 x222
>> NWRA, Boulder/CoRA Office             FAX: 303-415-9702
>> 3380 Mitchell Lane                       [email protected]
>> Boulder, CO 80301                   http://www.nwra.com
>>
>
> ***************************************************************
> Eve Kovacs
> Argonne National Laboratory,
> Room L-177, Bldg. 360, HEP
> 9700 S. Cass Ave.
> Argonne, IL 60439 USA
> Phone: (630)-252-6208
> Fax:   (630)-252-5047
> email: [email protected]
> ***************************************************************


--
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       [email protected]
Boulder, CO 80301                   http://www.nwra.com


Reply via email to