FS#43742 - [nfs-utils] Unable to mount NFS shares after latest package update.

Attached to Project: Arch Linux
Opened by Dustin Falgout (lots0logs) - Sunday, 08 February 2015, 18:57 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 24 February 2015, 07:43 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No


Description: After latest update NFS mounts fail to mount. The issue does not occur after downgrading to the previous version.

Additional info:
Version that is broken: 1.3.2-3
Version that works: 1.3.1-1

Steps to reproduce:

Try to mount an NFS share. The following error shows in the journal:

rpc.statd[4913]: Version 1.3.1 starting
rpc.statd[4913]: Flags: TI-RPC
rpc.statd[4913]: Running as root. chown /var/lib/nfs to choose different user
rpc.statd[4913]: failed to create RPC listeners, exiting
systemd[1]: rpc-statd.service: control process exited, code=exited status=1
systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking..
systemd[1]: Unit rpc-statd.service entered failed state.
systemd[1]: rpc-statd.service failed.
mount[4907]: Job for rpc-statd.service failed. See "systemctl status rpc-statd.service" and "journalctl -xe" for details.

This task depends upon

Closed by  Andreas Radke (AndyRTR)
Tuesday, 24 February 2015, 07:43 GMT
Reason for closing:  Works for me
Additional comments about closing:  with rpcbind and nfs-server on the server side and rpcbind + nfs-client on the clients mounting v4 and v3 works well with current core packages.
Comment by Leo Peschier (leepesjee) - Sunday, 08 February 2015, 21:28 GMT
I have thesame issue, except that version 1.3.1-1 doesn't work for me either.
Comment by Bujhm (Bujhm666) - Monday, 09 February 2015, 05:07 GMT
I have the same problem with the update 1.3.1-1.
My NSF resources are not mounted (through fstab also).
Comment by Tobias Powalowski (tpowa) - Monday, 09 February 2015, 05:58 GMT
Please enable rpcbind service as the wiki suggests.
NFS3 needs rpcbind.
Comment by Dustin Falgout (lots0logs) - Monday, 09 February 2015, 08:35 GMT
  • Field changed: Percent Complete (100% → 0%)
I have always had rpcbind enabled. I've been using NFS mounts on my system for the last two years. I have not made any changes to my configuration. Perhaps something changed in the latest update that is causing this or requires additional configuration that was not required previously. I will try to set some time aside to troubleshoot this ASAP.
Comment by Peter Weber (hoschi) - Monday, 09 February 2015, 15:42 GMT
I think the usual *hehe* problem with rpc.statd show always up, if a mere client tries to access an old NFSv3-Server. In this case, rpcbind.service is currently not mentioned for the client on the Wiki (should I add it?):
It seems to work for me with:
systemctl start nfs-client.target
systemctl start rpcbind.service
systemctl start rpc-statd.service
mount -t nfs [path_to_server] [mountpoint]
Comment by Josias Wolhuter (hawkinsthewizard) - Monday, 09 February 2015, 16:19 GMT
on nfs server
since 8 February 2015 nfs-idmapd fails and doesnt say why in the journal
systemd[1]: Failed to start NFSv4 ID-name mapping serv
-- Subject: Unit nfs-idmapd.service has failed
Comment by John (graysky) - Tuesday, 10 February 2015, 21:38 GMT
The problem is deeper than broken mounts. On my previously fine nfs-server, none of my exports are exporting due to a failure of rpc-statd

sudo journalctl _SYSTEMD_UNIT=rpc-statd.service
-- Reboot --
Feb 10 16:35:17 mars rpc.statd[561]: Version 1.3.2 starting
Feb 10 16:35:17 mars rpc.statd[561]: Flags: TI-RPC
Feb 10 16:35:17 mars rpc.statd[561]: Failed to read /var/lib/nfs/state: Success
Feb 10 16:35:17 mars rpc.statd[561]: Initializing NSM state
Feb 10 16:35:17 mars rpc.statd[561]: Running as root. chown /var/lib/nfs to choose different user
Feb 10 16:35:17 mars rpc.statd[561]: failed to create RPC listeners, exiting

sudo journalctl _SYSTEMD_UNIT=nfs-server.service
-- Reboot --
Feb 10 16:35:17 mars rpc.nfsd[571]: rpc.nfsd: writing fd to kernel failed: errno 111 (Connection refused)
Feb 10 16:35:17 mars rpc.nfsd[571]: rpc.nfsd: unable to set any sockets for nfsd
Comment by John (graysky) - Tuesday, 10 February 2015, 21:45 GMT
In an attempt to debug, I have begun rolling back packages. I have a functional system now with:

rpcbind to 0.2.1-5
nfs-utils to 1.3.1-1

Not sure if all of these are required at this point. I need to do family stuff now. Perhaps someone else can investigate with the rpcbind downgrade only and see if behavior is fixed. If not, try both rpcbind and nfs-utils.

EDIT: Forgot to mention that clients required a downgrade of libnfs to 1.9.6-1 to work with the downgraded server versions.
Comment by Bill Gardner (Cassino) - Tuesday, 10 February 2015, 21:59 GMT
I was able to get back in business by only downgrading nfs-utils to 1.3.1-1.

On Arch I run a Kerberized NFS client only, not an NFS server.
Comment by John (graysky) - Tuesday, 10 February 2015, 22:39 GMT
OK. I can confirm that the problem for my system resides with rpcbind to 0.2.2-2 not with nfs-utils 1.3.2-3. If I downgrade only rpcbind to 0.2.1-5, everything works as expected. Updating to 0.2.2-2 causes the breakage. Can someone confirm and reassign this bug report to the rpcbind package?

Also, libnfs needs to be downgraded to 1.9.6-1 for clients or else they are unable to connect when the server is using the downgraded rpcbind.

EDIT: I just read through  FS#41433  and after seeing that one needs to implicitly start rpcbind now, everything seems to work: enable rpcbind and nfs-utils (which the wiki states) on the server. Reboot to verify.

...but I still need to use libnfs-1.9.6-1 so I opened  FS#43776 
Comment by Bill Gardner (Cassino) - Tuesday, 10 February 2015, 22:46 GMT
Re graysky's report, I don't confirm that.

I'm running rpcbind 0.2.2-2 and downgraded nfs-utils 1.3.1-1, and everything works like before.

I don't have libnfs installed.
Comment by Jan Magnus Brevik (Best) - Wednesday, 11 February 2015, 04:21 GMT
Had to downgrade nfs-utils on the client. Was geting mount.nfs: an incorrect mount option was specified with nfs-utils 1.3.2-3.
Comment by Bujhm (Bujhm666) - Wednesday, 11 February 2015, 04:52 GMT
After the upgrade nfs-utils, I also get the error "mount.nfs: an incorrect mount option." I had to remove "noloсk" in mount options, and it worked.
Comment by Keith Waclena (keithw) - Wednesday, 11 February 2015, 16:19 GMT
Same problem here; downgrading one doesn't help, I have to downgrade both:

nfs-utils (1.3.1-1) & rpcbind (0.2.1-5): works
nfs-utils (1.3.2-3) & rpcbind (0.2.2-2): BROKEN

Linux myhost 3.18.6-1-ARCH #1 SMP PREEMPT Sat Feb 7 08:44:05 CET 2015 x86_64 GNU/Linux
Comment by Tobias Powalowski (tpowa) - Thursday, 12 February 2015, 07:22 GMT
Please be sure to enable and run rpcbind the "incorrect mount option" is a timeout error in rpc.mountd
which cannot launch if you don't enable rpcbind.
NFS3 needs rpcbind, NFS4 does not need rpcbind.
Comment by Jan Magnus Brevik (Best) - Friday, 13 February 2015, 03:38 GMT
I enabled rpcbind on both client and server then rebooted. Still got the incorrect mount option before I downgraded nfs-utils on the client.
Comment by Marco Milch (manalishi) - Sunday, 15 February 2015, 13:00 GMT
After upgrading rpcbind to 0.2.2-2 and nfs-utils to 1.3.2-3, neither rpcbind.service nor rpc-statd.service were active after booting. I had to start both services and nfs-client.target manually to mount the NFS mounts.
Comment by Jason S. Wagner (jswagner) - Monday, 16 February 2015, 10:00 GMT
Upgrading rpcbind and nfs-utils and broke both my server and my client. I just needed it to work, so downgrading both machines (along with libnfs on my desktop) got things going again.
Comment by Leo Peschier (leepesjee) - Monday, 16 February 2015, 14:02 GMT
I can acknowledge that the nfs mounts now work, with nfs-utils 1.3.2-3 and rpcbind 0.2.2-2, though I have not been able to nail down what exactly made it work. I still have a problem on another client, which connects to the same nfs-server but which is on armv7; that one still needs a downgrade to nfs-utils 1.3.1-1