Red Hat Bugzilla – Bug 132709
NFS client can't reconnect after server reboots
Last modified: 2015-01-04 17:09:44 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Description of problem:
If you mount one (or several) filesystems from one server running
FC3test2-ish on a client running the very same software, and the
server reboots because you typed reboot on the wrong window, even
after the server comes back up, the client won't ever regain access to
the previously-mounted mount point. You have to explicitly umount it
and then mount it again. Kind of a problem if the client was in the
middle of an NFS install and you can't even switch to VT2 to attempt
to remount it :-)
I've experienced the same problem with autofs-mounted NFS mounts as well.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Mount a filesystem over NFS from an FC3test2 server on an FC3test2
2.Reboot the server
3.Try to access the filesystem after the server comes back up
Actual Results: mount point will be stale, or will block, depending
on some conditions I can't figure out
Expected Results: It should reconnect after some time, but it doesn't
even seem to have tried, after more than half an hour
FWIW, I have some evidence that the problems I'm experiencing have to
do with iptables connection tracking. I have iptables set up to let
UDP packets from port 2049 pass through from the server, as well as
TCP syn packets from port 2049, as well as established tcp
connections. Whenever I run into the problem, the mount point has
been idle for quite some time (hours; no clue on why autofs wouldn't
have unmounted it), and attempts to access the filesystem will trigger
log messages from iptables on the client, denying server replies from
making it to the NFS client code in the kernel. Sometimes, after a
time out, the connection is restablished. But not always.
I think it's safe to disregard this as a kernel problem. I have now
to figure out how to get autofs to use some keepalive NFS mount
option, or to force the use of udp, or maybe let tcp packets in
regardless of conntrack.
the current 2.6.9 based update has quite a few NFS related fixes, can you see if
this problem is repeatable there ?
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.
There are a large number of inactive bugs in the database, and this is the only
way to purge them.