Bug 184225 - NFS server exported filesystem not mounted
NFS server exported filesystem not mounted
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: nfs-utils (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2006-03-07 09:58 EST by Rajdeep Sengupta
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 14:46:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Data captured from ethereal (21.79 KB, application/octet-stream)
2006-06-14 11:11 EDT, Rajdeep Sengupta
no flags Details

  None (edit)
Description Rajdeep Sengupta 2006-03-07 09:58:25 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

Description of problem:
We have a NFS server based on NFS utils version nfs-utils-1.0.6-33EL. The server has following exported filesystem.
/home *(rw)
/home1 *(rw)
/home2 *(rw)
/home3 *(rw)
/home4 *(rw)
/home5 *(rw)
/home6 *(rw)
/home7 *(rw)

Now we have many linux clients which mounts the server exported filesystem at random. Out of this clients, few clients are unable to mount all filesystem. In some clients only 2 filesystem is avialable, in somecases it is 3 or 4 but not all. And this problem starts all of a sudden. Once you see this issue in a particular client, the problem remains evenif you reboot the client. The only way you can fix it is by changing the ip address of the client and then reboot it.
This has become a regular issue and it happens on any machine irrelavant on the version of the OS of the client. We tried to look into the details and found that somehow the server keeps track of the mounted machines (IP address) in /var/lib/nfs/rmtab and xtab files. 
This has become a real pain for us

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

How reproducible:

Steps to Reproduce:
1.Arbitrarily one client will start behaving like this at one point of time.
2.you could see that all the filesystem of the server is not available from the client machine
3.Even reboot will not help anyway
  The only way to get rid of it si to change the ip address of the client machine.

Additional info:
Comment 1 Steve Dickson 2006-03-18 21:40:30 EST
Are there any error or warnings being logged in /var/log/messages on either the 
server or client?
Comment 2 Rajdeep Sengupta 2006-03-19 00:21:30 EST
No there is no relevant message in the /var/log/message file
Comment 3 Steve Dickson 2006-04-15 15:00:43 EDT
Would it be possible to get a binary tethereal network trace of this occurring
(i.e. on the server, ethereal -w /tmp/data.pcap host <client> )....

It is very bizarre that you have to reboot client to for it succeed in doing
nfs mounts... 
Comment 4 Rajdeep Sengupta 2006-06-14 11:11:24 EDT
Created attachment 130863 [details]
Data captured from ethereal

The captured data from the file server (machine name "shark" with IP when the client was trying to access home3(machine name "cyan"
with ip
This time except home3 all the other 8 exported home area were visible from
Comment 5 Steve Dickson 2006-07-18 14:46:55 EDT
Is there any type of error message in /var/log/messages on the server?
Comment 6 Rajdeep Sengupta 2006-07-19 04:07:24 EDT
No, ther is no error in /var/log/messages 
Comment 7 Steve Dickson 2006-07-20 08:55:42 EDT
I'm wondering if the problem is the server is so busy that is simply
drops the mount request which causes the client to fail, without retrying.
There has been some recent changes to the RHEL3 mount command that
will cause the mount to retry. So please update your util-linux to latest
RHEL3 version which I believe is util-linux-2.11y-31.18
Comment 9 RHEL Product and Program Management 2007-10-19 14:46:51 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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