freebsd stable - Jul 2018 - FreeBSD 11.2-RELEASE - mountd problem - mountd[1056]: unknown user: root

Hello -

I'm having a problem with one of my FreeBSD NFS servers. It's an
11.2-RELEASE box (upgraded fairly recently from 10.1), and actually
we had the same issue even when it was on 10.x.

Basically, what is happening is several of my NFS exports that are
configured with "-maproot=root" (and they are actually ZFS NFS
exports, in /etc/zfs/exports, configured with the 'zfs set
sharenfs="..."' command - if that matters, which I don't think
it
does) are generating the following error messages when the machine
first boots up -

Jul  X 15:19:58 nfs5 mountd[1094]: unknown user: root
Jul  X 15:19:58 nfs5 mountd[1094]: message repeated 14 times: [ unknown
user: root]

To fix the issue, I simply HUP the mountd process. Until I HUP the
mountd process, none of the clients that depend on being able to
write to their NFS shares as root work properly - they are read-only.
As soon as I HUP mountd, the issue goes away, no more "unknown user:
root" errors, and the mounts become writable for their clients.

I think this is tied into the fact this box uses sssd for LDAP
authentication, because I don't see this issue on another 11.2
machine configured very similarly that isn't using sssd. The LDAP
authentication works fine, the relevant lines in /etc/nsswitch.conf
look like -

$ grep sss /etc/nsswitch.conf
group: sss files
passwd: sss files

It feels like this may be some sort of ordering issue with the start
up scripts - mountd running before sssd is running? But why doesn't
it fall back to "files" and find root that way? We do *not* have a
root user in our ldap directory anyway. Someone on IRC has suggested
that I should swap the "sss files" to "files sss", but
I'm not sure
if this would help or not... For now, I simply added the following
work-around to my /etc/rc.local:

  kill -s HUP `cat /var/run/mountd.pid`

Has anyone seen a similar issue, or have any ideas?  I CC'd Rick
because I understand he is the NFS maintainer.

thanks,
John


-- 
GPG fingerprint: 17FD 615A D20D AFE8 B3E4  C9D2 E324 20BE D47A 78C7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20180725/d4fe35b6/attachment.sig>

John Newman wrote:
>I'm having a problem with one of my FreeBSD NFS servers. It's an
>11.2-RELEASE box (upgraded fairly recently from 10.1), and actually
>we had the same issue even when it was on 10.x.
>
>Basically, what is happening is several of my NFS exports that are
>configured with "-maproot=root" (and they are actually ZFS NFS
>exports, in /etc/zfs/exports, configured with the 'zfs set
>sharenfs="..."' command - if that matters, which I don't
think it
>does) are generating the following error messages when the machine
>first boots up -
>
>Jul  X 15:19:58 nfs5 mountd[1094]: unknown user: root
>Jul  X 15:19:58 nfs5 mountd[1094]: message repeated 14 times: [ unknown
>user: root]
This means that getpwnam() for "root" is failing. When an error is
logged as above,
the export line has failed and the export hasn't happened.
(Apparently, this gets "fixed" after you have booted, since it can
getpwnam() for
 "root" when you send mountd a SIGHUP.)

A couple of possible ways to fix this...
- Have a local password file on the server with "root" in it and edit
your
   /etc/nsswitch.conf so it looks there first. "passwd: file ..." or
something like that.
- Replace "root" with 0,0 on the exports line(s). I haven't done
this recently,
  so I don't remember the exact syntax.;-)
>To fix the issue, I simply HUP the mountd process. Until I HUP the
>mountd process, none of the clients that depend on being able to
>write to their NFS shares as root work properly - they are read-only.
>As soon as I HUP mountd, the issue goes away, no more "unknown user:
>root" errors, and the mounts become writable for their clients.
>
>I think this is tied into the fact this box uses sssd for LDAP
>authentication, because I don't see this issue on another 11.2
>machine configured very similarly that isn't using sssd. The LDAP
>authentication works fine, the relevant lines in /etc/nsswitch.conf
>look like -
>
>$ grep sss /etc/nsswitch.conf
>group: sss files
>passwd: sss files
I'd suggest you change these to...
group: files sss
passwd: files sss
and just have the minimum in /etc/passwd and /etc/group to make booting happy.
>It feels like this may be some sort of ordering issue with the start
>up scripts - mountd running before sssd is running? But why doesn't
>it fall back to "files" and find root that way? We do *not* have a
>root user in our ldap directory anyway. Someone on IRC has suggested
>that I should swap the "sss files" to "files sss", but
I'm not sure
>if this would help or not... For now, I simply added the following
>work-around to my /etc/rc.local:
>
>  kill -s HUP `cat /var/run/mountd.pid`
That works too. I don't know anything about the libc stuff behind
getpwnam(), so
I don't know why it fails at boot, but works later. (I always put the
critical stuff in
local files on servers and specify "files" first.)

Maybe someone else can explain why the ldap case would fail?

rick