Fun with NFSv4 and mount paths

Here’s one that bit me, and chewed off far too many hours.  The only advantage to the process is that I learned some incidental things about FreeIPA, or “RHEL Identity Management”.

Background: CentOS 7.4 originally, and as vanilla as I could possibly keep things.  I’d started setting up IPA earlier this year, and it all was “working” until I decided to make some “improvements”, namely getting home directories automounted.  I started out using /users as the mount point/parent for home directories on the server, but read some advice to use a different directory on the server to actually hold the home directories so that the file server could also automount the users’ homes to the same location – more consistent.

I set this up, moving the directories, and modifying the IPA map to reflect this.  Though it didn’t happen immediately, this turned out to break things, and so for the benefit of anyone else who trips over this:

Seeing messages indicating that the home directory couldn’t be mounted wasn’t an IPA issue:

mount.nfs4: mounting home1.us.kmpeterson.com:/users/kmp failed, reason given by server: No such file or directory

(actually, most apparently: “can’t mount home directory” on login)

And:

Dec 28 16:27:05 client1.us.kmpeterson.com oddjob-mkhomedir[18428]: error creating /home/kmp: No such file or directory

There wasn’t essentially a problem with the map.  By the time I got to this point, I’d reviewed over and over the exports file entry:

/users *(rw,sec=krb5p:krb5i:krb5,fsid=0)

That’s pretty clear.  And mount (on the NFS server) appears to reflect this:

/dev/mapper/volgroup1-home on /users type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
auto.home on /home type autofs (rw,relatime,fd=19,pgrp=1189,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=31126)
/dev/mapper/volgroup1-home on /home/kmp type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

And the one I really thought was germane:

lookup_read_map getautomntent_r lookup_read_map: lookup(sss): getautomntent_r: No such file or directory

What’s the answer then:

The first message mislead me.  “No such file or directory” indicated the issue was that NFS wasn’t exporting what I thought it was.  The real problem is that the client wasn’t trying to mount what I thought it was.

The export had been changed to export /users rather than /home.  My previously working map, when I was using /home on the server had this option string:

-fstype=nfs4,rw,sec=krb5p:krb5i:krb5,soft,rsize=8192,wsize=8192 home01.us.kmpeterson.com:/home/&

Changing home to user:

-fstype=nfs4,rw,sec=krb5p:krb5i:krb5,soft,rsize=8192,wsize=8192 home01.us.kmpeterson.com:/users/&

Wasn’t the right answer.  The right answer is:

A client using NFSv4 to mount a filesystem exported with fsid=0 won’t process (as understood in my CentOS 7 environment) the “server path”.  This means that the export must be the root, and the mount specifies the path.  The mount key must end with the string :/& — the /home from the server along with the key construct the target path.

Or, what worked is this:

/etc/exports:

/home *(rw,sec=krb5p:krb5i:krb5,fsid=0)

auto.home option string:

stype=nfs4,rw,sec=krb5p:krb5i:krb5,soft,rsize=8192,wsize=8192 home01.us.kmpeterson.com:/&

This mounts home01.us.kmpeterson.com:/home/kmp to /home/kmp on the NFSv4 client.

Clear as… well, it’s been a long day.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s