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 at 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 at 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 at centos.org > http://lists.centos.org/mailman/listinfo/centos