From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040809 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): kernel-2.6.8-1.541 How reproducible: Always Steps to Reproduce: 1.Mount a filesystem over NFS from an FC3test2 server on an FC3test2 client 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 Additional info:
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'. Thank you.
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. Thank you.