#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
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
Matt Garman wrote:> 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". ><snip> Related, maybe: I *just* solved my problem with NFS on CentOS 7.0.1406 mounting home directories as nobody:nobody. Looking at the above, and seeing mentions of [Translation], I reviewed the *entire* idpapd.conf file, and found that the UMICH LDAP scheme is, by default, enabled. I'd put our domain in the other day; now I commented out the UMICH, restarted rpcidmapd and autofs, and everything was wonderful. mark
--On Friday, April 24, 2015 10:03:09 AM -0500 Matt Garman <matthew.garman at gmail.com> wrote: [...]> 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[...]> Again, since you're not using GSS, I'm not sure if you can get away > with something like > > [Static] > joe = joeUnfortunately, it looks like the answer is "no". It'll still mess up the mappings. Thanks, though. While on other machines that talk LDAP the mappings may come out right (as yet unverified), in this case it looks like I'll have to resort to moving to higher UIDs. (I could force low UIDs on the CentOS7 side, but it looks like too many things understand the threshold of what makes a "system account".) Ah well. The NFS server was scheduled to be replaced with a FreeBSD box anyway. I guess we'll just have to fast-track it and start moving accounts and converting UIDs. Devin