Description of problem:
I tried to mount some of my NFS shares loacated behind a firewall
using "-o udp" option:
user@linux]$ mount -o udp server:/directory/folder /mnt/nfs/folder
udp ports were specially opened on the firewall but tcp ones weren't.
Mount operation hanged for ~ 5 minutes. The mount connection was
displayed in "netstat -a" as went over tcp protocol.
Interesting fact that the same mounting command worked just fine on
SuSE 9.1 and SLES 9.0 distros - they have util-linux version 2.12-72
and , as well as FC2, kernel 2.6. However if I didn't specify
explicitly "-o udp" behaviour on SUSE distros was the same. When I
replaced /bin/mount,/bin/umount binaries on FC2 with the same ones
from SUSE9.1 distro, the issue went away. Also the problem presents
in util-linux from FC3 and is reproduced on EM64T architecture.
Version-Release number of selected component (if applicable):
util-linux-2.12-18 - FC2
util-linux-2.12a-16 - FC3
Steps to Reproduce:
1. Install FC2
2. Try mount any NFS share over udp -
[user@linux]$ mount -o udp server:/directory/folder /mnt/nfs/folder
3.Use netstat for example:
[user@linux]$ netstat -a
There will be your nfs connection but established over tcp protocol.
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address
State PID/Program name
it is here ===> tcp 0 1 FC2.intel:996 server.int:4046
tcp 0 0 *:ssh *:*
tcp 0 0 localhos:x11-ssh-offset *:*
tcp 0 0 localhost:6011 *:*
tcp 0 0 localhost:6012 *:*
tcp 0 0 nntvtune20.inn.inte:ssh abudanko-linux.in:33368
tcp 0 0 nntvtune20.inn.inte:ssh abudanko-linux.in:33369
tcp 0 144 nntvtune20.inn.inte:ssh abudanko-linux.in:33372
udp 0 0 *:32768
udp 0 0 *:963
udp 0 0 *:sunrpc
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node PID/Program
unix 4 [ ] DGRAM 2673
unix 2 [ ACC ] STREAM LISTENING 2994
unix 2 [ ] DGRAM 2742
unix 2 [ ] DGRAM 2682
I am of the opition that is this more of a firewall bug
than an NFS problem becuase neither FC2 or FC3 mount command
ignore the udp option.
OK, but the same utilities work perfect on SUSE. Anyway I can't
exactly know what the problem is in, but this only happens on FC2/3
Try 'service iptables stop' and then the mount....
Of course, I disabled all local firewall services and iptables sevice
first time, before mounting, but it did'not help.
I didn't didn't mean to in insultive... :) I just wanted to cover the
Now what troubles me with the
"it is here ===> tcp 0 1 FC2.intel:996 server.int:4046 "
is 4046 is the not the port that NFS listens on, 2049 is the port
so I would have expected some like: "FC2.intel:996 server.int:nfs" or
"FC2.intel:996 server.int:2049" if TCP was really being used....
First, you are right - 4046 is not the apropriate port for nfs - the
2049 port is, but the question is why mount tried to operate over tcp
whereas I explicitly made it to connect over udp.
Second, "FC2.intel:996 server.int:nfs" from your previous message
indeed appears but only after about 5 minutes and nfs connection is
really established then.
My question is why it hangs so long, while other utilities operate
much more faster (I mean other distros).
Yes this is a problem... looking at a network trace it seems
rpc.mountd creates a TCP connection to the server even when
the "-o udp" mount is used.
Created attachment 107572 [details]
A patch that makes both mount and umount adhere to the current IP protocol.
To make NFS mount and umount firewall friendlier, the communication
between rpc.mound and the nfs server need to used the same IP protocol
that is given on the command line.
Created attachment 107604 [details]
.spec file for applying suggested above patch and building rpm
replace original util-linux.spec with the new one
I tried your fix and it indeed worked perfect for me, it is good
job :), thanks! I also attached new .spec file for building fixed
Fixed in util-linux-2.12-19.i386.rpm for FC2
Fixed in util-linux-2.12a-17.i386.rpm for FC3
*** Bug 128100 has been marked as a duplicate of this bug. ***
The fixed util-linux package is *still* not available in
It should be available now...
>It should be available now...
Well, it's not in
It's not in
"CURRENTRELEASE" means: "The problem described has already been fixed and can be
obtained in the latest version of our product."
The latest version of Fedora is FC3, and the bug is still present in FC3. No
fixed util-linux package has been released as stable for FC3, at least not in
So, closing this bug with CURRENTRELEASE seems wrong to me.
I'm not sure why these updates are not being pushed out but
I put the latest rpm and srpm in http://people.redhat.com/steved/bz140016/
No one requested that these be pushed from final to testing... is that a request?
I guess that was my fault.... please push this out...
The update is available for FC2 and FC3 now. Thanks.
However, I've discovered that the same problem exists in RHEL4. Should I open up
a new bug for this? Using the package util-linux-2.12a-23.i386 from FC3 seems to
work, but I assume that's not a supported solution.
I've opened up a new bug for this issue on RHEL4: