I posted this a few days ago over at http://ubuntuforums.org/ but after 120 views, I've got no answers, so I hope it's OK to cross-post it here. It's a weird problem and Google has been fruitless too:

I use my laptop as my NFS server and my desktop as an NFS client. I recently upgraded the desktop to Ubuntu 16.04 (it was on Ubuntu 14.04 before). The laptop/server is on Ubuntu 14.04, and I didn't change anything on it. For some reason, after the upgrade, I had to comment out the only active line in /etc/hosts.deny on the laptop/server to get my NFS share to mount:
/etc/hosts.allow contains references to all the network adapters on my desktop.

After doing that, I'm able to mount the NFS share on the laptop/server on my desktop, but strangely, I'm prompted to authenticate with this message:
I enter the root password for the desktop (OK, to be honest I think it's the root password for the desktop, but the root password is the same on both computers) and my NFS share mounts.

I'd love to be able to fix both these problems, especially the problem with having to authenticate to get my NFS share to mount. Does anyone have any ideas?

Update:

The output for 'll /sbin/rpc.statd' on the client/desktop is:
On the laptop/server:
No difference that I can see, except for the date, and rights seem correct so that world should be able to access rpc.statd.

Hi:

Was authentication required when you were running Ubuntu 14.04?

I suspect that there was something in the upgrade that changed the way things are recognized and or initialized. Maybe the upgrade changed the configuration you already had set up for your NFS and the configuration somehow became misconfigured?

After reading through this:
https://lists.ubuntu.com/archives/ub...ay/034138.html

Maybe (guessing) that mount.nfs' appeared to think that rpc.statd is not running (which
can't depend on what's in hosts.deny/allow. And that's why commenting that out made it mount?

There are suggestions to add lines to /etc/hosts.deny: (not sure if that helps)
http://www.linux.org/threads/nfs-how...ransfers.6617/

rpc.statd is started automatically by the nfslock service. Maybe that's on or off by default with the upgrade?
https://www.centos.org/docs/5/html/D...US/ch-nfs.html

If there is a way to stop the authentication from being required I didn't find it. Sorry.
I gave it my best.

https://help.ubuntu.com/community/SettingUpNFSHowTo
https://help.ubuntu.com/community/Si...roubleshooting
http://linux.die.net/man/8/rpc.statd

Thanks for your reply, and sorry for my late response (I do shift work and don't have time for much else other than sleeping until I get a block of days off). I like your nfslock idea. A 'ps -ef | grep nfslock' gets no results either on my client or server, but still, I'll try to look into that further, and if I have time I'll read the lengthy NFS documentation you linked. It couldn't hurt to improve my general knowledge of NFS.

Based on the first section in the documentation link, I did check my versions and I seem to be running NFSv3 on the client, whereas the server seems to support versions 2, 3, and 4.

I might end up just completely blowing away NFS on both hosts and starting over too, to see if that somehow fixes it.

3 to 11, 11 to 7 and 7 to 3......yeah BTDT it's not the greatest schedule:-

Sometimes a fresh configuration is the only thing to do when there are so many variables involved.
Hope the NFS documentation helps. It should when you have the time.