Bug 128100 - mount requires portmapper even with port=,mountport= options
Summary: mount requires portmapper even with port=,mountport= options
Keywords:
Status: CLOSED DUPLICATE of bug 140016
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: 2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Steve Dickson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-07-17 19:02 UTC by Doug Dumitru
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-21 19:04:29 UTC
Type: ---
Embargoed:


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

Description Doug Dumitru 2004-07-17 19:02:28 UTC
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 13:20:19 UTC
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 13:22:03 UTC
Created attachment 102202 [details]
initialize mnt_pmap->pm_prot (just like nfs_pmap->pm_prot)

Comment 3 Peter Åstrand 2004-10-15 10:41:17 UTC
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-11 01:20:37 UTC

*** This bug has been marked as a duplicate of 140016 ***

Comment 5 Red Hat Bugzilla 2006-02-21 19:04:29 UTC
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.