Red Hat Bugzilla – Bug 128100
mount requires portmapper even with port=,mountport= options
Last modified: 2007-11-30 17:10:46 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Description of problem:
NFS mount to external nfs v3 server with hardcoded port= and
mountport= options fails with a "server down" message. Pulling the
mount binary from RH73 suceeds.
Line in /etc/fstab is:
192.168.10.2:/usr2/vbak/01632/fs /ez_fs nfs
soft,port=51768,mountport=51769,nolock 0 0
Error message is:
[root@v-1632 root]# mount-fc2 -a
mount to NFS server '192.168.10.2' failed: server is down.
[root@v-1632 root]# mount-rh73 -a
strace shows that mount failed right after trying to connect to
test system is FC2 with all updates running on UML kernel (2.4.26),
but I suspect this is a simple user-level bug in mount not ignoring
the portmapper error when port= and mountport= are included as options.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Setup an NFS server on hard-defined ports
2. Stop the portmapper on the NFS server
3. Try to mount the NFS mountpoint from FC2
4. Try mount from RH73 that works
I think I found the cause of this bug.
It lies in mount/nfsmount.c:parse_options(), where mnt_pmap->pm_prot
is NEVER set (either to TCP or UDP), but stays null, which triggers
the call to the portmapper (in probe_mntport())
parse_options() is located in the NFSv4 patch
I think the solution is simply to initialize mnt_pmap->pm_prot just
like nfs_pmap->pm_prot, see attached patch (the attentive reader
notices that the limited mount user interface prevents hybrid UDP/TCP
The attached patch is "quick and dirty", but solves the issue for me.
Created attachment 102202 [details]
initialize mnt_pmap->pm_prot (just like nfs_pmap->pm_prot)
This bug is a major problem for us as well, since it makes it
impossible to use NFS over SSH tunnels, for example. I agree with Marc
It would be *really* nice if an updated package could be released.
Anything I can do to help?
*** This bug has been marked as a duplicate of 140016 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.