This is an unusual situation where I have an NFS server currently serving out MULTIPLE clients over several variants of Linux and UNIX successfully (world permissions) except for a SINGLE client. Even the other Linux (SuSE) clients in the same room are mounting successfully with defaults without incident. Server and workstation are on the same subnet with NO firewall and (I don't believe) any routers between them. The "traceroute" command shows a single hop directly to the server and nothing in between.
THIS client 'just stopped working' and the only error from the /var/log/messages file indicates that it "could not contact the NFS server: operation timed out."
It all gets fixed if I use 'tcp' as the mount option in /etc/fstab and manually, bypassing UDP altogether. However this client had been working up until this week and AFAIK no changes were made to this client. Again, other Linux clients IN THE SAME ROOM and ON THE SAME SWITCH are doing just fine and not having this problem!
Even the client system itself mounts two other NFS file systems from a different server without this workaround (IRIX server, believe it or not) but cannot mount the SuSE server without using the 'tcp' flag and bypassing udp protocol.
Any clues here? I've googled this particular issue in bug reports but to no avail. Here's the output from the client side of what's being served:
As I understand it, TCP is better anyway, given that TCP is tuned on your network for LAN access (see TCP/IP tuning guides).
Still, that doesn't solve the problem.
You didn't mention what was running on the server. What OS, version, distribution, and kernel version, please? On the client, what does "uname -a" report? Also what version of NFS is being used on each? You can use "rpm -qi nfs-tools" or similar to get that information.
The server is running SuSE and the client is running Red Hat.
I know the server is "serving out" NFS versions 2 and 3 (see rpcinfo from above) but I'm not 100% sure what the client is using. rpcinfo for the client reveals the following:
It occurred to me that both Suse and RedHat distributions have automatic updates. It's possible they automatically updated some server tools which triggered an incompatibility. Did you check to see that modules and tools for nfs are still the same? That is, they have an older timestamp. Post the output of these commands:
I ran this command set on the client, and received zero output as a result.
The rpm query yielded nothing for nfs-tools, and the find command also came back with nothing there either.
The client is definitely not set up for auto updates, as it is connected only internally on corp. LAN and does not access the Internet.
The server is also tightly controlled, and auto-updates are turned off on that system. Updates on that particular NAS server are tightly controlled, here.
As far as I know, no major updates were done to either. The client *could* have had the opportunity to slip by, but I just verified that this client is definitely NOT on the corporate LAN. It is firewalled inside of our "dev-only" network.
If you have it working with TCP, it is now suggested that be used anyway. It actually has better performance, when the server and client are properly tuned.
Red Hat AS 3 (I guess you can call it RHEL 3, but that's incorrect) has a bug in it's broadcom, tg3 driver, your interface will probably be bouncing a lot... afaik, there is no fix for it. Move to RHEL 4 or 5 if you can.
If you're not using the tg3 driver, then I don't know what the issue is....