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@xxxxxxx> 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@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
