<br><div class="gmail_quote">On Tue, Dec 2, 2008 at 10:37 PM, Collins Richey <span dir="ltr"><<a href="mailto:crichey@gmail.com">crichey@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We've had a long day debugging an NFS problem, and we're nowhere near<br>
figuring it out. Here's the setup.<br>
<br>
We have a number of RHEL3/RHEL4 servers and workstations that share<br>
clearcase data stored on three separate servers mounted via NFS. The<br>
RHEL4 servers are at varying maintenance levels (U3, U4, U7), and<br>
upgrading the problem servers to U7 does not help. The three problem<br>
servers (A, B, C) each have a large directory (D1 on A, D2 on B, and<br>
D3 on C). A mounts D2 and D3, B mounts D1 and D3, and C mounts D1 and<br>
D2). All workstations and several other servers (RHEL3/4/5) mount D1,<br>
D2, and D3.</blockquote><div><br><br>Ok, so you have a bunch of crossmounts. The version of NFS should be what is important to maintain correct communication in the protocol, unless you think there's a bug somewhere. (Which is certainly quite possible.)<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The problem appeared this morning when I needed to restart NFS on a<br>
related server to change the mount status of it's directories (let's<br>
call this server D and directory D4. This server does not share D1,<br>
D2, or D3, but all of the servers that mount D1, D2, D3 also mount D4.<br>
As soon as I restarted NFS on D and attempted to restart netfs on<br>
another server (E), E refused to mount D1, D2, D3 claiming that server<br>
refused due to permissions. All other servers and work stations<br>
continue to use the NFS mounted D1, D2, D3, D4 continue to work with<br>
no errors. Any system that is booted or netfs restarted, declines to<br>
mount D1, D2, D3, but D4 mounts OK. In every case the exporting server<br>
produces the same message whether the mount is successful or failed.<br>
If new exports are created on A, B, or C and NFS restarted, these<br>
exported directories also fail to mount anywhere.</blockquote><div><br>Does exportfs report the expected exports? Would an exportfs -r help? After attempting to mount, does showmount indicate things are mounted or not? Can you at least do an nfs mount to localhost?<br>
<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
No changes to the exports or software on any of these servers in the<br>
past few months. NFS on other servers and workstations continues to<br>
work without a hitch. Each of the problem servers has been rebooted,<br>
but that has no effect. Firewalls have been stopped, so that is not<br>
the answer.</blockquote><div><br>And you don't have any weird network setup with ipvsadm, etc. to be worried about? <br></div><div><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Does anyone have any clues or helpful hints about interpreting strace<br>
data for the problem?. From the client side (mount request), after a<br>
lot of setup, the client opens a TCP socket and passes the requesting<br>
ip address / name to the server, gets a response, opens a UDP socket,<br>
passes the address/name again, and gets a response. The last response<br>
is different for the successful / unsuccessful case, but I haven't<br>
been able to find a way of interpreting this. If successful, the<br>
actual mount command is issued and mtab is updated. If unsuccessful,<br>
no mount is issued and the error message is generated.<br>
<br>
I've also straced rpc.mountd on the exporting server, but I know even<br>
less about this.<br>
<br>
Another quirk. In both cases the strace logs an attempt to locate a<br>
program /sbin/mount.nfs which does not exist.<br>
<br>
A mystery within a riddle wrapped in an enigma.<br>
<br>
The only relevant google entry we found suggested that reboot cured the problem.</blockquote><br>It sounds like the problem is on the the nfsd side. I would have suspected a network issue, but since you seem to know that the server is sending back a deny response, you know that it's not a case. I would probably investigate the machine to try to figure out why it might be denying connections. Could it be something as simple as nfsd having reached its max number of connections?<br>
<br>Angelo<br><br></div><br>