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
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
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.
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.
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
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
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
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
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
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.
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.
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>
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
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!
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?
This was fixed in FC-3; any packages versioned 4.1.3-15 and later should work.