Fedora 24 NFSv4 Clients Spontaneously Mount Previously-Working Shares as Nobody:Nobody!

A Bug Report is Already In:  https://bugzilla.redhat.com/show_bug.cgi?id=1372136

The Quick Fix Up Front:  executing sudo dnf downgrade libnfsidmap suffices to resolve the matter until the new package version is out with the fix.

Man, that was annoying.  I’m glad people are already on it, and it looks like a patch is on its way out, but it took me a good four hours to figure out what had happened.  In my defense, the first two were spent from 11:00 PM to 1:00 AM and I was in no mood or condition to be methodical and smart when I booted into my beautiful Fedora 24 VM (which depends on an NFSv4-mounted home directory) and found GNOME’s audio controls failing to appear because pulseaudio failed to start properly.

This was particularly unfortunate timing since I was, at that point, just shutting down my Windows 7 VM after troubleshooting its own audio problems which I believed to be caused by a combination of the difficulty with which one controls Windows-connected audio monitors (my HDMI-connected Sony Amp is being missed in favor of the Samsung TV to which it, in turn, is connected, and therefore Windows only wants to output 2 channel sound to my Amp) and some lingering driver-based issues for the VM (which I think I can resolve by installing my motherboard-specific drivers for Windows, given that the Windows VM is using, via IOMMU-facilitated PCI Passthrough, a PCI device from the motherboard).

So I was most displeased to boot up my reliable, perfect Fedora 24 VM and find…spontaneous audio problems.

It turns out, however, that I rather quickly discovered that my NFSv4-mounted home directory was now mounted as nobody:nobody!


I had just run updates on the clients and the server, but both my Fedora 24 systems were failing in the same manner (‘natch) despite an OpenBSD system retaining its NFSv4 client sanity.  I initially suspected an update operation to be at fault, but my faith in the stability of Fedora got the better of me and I didn’t really consider an NFS client bug to be too likely.  I overlooked the obvious culprit in my quick scan of my last dnf operation in which I updated 28 packages, one of which was, of course, the libnfsidmap package, whose name makes it an obvious candidate for causing this issue.

After ratcheting up verbosity on my FreeBSD system’s nfsuserd daemon and watching correct UID and GID assignments roll through despite continued mounts on my clients as nobody:nobody, I returned to my client system and executed nfsidmap -d and saw:

error: /lib64/libnfsidmap.so.0: undefined symbol: __dn_expand

This convinced me I might actually be seeing a bona fide bug and brought me back to my initial investigation of the update history where I found that libnfsidmap had just been updated to version 0.26-5.rc4.fc24.  I downgraded, saw my problem fixed, and then a quick Google of that package revealed the link to the bugzilla report I provide above.

Free Open Source Software!  It’s amazing, and it’s wonderful, but it does require you to remember your fundamentals when faced with operating issues.  A more methodical approach to my issue in which I placed heavier emphasis on the obvious recent system changes (package updates) as the potential culprit would’ve saved me a few hours, I imagine.

This entry was posted in Information Technology and tagged , , . Bookmark the permalink.

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