Bug 128100 - mount requires portmapper even with port=,mountport= options
mount requires portmapper even with port=,mountport= options
Status: CLOSED DUPLICATE of bug 140016
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-17 15:02 EDT by Doug Dumitru
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 14:04:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
initialize mnt_pmap->pm_prot (just like nfs_pmap->pm_prot) (1.30 KB, patch)
2004-07-26 09:22 EDT, Marc Herbert
no flags Details | Diff

  None (edit)
Description Doug Dumitru 2004-07-17 15:02:28 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Gecko/20040707 Firefox/0.9.2

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
[root@v-1632 root]# 

strace shows that mount failed right after trying to connect to
192.168.10.2:111 portmapper.

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):
util-linux-2.12-18

How reproducible:
Always

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
Comment 1 Marc Herbert 2004-07-26 09:20:19 EDT
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
"util-linux-2.11z-01-nfs.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
mountd/nfsd connections)

The attached patch is "quick and dirty", but solves the issue for me.

Comment 2 Marc Herbert 2004-07-26 09:22:03 EDT
Created attachment 102202 [details]
initialize mnt_pmap->pm_prot (just like nfs_pmap->pm_prot)
Comment 3 Peter Åstrand 2004-10-15 06:41:17 EDT
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
Herberts conclusions. 

It would be *really* nice if an updated package could be released.
Anything I can do to help?
Comment 4 Steve Dickson 2004-12-10 20:20:37 EST

*** This bug has been marked as a duplicate of 140016 ***
Comment 5 Red Hat Bugzilla 2006-02-21 14:04:29 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.