NFS capabilities just died randomly on my workstation

Red Squirrel

No Lifer
May 24, 2003
69,662
13,310
126
www.betteroff.ca
I was trying to open an Open Office document, when it just froze at the splash screen. REfused to open. Tried again and again, nothing. So I rebooted. Now I can't even mount my NFS shares. Mount -a just does nothing. It just sits forever. The machine also took about 10 minutes to boot up.

Only thing I see in the logs that MIGHT be an issue is this:

Code:
[   15.672179] alx 0000:02:00.0 enp2s0: NIC Up: 1 Gbps Full
[   15.672384] IPv6: ADDRCONF(NETDEV_CHANGE): enp2s0: link becomes ready
[  111.146224] vboxdrv: module verification failed: signature and/or required key missing - tainting kernel
[  111.150686] vboxdrv: Found 4 processor cores
[  111.170819] vboxdrv: TSC mode is Invariant, tentative frequency 3501765591 Hz
[  111.170822] vboxdrv: Successfully loaded version 5.0.40_Ubuntu (interface 0x00240000)
[  111.177094] VBoxNetFlt: Successfully started.
[  111.180688] VBoxNetAdp: Successfully started.
[  111.184820] VBoxPciLinuxInit
[  111.186611] vboxpci: IOMMU not found (not registered)
falcon ~ #

Usually anything that says tainted kernel is a bad thing.

Is there a way I can troubleshoot this? NFS is terrible in that it does not really have any logs, not even on the server, so it's something that's very hard to troubleshoot.

This is what I get if I try to mount manually with -v:

Code:
falcon network # mount -v ryan
mount.nfs: timeout set for Mon Apr 16 23:31:34 2018
mount.nfs: trying text-based options 'vers=3,addr=10.1.1.50'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'vers=3,addr=10.1.1.50'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'vers=3,addr=10.1.1.50'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'vers=3,addr=10.1.1.50'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused

All my VMs are running ok so I know it's not the NFS server. It's something with the workstation.
 

Red Squirrel

No Lifer
May 24, 2003
69,662
13,310
126
www.betteroff.ca
Ok so restarting NFS on the server fixed it... problem is now every single file I try to open is locked for editing, wtf? Is there a way to reset that? I don't see any hidden files or anything that I can delete.
 

thecoolnessrune

Diamond Member
Jun 8, 2005
9,673
583
126
Are these NFSv3 shares? Chances are something is messed up with the nfslock daemon (or it never started). Have you tried restarting your NFS Server entirely to see if it can come up clean?
 

Red Squirrel

No Lifer
May 24, 2003
69,662
13,310
126
www.betteroff.ca
I think so, not really sure how to check. It's CentOS 6.9 so whatever is default in that distro. I did restart NFS. I was reluctant to do that because it could crash all my VMs but it seems to have been ok.

It seems to only be doing it to open office documents. If I copy the file locally I can edit it, and then copy it and overwrite the one on the share, but quite annoying having to do that.
 

Fallen Kell

Diamond Member
Oct 9, 1999
6,142
500
126
CentOS 6.x defaults to using NFSv4. Try changing your client mount options to use "intr tcp vers=3 nolock". If that works, then try it without the "nolock" option. If that still works, try without the "vers=3" option. I suspect it is the NFSv4 protocol and has something to do with your NFSv4 domain, but the above would prove it out.

You can verify what protocol you are using via "nfsstat -c" on the client side and seeing if the command counts are under the NFS3 or NFS4 sections (and/or you can specifically only look at version 3 or version 4 with an option to nfsstat).
 
Last edited: