Description of problem: I have a small home network including an NFS disk server and a couple desktops which use autofs via /etc/auto.misc to mount the NFS server. All boxen are on FC2 test 3 (I'm brave.) My auto.misc entry is this: alexopt -rw,nfsvers=3,tcp alex:/opt Key features: nfsvers=3, and tcp-only. Meanwhile the NFS server itself has open only the specific ports for mountd, rpc, and NFS. (i.e. rpc/111, nfs/2049, and mountd/10002 after hard-coding in /etc/sysconfig/nfs.) This command works fine: mount -t nfs -rw -o nfsvers=3,tcp alex:/opt /mnt/foo Mount is successful, **whether firewall on NFS server is running or not.** However, the autofs config above fails, *if and only* if the firewall is running on the NFS server. After some exploration and toying with the firewall rules on the server I discovered that when autofs attempts to mount /misc/alexopt, it is trying to use UDP to port 111. The NFS firewall has UDP ports shut, but the default firewall rule is a -j REJECT with icmp-host-prohibited, which autofs interprets as a "host is down" failure and then dies. If I disable the firewall on the NFS server or allow the server to return a normal error to the UDP request, autofs proceeds to try TCP. In a nutshell, autofs is defaulting to UDP, and if that fails, it tries TCP. I can only conclude from this that autofs is ignoring or dropping the "tcp" option to it. "noudp" doesn't help. Depending on how the firewall on the NFS server is configured, autofs will either fail on UDP and try to use TCP (which succeeds,) or else it will conclude that the server is down and fail. Version-Release number of selected component (if applicable): I just upgraded to FC2 test 3 yesterday, so whatever's in that. How reproducible: Always Steps to Reproduce: 1. Configure NFS server to use TCP-only NFSv3 and to have only TCP ports 111, 2049, and 10002 (for mountd open) 2. Test mount command above: success 3. Test autofs config above: fail 4. Disable firewall on server, re-test autofs: success 5. Add a -j LOG rule to NFS firewall, restart firewall, retest autofs: failure, but this time it logs the UDP attempt
When checking to see if a host is available, the autofs4 code tries to do an RPC ping using UDP. This just calls function 0, and then checks the latency of the test. So, your firewall scripts should be reworked to allow this packet through. Please let me know if this works for you. -Jeff
That's consistent with what I am seeing, and yes letting UDP in does work. However, I would call that behavior a bug. Here's my reasoning: 1. If I added the "tcp" option to the autofs config line, I wasn't just kidding around; I don't want it using UDP. :) I realize that's for the NFS mount and not for RPC, but still... NFS honors it, why doesn't autofs? 2. If I can mount the same NFS export directly from command line and THAT doesn't require an RPC ping over UDP, then why does autofs? I mean, what's it going to do? Refuse to perform the mount if the latency is over a certain amount? :) 3. If the intent of the RPC ping is just to see if the host is up or not (i.e. latency isn't the ultimate goal) then if the "tcp" option is set (or alternatively, perhaps "noudp") I would argue for a TCP ping. As a disclaimer, I don't really know why autofs is doing the ping in the first place. I suppose it could be using the latency to select a rsize/wsize or cache or something equally exotic, but that would be... well, exotic. So, maybe I'm just ignorant, but it seems like this is weird behavior for a tool which is just shorthand for mount/umount. But either way, tweaking the firewall rule does work. If you choose to close the bug, then perhaps a note in the documentation about this behavior is in order. (Unless one already is and I just forgot to RTFM. :)
You make some valid points. I will take this up with the author and see what we can come up with. FYI, the rpc_ping is a side effect of the replicated server functionality. It checks to see if each server in the list is alive, and also for the latency to each server. In this way, it can choose the best server from which to mount. This bit of code is generic, so even if you only have one server listed, you go through this path. Autofs itself, as you mentioned, in the end just calls mount. As such, it never has the need to interpret mount options. You are suggesting that autofs looks at the mount options to determine how it should behave itself. I'm not completely against this, but it is ugly.
Ahhhh... neat. I figured there was probably something I was missing about why autofs was even trying. Also a good point about parsing the mount options -- though I had assumed that autofs was already doing that. (i.e. -fstype=foo is an argument to autofs, not to mount, so autofs has to extract at least that much. Or so I assumed.) Anyway, a workaround exists, so... thanks much.
Hi Dan, Could you try the latest test rpm from my people page? It should take the rpc_ping logic out of the non-multi mount case. Also, I'll attach a test program here for you to run. Please give it a go and post the output to the bug report. I'm interested in the output from this program when your NFS server is configured for only TCP. Thanks! Jeff
Created attachment 100210 [details] rpc ping program which tests for nfs v2 and nfs v3 Compile with gcc rpcping.c -o rpcping Run as rpcping <hostname>
Thanks, Jeff! Here is the output of your rpcping.c program (gcc -g -Wall): [morrildl@eponymous morrildl]$ ./rpcpinger alex detected NFS V2 on host alex detected NFS V3 on host alex No more logs about unexpected UDP packets from the NFS server's firewall. Quick comment about rpcping.c, though: if the default firewall rule on the server is "-j DROP" intead of "-j REJECT --reject-with..." then rpcping (as you would expect) takes a while to timeout on the UDP requests since it gets no response at all. AFAIR, the rule on Fedora if you select "high security" version of the firewall during install is (or was) "-j DROP"; you might want to be aware of this. Requiring NFS servers not to use DROP is probably reasonable though; I have no issue with it at least. Anyway, autofs 4.1.2-6 from /~jmoyer/autofs/fc2/4.1.2-6/i386/ mounts the NFS drive quite happily, no problem. Ship it! :) Thanks for your help! - Dan
I notice this (by that I mean the patched autofs you have on your people page) hasn't made it into updates yet for FC2. Will it be included in FC3? Regards, - Dan
This was fixed in FC-3; any packages versioned 4.1.3-15 and later should work.