You are not logged in.
I'm running a fully up to date 64-bit Arch with Xfce as DE.
Linux sirius 3.10.9-1-ARCH #1 SMP PREEMPT Wed Aug 21 13:49:35 CEST 2013 x86_64 GNU/Linux
I use several NFS mounts, all manually mounted. I've had quite a few problems with Arch failing to shut down if I forget to unmount the share prior to shutting down, but today I hit a new problem.
Ran pacman -Syu earlier, and ended up with a new kernel and a new rpcbind package. When I attempted to mount one of my NFS mounts, I ended up with this error:
mount.nfs: Protocol not supported
Since the mount had been working earlier in the day, it has to be something in either the new kernel or in the updated version of rpcbind. I was in a hurry (had a job to finish) so I've rolled both back to the previous versions for the moment. When I've finished the job, I'll try upgrading again and see if I can narrow down the cause of the problem.
In the meantime, has anyone else hit this sort of problem? I did some searching, but the only hits I got were for things like problems with /etc/services, which don't apply here, so I'm at a bit of a loss.
Paul.
Offline
Offline
Strange. I searched under exactly those terms and didn't get any hits.
I'm not sure what the problem is. Before entering my original message I had restarted the machine and still had the same problem. I also hit another problem - the system suddenly started having problems getting a wifi connection. I'm using an Asus RT-N56U router (dual wifi). The system kept failing at the authentication stage, then, eventually connected to the 2.4 GHz AP, but would only get a 72 mbps connection. And I was still getting a "protocol not supported" error when attempting to connect to my NFS shares.
I've updated the kernel and rpcbind again, and everything is working, but...
It took several attempts to get the laptop to connect to the 5 GHz AP, and its only getting a 150 mbps connect. I've currently got two NFS connects - one to an Icy Box NAS, the other to a Slackware-based home server. I've got the server connect set to use NFS ver 3 (one of my attempts to stop the shutdown lockups I've been having with NFS), while the Icy Box defaults to NFS ver 4. Now, connecting to the Icy Box takes 20 - 30 seconds, while the connect to the server is pretty well instantaneous. Prior to this, there was no discernible difference in the connect/mount time.
I like challenges, but at the moment, I'm completely out of my depth. From a system that had one (avoidable) problem, I've ended up with a host of of them...
One other odd thing - looking through dmesg to see if I could spot what was happening during the slow NFS connects, I've found this:
[ 224.599735] NFS: Registering the id_resolver key type
[ 224.599748] Key type id_resolver registered
[ 224.599749] Key type id_legacy registered
[ 239.636798] RPC: AUTH_GSS upcall timed out.
Please check user daemon is running.
I'm not at all sure what "user daemon" is being referred to, so its a bit difficult to check whether its running or not.....
Paul.
Offline
Have you tried the 'fix' outlined here:
https://bbs.archlinux.org/viewtopic.php … 5#p1312675
It worked for me, still dont understand why it is required though.
Offline
Have you tried the 'fix' outlined here:
https://bbs.archlinux.org/viewtopic.php … 5#p1312675It worked for me, still dont understand why it is required though.
Thanks! That worked for me as well - V4 connects now work pretty well instantly. As you say, reason it should be needed isn't very clear.
Now all I need is to find a way to stop the hang when shutting down if I've forgotten to unmount the NFS shares. I've tried a predisconnect script for wicd, but while it slows the shutdown down a bit, it doesn't prevent the hang if the shares were mounted. Guess its back to google on that subject at least....
Paul.
Offline