Bug 184225 - NFS server exported filesystem not mounted
Summary: NFS server exported filesystem not mounted
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: nfs-utils
Version: 3.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-03-07 14:58 UTC by Rajdeep Sengupta
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-19 18:46:51 UTC
Target Upstream Version:
Embargoed:


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

Description Rajdeep Sengupta 2006-03-07 14:58:25 UTC
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):
nfs-utils-1.0.6-33EL

How reproducible:
Always

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-19 02:40:30 UTC
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 05:21:30 UTC
No there is no relevant message in the /var/log/message file

Comment 3 Steve Dickson 2006-04-15 19:00:43 UTC
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 15:11:24 UTC
Created attachment 130863 [details]
Data captured from ethereal

The captured data from the file server (machine name "shark" with IP
192.168.3.120) when the client was trying to access home3(machine name "cyan"
with ip 192.168.2.11)
This time except home3 all the other 8 exported home area were visible from
client.

Comment 5 Steve Dickson 2006-07-18 18:46:55 UTC
Is there any type of error message in /var/log/messages on the server?

Comment 6 Rajdeep Sengupta 2006-07-19 08:07:24 UTC
No, ther is no error in /var/log/messages 

Comment 7 Steve Dickson 2006-07-20 12:55:42 UTC
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 Program Management 2007-10-19 18:46:51 UTC
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:
http://www.redhat.com/security/updates/errata/
 
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.