[CentOS] CentOS 7 NFS client problems

Fri Apr 24 15:03:09 UTC 2015
Matt Garman <matthew.garman at gmail.com>

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