Red Hat Bugzilla – Bug 172308
NFS mount tries portmap even when mountport=/port= specified
Last modified: 2007-11-30 17:07:21 EST
Description of problem:
When trying to mount an NFS export, attempts to bypass portmap by manually
specifying the nolock, mountport= and port= options fail if portmap cannot be
reached. I do not think it should be necessary that we talk to portmap in
stationA is exporting /exports to stationB, has nfs and nfslock started.
The rpc.mountd service is bound to port 645. nfsd is bound to port 2049.
The following netfilter rules are set on stationA:
iptables -I INPUT -s stationB -p tcp --dport 111 -j REJECT
iptables -I INPUT -s stationB -p udp --dport 111 -j REJECT
stationB runs the following command:
mount -o nolock,mountport=645,port=2049 stationA:/exports /mnt
tethereal capture when using mount for util-linux-2.12a-16.EL4.12:
0.000000 192.168.1.20 -> 192.168.0.19 TCP 32989 > sunrpc [SYN] Seq=0 Ack=0
Win=5840 Len=0 MSS=1460 TSV=165772015 TSER=0 WS=2
0.000966 192.168.0.19 -> 192.168.1.20 ICMP Destination unreachable
0.005649 192.168.1.20 -> 192.168.0.19 TCP 810 > sunrpc [SYN] Seq=0 Ack=0
Win=5840 Len=0 MSS=1460 TSV=165772021 TSER=0 WS=2
0.006209 192.168.0.19 -> 192.168.1.20 ICMP Destination unreachable
0.006280 192.168.1.20 -> 192.168.0.19 Portmap V2 GETPORT Call
0.006708 192.168.0.19 -> 192.168.1.20 ICMP Destination unreachable
So mount tries to talk to stationA's portmap using TCP twice, gets ICMP
unreachable both times due to the REJECT rule sending admin-prohibited.
Then it tries UDP. Detailed capture shows mount trying to get the port for
RPC program 100003 (NFS) version 3, even though we specified that on the
command line and shouldn't be asking portmap for it. Then we get an ICMP
unreachable for the UDP message and mount exits with
mount to NFS server 'station19.example.com' failed: server is down.
The port= option should be honored by mount, and portmap should not be contacted
for this information.
Yeah... this appears to be a bug...
I did notice that the packet capture appeared slightly different with the stock
util-linux we shipped with RHEL4 GA; I think it made one connection attempt to
111/tcp, got the ICMP rejection from the firewall, and then stopped trying, but
I don't have the hardware/software in front of me to reproduce it again.
This did function as expected in mount for RHEL3 GA, as I recall.
Any news here? is there any bugfix available?
After further review, its not clear that can eliminate any and all
communication to the portmapper. Not only is the port needed
but the protocol and version is also needed from both the remote
mountd and nfsd. With that said, does the following work?
mount -o mountprog=100005,mountvers=3,mountport=<port>,
since thats all the information needed from the remote portmapper.
Nope. The mount command still tries to talk to port 111/tcp, and when it
recieves the TCP reset (or ICMP port unreachable) from the target system, it
stops trying to do anything.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
WRT comment #7 I'm thinking this is exactly what mount should do on
restest and ICMP errors. These errors generally mean a machine or
service has restarted so in those case I believe it does make sense
to ask the portmapper for updated information...
So I'm going to close this is NOTABUG...
Requires the tcp option:
mount -o tcp,port=2049,mountport=645 stationX:/share /mountpoint