I’ve been tinkering with the NFS settings in the 2.6.26-series kernels, and wondering why in the heck things suddenly wouldn’t work my way … or the way I was used to.

No matter what I did, any attempt to mount a network drive was hanging for two and three minutes at a time, possibly longer — I cut the command short when it looked like it wasn’t working. As far as I could tell I had the same network settings as the Arch-to-Arch arrangement, so I couldn’t help but wonder why the Crux-to-Arch setup was misbehaving.

I tried recompiling two or three kernels, with the NFS module incorporated and separate, and I even rebuilt portmap and nfs-utils with different flags. Every time, it was the same, eternal, empty command prompt.

Until my quasi-ADHD tendencies took over, and I became distracted during one of those blind, hanging mount attempts. When I remembered what I was supposed to be doing, I checked the terminal and there was a nifty message telling me I needed to use the nolock option, or run statd.

Aha! So, rewriting my /etc/fstab to include that, or including it with the -o flag on a mount command suddenly makes things happy. Here’s what it looked like in action. …

mount 192.168.xx.xx:/home/kmandla /media/thinkpad -o nolock

And here’s what it looks like in my fstab.

192.168.xx.xx:/home/kmandla/ /media/thinkpad nfs noauto,nolock,users 0 0

Just like magic. I don’t know what I’m doing that I need that command, but I also don’t think I had been running my Crux machine as the client in my previous NFS arrangements. New style, new challenge. And usually I just have to wait to get the information I need, instead of repeatedly bashing my head against the screen.

Sometimes things just work right, and sometimes they just don’t. Sometimes I feel like Elvis, and sometimes I feel like Abbott.