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 this case. Scenario: 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>, tcp,nfsprog=100003,nfsvers=3,port=2049 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 release.
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