nfsv4 idmapping between domains

Issues related to configuring your network
Post Reply
vtwin@cox.net
Posts: 38
Joined: 2017/02/16 16:41:29

nfsv4 idmapping between domains

Post by vtwin@cox.net » 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... ad.mydomain.com and old.mydomain.com

Years ago, everything was on old.domain.com, and slowly we integrated machines into our active directory domain with single signon using sssd. Now, all machines, except one, are on ad.mydomain.com. The one machine left on old.mydomain.com, 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 ad.mydomain.com used autofs and had a nfsvers=3 in their /etc/auto.net 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 ad.mydomain.com machines.

Well, this has the unanticipated consequences of now having everyone be unable to access their files via nfs on old.mydomain.com. 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 'myname@host.old.mydomain.com' does not map into domain 'ad.mydomain.com'

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

On my ad.mydomain.com 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 old.mydomain.com

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.

hunter86_bg
Posts: 2019
Joined: 2015/02/17 15:14:33
Location: Bulgaria
Contact:

Re: nfsv4 idmapping between domains

Post by hunter86_bg » 2018/05/18 14:44:46

Did you setup a trust between ad.domain.com and old.domaain.com ? I guess a trust between the 2 domains could resolve that.

vtwin@cox.net
Posts: 38
Joined: 2017/02/16 16:41:29

Re: nfsv4 idmapping between domains

Post by vtwin@cox.net » 2018/05/18 14:50:56

old.mydomain.com is not an active directory domain (never was, thus the move to ad.mydomain.com 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 old.mydomain.com has its own /etc/passwd /etc/group files which have uid/gids mimicking their AD counterparts in ad.mydomain.com

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.

hunter86_bg
Posts: 2019
Joined: 2015/02/17 15:14:33
Location: Bulgaria
Contact:

Re: nfsv4 idmapping between domains

Post by hunter86_bg » 2018/05/18 16:43:05

Maybe you can set [static] on the old server. Something like described here.

vtwin@cox.net
Posts: 38
Joined: 2017/02/16 16:41:29

Re: nfsv4 idmapping between domains

Post by vtwin@cox.net » 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 old.mydomain.com. 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.

hunter86_bg
Posts: 2019
Joined: 2015/02/17 15:14:33
Location: Bulgaria
Contact:

Re: nfsv4 idmapping between domains

Post by hunter86_bg » 2018/05/18 19:11:37

What happens when you disable version 4 on old.mydomain.com? 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 (old.domain.com) to only NFS v3.

vtwin@cox.net
Posts: 38
Joined: 2017/02/16 16:41:29

Re: nfsv4 idmapping between domains

Post by vtwin@cox.net » 2018/05/18 19:37:05

hunter86_bg wrote:What happens when you disable version 4 on old.mydomain.com?
Hundreds of clients start puking with "protocol not supported" errors when they attempt to automount filesystems on old.mydomain.com. 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 (old.domain.com) to only NFS v3.
in /etc/autofs.net 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 ad.mydomain.com 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.

hunter86_bg
Posts: 2019
Joined: 2015/02/17 15:14:33
Location: Bulgaria
Contact:

Re: nfsv4 idmapping between domains

Post by hunter86_bg » 2018/05/18 22:50:43

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.

vtwin@cox.net
Posts: 38
Joined: 2017/02/16 16:41:29

Re: nfsv4 idmapping between domains

Post by vtwin@cox.net » 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 ad.mydomain.com 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.

/etc/sysconfig/autofs:

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
#
LOCALOPTIONS=""
DAEMONOPTIONS="--timeout=900"

#  UNDERSCORETODOT changes auto_home to auto.home and auto_mnt to auto.mnt
UNDERSCORETODOT=1
DISABLE_DIRECT=1
/etc/auto.net:

Code: Select all

#!/bin/sh

# $Id: auto.net,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

key="$1"

# add "nosymlink" here if you want to suppress symlinking local filesystems
# add "nonstrict" to make it OK for some filesystems to not mount
opts="-fstype=nfs,tcp,intr,nodev"

# 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 }
        '

hunter86_bg
Posts: 2019
Joined: 2015/02/17 15:14:33
Location: Bulgaria
Contact:

Re: nfsv4 idmapping between domains

Post by hunter86_bg » 2018/05/20 13:33:47

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

RHEL 5

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

RHEL 6
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.

RHEL 7

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
Source: https://access.redhat.com/articles/2252881

Post Reply