Page 1 of 1

nfsv4 idmapping between domains

Posted: 2018/05/18 10:26:26
Wondering if someone may point me in the correct direction... after 6 hours of googling around for an answer, I'm not any closer.

I have an environment which has two dns domains... and

Years ago, everything was on, and slowly we integrated machines into our active directory domain with single signon using sssd. Now, all machines, except one, are on The one machine left on, due to the software it runs (a much older version of centos running a rocks head-end), cannot be easily migrated. However, all the uid/gids in passwd/groups on the old machine match their ad counterparts.

Up to this point, we have not used nfsv4 w/ idmapping, all machines in used autofs and had a nfsvers=3 in their /etc/ mount options. However in the process of solving a different issue related to lockd after upgrading to 7.5, it became necessary to remove this parameter (which then enables nfsv4) on our machines.

Well, this has the unanticipated consequences of now having everyone be unable to access their files via nfs on All file ownership shows as nobody:nobody. Looking in /var/log/rsyslog, I see a series of messages:

May 18 06:05:49 mybox nfsidmap[39170]: nss_getpwnam: name '' does not map into domain ''

Well, my name, gid, and uid are identical on both and, so I'm not sure what is causing this messages.

On my machine, I've tried various iterations of changes to /etc/idmapd.conf, with no success, based on numerous threads I've found online, although truthfully I have not been able to find one which describes a similar networking environment. Regardless of the modifications I've made to the Domains, Realm-Domains, No-Strip, Method, etc.) I constantly get the above message whenever I attempt to access an nfs filesystem on

Any pointers as to how I can resolve this would be appreciated. I'm starting to get cross-eyed flipping through pages of decade-old search results now.

Re: nfsv4 idmapping between domains

Posted: 2018/05/18 14:44:46
by hunter86_bg
Did you setup a trust between and ? I guess a trust between the 2 domains could resolve that.

Re: nfsv4 idmapping between domains

Posted: 2018/05/18 14:50:56
by is not an active directory domain (never was, thus the move to to facility single signon rather than NIS or individual machine accounts), its merely the dns name of the old centos machine.

At this point, the single machine on has its own /etc/passwd /etc/group files which have uid/gids mimicking their AD counterparts in

All worked fine with nfs versions prior to 4, but the idmapping in nfsv4 barfs. I'm sure there's a parameter somewhere I can set in /etc/idmapd.conf to resolve this, but I simply cannot find it.

Re: nfsv4 idmapping between domains

Posted: 2018/05/18 16:43:05
by hunter86_bg
Maybe you can set [static] on the old server. Something like described here.

Re: nfsv4 idmapping between domains

Posted: 2018/05/18 18:29:03
yes, i thought about that. However, I'd prefer not to have to create several hundred entries for all the users and distribute the resulting idmap.conf file to the hundred or so servers which require nfs access to the file systems on Sort of defeats the point of having ad and single signon if I have to maintain this manually for nfsv4 under 7.5 when it worked fine with nfsv3 under 7.4.... especially when the user names, uids, and gids are identical.

Re: nfsv4 idmapping between domains

Posted: 2018/05/18 19:11:37
by hunter86_bg
What happens when you disable version 4 on The NFS version is negotiatable between server and clients. As per my understanding, you had to disable nfsvers=3 on the clients, but you can achieve the same by restricting the NFS server ( to only NFS v3.

Re: nfsv4 idmapping between domains

Posted: 2018/05/18 19:37:05
hunter86_bg wrote:What happens when you disable version 4 on
Hundreds of clients start puking with "protocol not supported" errors when they attempt to automount filesystems on The clients do not seem to negotiate down in nfs versions.
The NFS version is negotiatable between server and clients. As per my understanding, you had to disable nfsvers=3 on the clients, but you can achieve the same by restricting the NFS server ( to only NFS v3.
in /etc/ there was a specific parameter to force automount to use nfs version 3. I cannot recall why this was done -- much of this environment has been in existence for over a decade. The upgrade from 7.4 to 7.5 on client systems necessitated removing the parameter to fix an issue with lockd which caused gdm to stop working. however, in that case, there was no impact, because user home directories are on servers in the name space.

I suppose I could "fix" the issue by upgrading the rocks headend to centos 7 and integrate it into ad, but that will require scheduling a week of downtime, and is my last resort at this point.

Re: nfsv4 idmapping between domains

Posted: 2018/05/18 22:50:43
by hunter86_bg
Can you provide the autofs configuration and /etc/sysconfig/autofs (if exists) of one of the nfs clients ? Maybe 'mount_nfs_default_protocol' was explicitly set to ignore nfs v3.

Re: nfsv4 idmapping between domains

Posted: 2018/05/19 10:16:30
All the clients are identical. They are pretty much a stock CentOS 7 rollout with a few minor configuration changes to integrate it into the network (e.g. join it to ad, change /etc/auto.master to set the global common mount point to something other than /net, etc.)

I am hesitant to start fiddling around with nfs on all the client systems. I have hundreds of clients and a dozen servers in which are working fine -- many of the clients are themselves also have local filesystems they share via nfs/automount to other clients. Its this single older machine, which serves as a rocks head-end (and thus cannot be modified at the risk of breaking rocks which will result in a complete shitshow), which is giving me grief.


Code: Select all

# Define custom options in /etc/sysconfig/autofs
# Use LOCALOPTIONS for defining variables, e.g. OSREL
# Use DAEMONOPTIONS to define the unmount timeout
# Define UNDERSCORETODOT as 1 to convert 
#     auto_home to auto.home and auto_mnt to auto.mnt
# Mount options, e.g. rsize=8192, should go in auto.master or
#     the auto_* map entry for a specific mount point

#  UNDERSCORETODOT changes auto_home to auto.home and auto_mnt to auto.mnt

Code: Select all


# $Id:,v 1.5 2003/09/29 08:22:35 raven Exp $

# Look at what a host is exporting to determine what we can mount.
# This is very simple, but it appears to work surprisingly well


# add "nosymlink" here if you want to suppress symlinking local filesystems
# add "nonstrict" to make it OK for some filesystems to not mount

# Showmount comes in a number of names and varieties.  "showmount" is
# typically an older version which accepts the '--no-headers' flag
# but ignores it.  "kshowmount" is the newer version installed with knfsd,
# which both accepts and acts on the '--no-headers' flag.
#SHOWMOUNT="kshowmount --no-headers -e $key"
#SHOWMOUNT="showmount -e $key | tail +2"

# Newer distributions get this right
SHOWMOUNT="/usr/sbin/showmount --no-headers -e $key"

$SHOWMOUNT | sort | \
        awk -v key="$key" -v opts="$opts" -- '
        BEGIN           { ORS=""; first=1 }
                        { if (first) { print opts; first=0 }; print " \\\n\t" $1
, key ":" $1 }
        END             { if (!first) print "\n"; else exit 1 }

Re: nfsv4 idmapping between domains

Posted: 2018/05/20 13:33:47
by hunter86_bg
Have you tried to disable the mapping on the NFS server just like the answer here?

From solution 2252881 idmapping is disabled by default (maybe joining to domain changes that) ,but you can also disable them manually:

ID mapping is handled by rpc.idmapd on the NFS server and nfsidmap by default, or optionally by rpc.idmapd, on the NFS client. Please refer to their manual pages for more details.

ID mapping can be disabled by using the following tunables:
* NFS client: /sys/module/nfs/parameters/nfs4_disable_idmapping
* NFS server: /sys/module/nfsd/parameters/nfs4_disable_idmapping


ID mapping cannot be disabled.
Both the NFS Client and NFS Server use rpc.idmapd.

NFS Client

In RHEL 6.3 (kernel 2.6.32-279.el6) ID mapping defaults to disabled on the NFS Client. i.e. nfs4_disable_idmapping defaults to "Y".

Prior to RHEL 6.3 rpc.idmapd was required for ID mapping. In RHEL 6.3, nfsidmap and keyring based ID mapping was introduced in nfs-utils-1.2.3-26.el6. There were issues in the implementation that were fixed in RHEL 6.6's nfs-utils-1.2.3-54.el6. If ID mapping is required for RHEL 6.5 or older, please use rpc.idmapd.

NFS Server

In RHEL 6.5 (2.6.32-431.el6) ID mapping can be disabled on the NFS Server. However, nfs4_disable_idmapping defaults to "N". The kernel NFS Server maintainer recommends that users disable ID mapping on new NFS servers by setting nfs4_disable_idmapping to "Y".

The NFS Server uses rpc.idmapd for ID mapping.


Both the NFS Client and the NFS Server has ID mapping disabled by default. i.e. nfs4_disable_idmapping defaults to "Y"

For ID mapping, the NFS Client uses nfsidmap and the NFS Server uses rpc.idmapd