What does your /etc/idmapd.conf look like on the server side?
I fought with this quite a bit a while ago, but my use case was a bit different, and I was working with CentOS 5 and 6.
Still, the kicker for me was updating the [Translation] section of /etc/idmapd.conf. Mine looks like this:
[Translation] Method = nsswitch GSS-Methods = nsswitch,static
You said you're not using Kerberos or LDAP, so I'm guessing you can leave out the GSS-Methods line entirely, and make your Method line "nsswitch,static".
Furthermore, in my /etc/idmapd.conf file, I have a [Static] section which, according to my comments, maps GSS-authenticated names to local user names. So mine looks kind of like this:
[Static] someuser@REALM = localuser
Again, since you're not using GSS, I'm not sure if you can get away with something like
[Static] joe = joe
But it's probably worth trying/experimenting.
I hope that can be of some help!
On Thu, Apr 23, 2015 at 3:11 PM, Devin Reade gdr@gno.org wrote:
#define TL;DR
Despite idmapd running, usernames/IDs don't get mapped properly. Looking for a workaround.
#undef TL;DR
I'm trying to get a new CentOS 7.1 workstation running, and having some problems with NFS filesystems. The server is a fully patched CentOS 6 server.
On the NFS filesystem, there are two subdirectories owned by a regular user (joe). (There are actually more and by multiple users, but I'll just show the two.) That user exists on both the NFS server and this CentOS 7 NFS client. However, the user on the client machine is unable to perform various operations. (The operations work when logged into the server.)
$ whoami joe $ cd /nfs $ ls -l drwx------. 6 joe joe 4096 Apr 23 11:20 one drwxr-xr-x. 4 joe joe 4096 Dec 14 2011 two $ cd one one: Permission denied. $ cd two $ ls subdir1 subdir2 $ touch testfile touch: cannot touch testfile: Permission denied
mount(1) shows that the filesystem is mounted rw. The server has it exported rw to the entire subnet. Other machines (CentOS 5) mount the same filesystems without a problem.
Looks a lot like an idmapd issue, right?
On the server: # id joe uid=501(joe) gid=501(joe) groups=501(joe)
Back on the client:
$ ps auxww | grep idmap | grep -v grep $ id joe uid=1000(joe) gid=1000(joe) groups=1000(joe) $ cd /nfs $ ls -n drwx------. 6 1000 1000 4096 Apr 23 11:20 one drwxr-xr-x. 4 1000 1000 4096 Dec 14 2011 two
So it looks like even though the name/UID mapping is correct even though the idmapd daemon isn't running on the client. (It looks like CentOS7 only starts idmapd when it's running an NFS *server*.)
# systemctl list-units | grep nfs nfs.mount loaded active mounted /nfs proc-fs-nfsd.mount loaded active mounted NFSD configuration filesystem var-lib-nfs-rpc_pipefs.mount loaded active mounted RPC Pipe File System nfs-config.service loaded active exited Preprocess NFS configuration nfs-client.target loaded active active NFS client services
The behavior was tested again with SELinux in permissive mode; no change.
Splunking a bit more shows some similar behavior for other distros: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/966734 https://bugzilla.linux-nfs.org/show_bug.cgi?id=226
Yep, this is a situation where LDAP and Kerberos aren't in play. And the CentOS 5, CentOS 6, and other UNIXen boxes are using consistent UID/GID mappings. However, CentOS7 (well, RHEL7) changed the minimum UID/GID for regular accounts, so when the account was created on the latter, the UID is out of sync. So much for idmapd (without the fixes involved in the above URLs).
Has anyone else run into this and have a solution other than forcing UIDs to match?
Devin
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos