Bug 200312 - fstab mounting of different nfs servers broken
fstab mounting of different nfs servers broken
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: util-linux (Show other bugs)
3.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Steve Dickson
Brian Brock
:
: 200529 203117 (view as bug list)
Depends On:
Blocks: 190430
  Show dependency treegraph
 
Reported: 2006-07-26 15:55 EDT by Josko Plazonic
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2006-0657
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-28 10:23:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace of failing mount (21.42 KB, text/plain)
2006-07-28 13:44 EDT, Jeff Layton
no flags Details

  None (edit)
Description Josko Plazonic 2006-07-26 15:55:35 EDT
Description of problem:
If two or more different nfs servers are listed in fstab mount 2.11y-31.18
cannot mount them both - it will only mount the first one in most cases (as long
as rpc.mountd is listening on different ports on these servers).

The reason is addition of util-linux-2.11y-nfsmount-mountd-udp.patch in
2.11y-31.18 release.  What happens is that portmap is queried on the first
server, that info is cached in a static struct and not reset when mounting the
second server. As a result of that bug mount uses the rpc.mountd port of the
first server to talk to the rpc.mountd on the second server.  I include relevant
strace that shows this.

A brute force fix is:
--- util-linux-2.11y/mount/nfsmount.c.jpfix     2006-07-26 14:01:18.000000000 -0400
+++ util-linux-2.11y/mount/nfsmount.c   2006-07-26 14:05:45.000000000 -0400
@@ -267,6 +267,8 @@
        time_t prevt;
        time_t timeout;

+
+       pmaps = NULL;
        /* The version to try is either specified or 0
           In case it is 0 we tell the caller what we tried */
        if (!*nfs_mount_vers)


Version-Release number of selected component (if applicable):
2.11y-31.18

How reproducible:
check steps

Steps to Reproduce:
1. Have two different nfs servers in fstab, make sure they have mountd listening
on different ports - important.
2. mount -a 
  
Actual results:
Only the first nfs mount will be mounted.  Second mount will fail with errors
(like "mount: RPC: Unable to receive; errno = Connection refused").

Expected results:
All nfs mounts should be mounted.

Additional info:
connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("172.16.16.2")}, 28) = 0
recvfrom(3, "i\377\205\200\0\1\0\1\0\6\0\6\4maia\3sns\3ias\3edu\0\0"..., 1024,
0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.16.16.2")},
[16]) = 258
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")},
16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("172.16.16.9")}, 16) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(1003),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "@\226s\330\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\3\0\0\0\1"..., 108, 0,
{sa_family=AF_INET, sin_port=htons(32767), sin_addr=inet_addr("172.16.16.9")},
16) = 108
recvfrom(3, "@\226s\330\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8800,
0, {sa_family=AF_INET, sin_port=htons(32767),
sin_addr=inet_addr("172.16.16.9")}, [16]) = 68
bind(4, {sa_family=AF_INET, sin_port=htons(1004),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("172.16.16.2")}, 28) = 0
recvfrom(3, "Y\227\205\200\0\1\0\1\0\6\0\6\4maia\3sns\3ias\3edu\0\0"..., 1024,
0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.16.16.2")},
[16]) = 258
bind(3, {sa_family=AF_INET, sin_port=htons(1005),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "n\264\344B\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\2\0\0\0\1"..., 108, 0,
{sa_family=AF_INET, sin_port=htons(32767), sin_addr=inet_addr("172.16.16.9")},
16) = 108
recvfrom(3, "n\264\344B\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8800,
0, {sa_family=AF_INET, sin_port=htons(32767),
sin_addr=inet_addr("172.16.16.9")}, [16]) = 60
bind(5, {sa_family=AF_INET, sin_port=htons(1006),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("172.16.16.2")}, 28) = 0
recvfrom(3, "\7\'\205\200\0\1\0\2\0\6\0\6\10mailhost\3sns\3ias\3ed"..., 1024, 0,
{sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.16.16.2")},
[16]) = 284
bind(3, {sa_family=AF_INET, sin_port=htons(1007),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "P\27\33i\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\3\0\0\0\1\0"..., 108, 0,
{sa_family=AF_INET, sin_port=htons(32767), sin_addr=inet_addr("172.16.17.19")},
16) = 108
recvmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(32767),
sin_addr=inet_addr("172.16.17.19")},
msg_iov(1)=[{"P\27\33i\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\3\0\0\0\1\0"..., 108}],
msg_controllen=44, {cmsg_len=44, cmsg_level=SOL_IP, cmsg_type=, ...},
msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 108
Comment 1 Steve Dickson 2006-07-27 10:44:06 EDT
Fixed in mount-2.11y-31.19
Comment 2 Jeff Layton 2006-07-28 13:29:36 EDT
*** Bug 200529 has been marked as a duplicate of this bug. ***
Comment 3 Jeff Layton 2006-07-28 13:44:49 EDT
Created attachment 133254 [details]
strace of failing mount

I just tried the package in 3.0E-errata-candidate and am still seeing the same
problem. Here's an strace from a failed "mount -t nfs -a". The first mount that
it attempts is successful, but subsequent mounts still fail.

It looks like the problem is that it consults the portmapper for the first
server to get the mountd port, and then assumes that all other servers are
using the same port.
Comment 4 Josko Plazonic 2006-07-28 13:54:46 EDT
That's exactly what is happening - maybe I didn't explain it clearly enough but
read above.  I also included a fix above that is confirmed to work even though
it is not very elegant.

BTW this is probably a significant enough regression that you should  probably
consider pushing this fix earlier rather than later - but don't mind me...
Comment 5 Jeff Layton 2006-07-28 14:59:28 EDT
Oops, the patch that went into -31.19 *does* seem to correct the problem. I had
updated the wrong package when testing before.
Comment 6 Karel Zak 2006-08-18 10:52:31 EDT
*** Bug 203117 has been marked as a duplicate of this bug. ***
Comment 13 Red Hat Bugzilla 2006-08-28 10:23:12 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0657.html

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