# idmapd.conf unable to read its own configuration

## mounty1

```
[...]

Verbosity = 3

[...]

Domain = landy.net

[...]
```

but

```
rpc.idmapd: libnfsidmap: Unable to determine the NFSv4 domain; Using 'localdomain' as the NFSv4 domain which means UIDs will be mapped to the 'Nobody-User' user defined in /etc/idmapd.conf
```

and I've tried NFSDomain, NFSV4Domainname etc.  Why doesn't rpc.idmapd pick up the right domain name ?

----------

## truc

The domain may need to be quoted?

----------

## mounty1

I did try it, but no.  None of the other strings in the file are quoted.

The file is being read, as it picks up the settings for Nobody-User and Nobody-Group.

This is getting ridiculous.  Just where do you set the domain name in Gentoo ?  Neither the dns_domain_lo setting in /etc/conf.d/net nor the contents of /etc/defaultdomain have any effect.  The domain name is still (none), after a reboot.

----------

## hasues

I think the domain setting it is referring to is in /etc/resolv.conf.  I know that Solaris and Gentoo both will use the domain setting in that file if you do not have one set for NFS.  Can you paste your config files?

----------

## mounty1

```
# Generated by net-scripts for interface lo

domain landy.net
```

```
127.0.0.1       localhost localhost.landy.net

::1     localhost6.localdomain6 localhost6

::1             localhost

192.168.1.1     cortex  cranium loghost cortex.landy.net

192.168.1.2     services

192.168.1.3     people

192.168.1.58    dickless dickless.landy.net
```

```
[General]

Verbosity = 9

Domain = "landy.net"

[Mapping]

Nobody-User = mounty

Nobody-Group = users

[Translation]

[Static]

[UMICH_SCHEMA]

LDAP_server = ldap-server.local.domain.edu

LDAP_base = dc=local,dc=domain,dc=edu
```

```
NFS_NEEDED_SERVICES="rpc.idmapd"

OPTS_RPC_NFSD="8"

OPTS_RPC_MOUNTD=""

OPTS_RPC_STATD=""

OPTS_RPC_IDMAPD=""

OPTS_RPC_GSSD=""

OPTS_RPC_SVCGSSD=""

OPTS_RPC_RQUOTAD=""

EXPORTFS_TIMEOUT=30
```

```
config_eth0="noop"

modules="wpa_supplicant"

config_wlan0="dhcp"

wpa_supplicant_wlan0=""

wpa_timeout_wlan0=15

key_PericaNet="***********"

key_BTHomeHub_1EE0="**********"

key_Brettster="*********"

key_BigPond49DB="***********"
```

----------

## hasues

For catch up, I think we should mention that the NFS Server is Solaris 10.  And the /etc/default/nfs file should be posted...

So, can you post what the Solaris 10 host thinks the DNS name is and what Gentoo thinks its DNS name is?  Granted, this shouldn't matter because of the NFSMAPID_DOMAIN option (please post for other users) is set in /etc/default/nfs, so I wonder if there is a similar option in NFS in Linux.  I'll have to look this up.

----------

## mounty1

```
NFSD_LISTEN_BACKLOG=32

NFSD_PROTOCOL=ALL

NFSD_SERVERS=16

LOCKD_LISTEN_BACKLOG=32

LOCKD_SERVERS=20

LOCKD_RETRANSMIT_TIMEOUT=5

GRACE_PERIOD=90

NFSMAPID_DOMAIN=landy.net
```

The Solaris cat /var/run/nfs4_domain command reports landy.net.  The Gentoo domainname command reports (none).  But this is not necessarily the NFS domain name, and I don't know the Gentoo command to find that.

----------

## hasues

What does dnsdomainname report?

----------

## hasues

Well, looks like you are correct in that the Domain = "landy.net" is to go in the idmapd.conf file and does what that value in /etc/default/nfs does.  However, have you tried it without quotes?  All the examples I am seeing are not using quotes.

----------

## mounty1

Yes, I tried it without quotes.  I only put the quotes on to-day in response to the earlier suggestion in this thread that they might help.

----------

## mounty1

 *hasues wrote:*   

> What does dnsdomainname report?

 Nothing;  it returns no output.

This is blinking well baffling !   Is anyone running a NFSv4 client on Linux ?

----------

## ojbyer

 *mounty1 wrote:*   

> This is blinking well baffling !   Is anyone running a NFSv4 client on Linux ?

 I'm having this exact same problem. I hadn't updated nfs-utils for a long time and all of a sudden when I did this problem showed up.

This is an  upstream bug in nfs-utils. There's a discussion on the Redhat bug tracker and I opened a Gentoo bug as well.

----------

## mounty1

 *ojbyer wrote:*   

> This is an  upstream bug in nfs-utils. There's a discussion on the Redhat bug tracker and I opened a Gentoo bug as well.

 Looks like it's fixed in nfs-utils-1.2.5.3 so let's just wait for that to float downstream.

----------

## ojbyer

 *mounty1 wrote:*   

> Looks like it's fixed in nfs-utils-1.2.5.3 so let's just wait for that to float downstream.

 I took this opportunity to learn about ebuilds, overlays and github and I made an overlay that contains ebuilds that fix the problem. 

Anyone who doesn't want to wait can use them. I've got an one the applies the fix to the Gentoo-patched version of 1.2.4 and a version of 1.2.5.

----------

## wmark

Make sure that dnsdomainname actually returns something and resolveip <your-non-localhost-ip> has a FQDN as first result. The corresponding domain name will be used by idmapd.

If your /etc/host.conf says order hosts then you will have to feature the FQDN as first entry after your IP address in /etc/host. Any fancy and short aliases go after that.   :Wink: 

For example:

```

# resolveip 192.168.1.16

Host name of 192.168.1.16 is testhost.foobar.net, testhost

# hostname

testhost

# hostname --fqdn

testhost.foobar.net

# dnsdomainname

foobar.net

# grep -F '192.168.1.16' /etc/hosts

192.168.1.16 testhost.foobar.net testhost

# grep -v '^#' /etc/idmapd.conf | grep -v '^$'

[General]

Domain = foobar.net

Local-Realms = FOOBAR.NET,SPAM.UCE.EDU

Pipefs-Directory = /var/lib/nfs/rpc_pipefs

[Translation]

Method = nsswitch

# grep -e '^order' /etc/host.conf

order hosts, bind

```

If the FQDN couldn't be resolved by /etc/hosts the FQDN will have to be provided by DNS. That is, dig +short <your-non-localhost-ip> has to return the FQDN and so forth. You got the idea.

----------

## depontius

 *mounty1 wrote:*   

> 
> 
> ```
> 127.0.0.1       localhost localhost.landy.net
> 
> ...

 

Ummmm... My /etc/hosts files have never looked like this.  I've always had first the IP, then the FQDN, then the shortname.  You appear to have the shortname and FQDN reversed.  As mentioned elsewhere, you need to get reasonable results out of "hostname" and "hostname -f" in order to work properly.  In other words, if your box doesn't even know who it is and what domain it's in, it's going to have a darned tough time making the domain-sensitive part of the idmapper work.

----------

## mounty1

 *ojbyer wrote:*   

>  *mounty1 wrote:*   Looks like it's fixed in nfs-utils-1.2.5.3 so let's just wait for that to float downstream. I took this opportunity to learn about ebuilds, overlays and github and I made an overlay that contains ebuilds that fix the problem. 
> 
> Anyone who doesn't want to wait can use them. I've got an one the applies the fix to the Gentoo-patched version of 1.2.4 and a version of 1.2.5.

 Funny;  1.2.6 has now arrived, but the problem is still there.    :Mad: 

----------

