Red Hat Bugzilla – Bug 170548
autofs mounts fail when using dhcp, ok with static ip
Last modified: 2008-08-02 19:40:33 EDT
Description of problem:
In the last two weeks or so autofs has failed for me on the only machine I have
that uses dhcp. Providing static IP information and changing BOOTPROTO=dhcp to
BOOTPROTO=none in /etc/sysconfig/network-scripts/ifcfg-eth0 and running "service
network restart" "service autofs restart" reliably fixes the problem. Just
changing back to BOOTPROTO=dhcp and restarting the services brings the problem back.
The NFS server is on the local network and its name resolution is via /etc/hosts.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Change to BOOTPROTO=dhcp
2. service network restart
3. service autofs restart
4. cd /net/barrel/usr/export/....
cd attempt fails after 30 sec or so. "No such file or directory"
Oct 12 15:14:22 localhost automount: >> /usr/sbin/showmount: can't get
address for barrel/usr/export
Oct 12 15:14:22 localhost automount: lookup(program): lookup for
Oct 12 15:14:22 localhost automount: failed to mount /net/barrel/usr/export
NFS automounts available on DHCP client.
The error message is familiar, but your reproducer is a bit strange! I use
autofs extensively with dhcp clients...
Anyway, please follow the directions on filing bug reports found on my people page:
Perhaps with some more detailed log information we can figure out what is going on.
Created attachment 120067 [details]
Created attachment 120068 [details]
Created attachment 120069 [details]
Oct 17 13:37:49 tux automount: >> mount: RPC: Timed out
I think that is the real problem. It probably exists independently of the
automounter. Have you tried simply nfs mounting the share by hand? I'd be
interested to know if that works.
From the logs, the automounter is working as it should. But, I'd be happy to
help in narrowing this down further, so we know who to bother next. ;)
Let me know if you can do the mount manually with a dhcp address.
No, I get:
root@tux:~# mount barrel:/usr/export /net/barrel/usr/export
mount: RPC: Timed out
The other end (barrel) seems to authenticate the rpc request ok.
Oct 17 13:55:23 barrel rpc.mountd: authenticated mount request from 192.168.0.15
8:627 for /usr/export (/usr/export)
ok, stupid question: when you configure your IP address statically, do you use
the same address? I.e. the one that dhcp gives you?
No. DHCP gives me 192.168.0.158
The static IP is: 192.168.0.10
OK. Is it possible that there are firewalling rules in effect that would cause
problems? Can the server do a reverse lookup on the dhcp address? (I'm not
sure if the latter matters at all, but it certainly can be a source of delays).
Could you get a packet trace of the failed mount? Something like the following
tethereal -w /tmp/data.pcp client server
Then we can hopefully figure out where in the chain things are going wrong.
Not a firewall problem. I stopped iptables at both ends.
No, reverse lookups won't work. Neither machine is in DNS.
I'll get back to you with a packet trace when I can work out how to
make tethereal work.
Sorry, I typed above. The tethereal line should be:
tethereal -w <capturefile> host <servername>
where capturefile is replaced by the file you want to use to store the packet
capture, and server name is the name of the nfs server. This should be run on
the client, as root.
OK. I'll attach the result of:
tethereal -i eth0 -w /tmp/capture host 192.168.0.6
when I tried:
root@tux:~# cd /net/barrel/usr/export
-bash: cd: /net/barrel/usr/export: No such file or directory
Created attachment 120080 [details]
result of: "tethereal -i eth0 -w /tmp/capture host 192.168.0.6"
Created attachment 120083 [details]
same test with static ip
In the failed transaction, message #65 is a RST.
In the successful transaction, the corresponding message #67 is an ACK.
The ethereal trace in Comment #15 (capture) shows the protocol being used
for the mount is TCP but the server does not seem to support that
protocol (Note: Packet 26 and its replay Packet 28).
The ethereal trace in Comment #16 (capture2) shows the protocol being
used is UDP and since the server support UDP, thats why the mount
So to prove this theory, I would like to add the '-o udp' to
the mount command in Comment #7 so it would be:
mount -o udp barrel:/usr/export /net/barrel/usr/export
also please post the output of 'rpcinfo -p <server>' which
will show what the server supports and what it does not.
Question: Is this a Linux server?
Yes, only udp is supported.
Using the working static IP configuration, "mount -o udp ...." succeeds and
"mount -o tcp ..." fails
I'll attach the output of 'rpcinfo -p <server>' next.
The server is Redhat 9:
So why doesn't udp work if the client is started with dhcp ?
Created attachment 120086 [details]
output of: rpcinfo -p barrel
One more question: what version of util-linux are you running?
On the client (tux): util-linux-2.13-0.5.pre4
On the server (barrel): util-linux-2.11y-9
steve, did you see this last update? util-linux version (on the client) is
2.13-0.5pre4. Do you know which patches are in that one?
Steve, I'm reassigning this to you so it doesn't get lost.
Is this still happening with a more recent nfs-utils rpm?
A verion that has the mounting code included?
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.
If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.
The process we're following is outlined here: