Red Hat Bugzilla – Bug 116510
After mounting any OS's(other than a RHEL 3 NFS server) nfs version 3 server, our RHEL 3 ws update one nfs client hangs
Last modified: 2008-08-02 19:40:34 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; YComp
188.8.131.52; .NET CLR 1.1.4322)
Description of problem:
This is the scenario.
We have an HP-UX NFS server. After mounting the NFS server
successfully using our newly installed RHEL 3 WS(ia64), we try to do
an ls on the mounted directory and the system hangs. We can
successfully mount the HP-UX nfs server using any other os and/or
We thought it may be an incompatibility between RHEL 3 and HPUX so we
did the following. We have exported filesystems from a RH AW 2.1
machine and can successfully mount the directory, but when we try to
perform any access on the mounted directory it hangs. Any other
OS/Distribution can successfully mount and access the RH AW 2.1 NFS
No firewall rulesets are setup on any of the boxes.
The wierd thing is this: We installed another RHEL 3 WS on another
machine and both RHEL 3 WS machine can mount and access each other.
So it looks like RHEL 3 WS IA64 can only mount and access another
RHEL 3 WS/AS.
We have made sure that firewall rulesets are disabled and that UDP is
being used to mount.
This is holding up our upgrade since our central NFS server is HP-UX.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Mount any remote NFS SERVER that is not RHEL 3 based to /tmp/test
2. cd /tmp/test
Actual Results: It Hangs
Expected Results: We should be able to successfully mount and access
a mounted directory.
Would it be possible to post a bzip2-ed ethereal trace of the hang?
Created attachment 99161 [details]
The ethereal capture of rhew 3 client trying to mount hpux nfs server
It seems to be hanging on a readdirplus call to the server.
Is there any type of errors being logged on the server?
No messages are being generated on the server and we have turned on
debugging on the hpux box's nfs subsystem.
Ok... But this really looks like a server problem... Please
send HP the ethereal trace and ask them why they are not
responding to our readdirplus request...
I am going to have to disagree with you on this one.
Like I said in the original bug report, we made one of our RHAW 2.1
machines an NFS server, we exported a directory from the RHAW 2.1 box.
We tried mounting the RHAW ia64 2.1 box using the RHEL 3 ia64 client,
and it was the SAME EXACT PROBLEM. So the problem is NOT with the HPUX
server. It is with the RHEL 3 ia64 client machine. Like I also said,
the only thing a RHEL 3 i64 client can mount is another RHEL 3 ia64
Ok... I would like to handle this as two different problems.
So could you please post the ethereal trace of the RHEL3
client to AS21 server hang.
Obviously this does not happen in our testing, so I'm very
curious as to why this hang is occurring....
I'm experimenting the same problem on a RHEL 3 ES on i686 platform,
mounting a NFS-exported directory from a RedHat 9 Server. The NFS
client just hang for a few minutes, then recover and (sometimes)
cancel the copy. All I see when the client is hung is a few "UDP
fragment" for NFS between the server and the client.
I have this same exact problem with a NAS storage running Windows
2003 from Dell.
Created attachment 100487 [details]
Ethereal trace of an "hanged" NFS connection (RHEL 3 - RedHat 9)
I've just uploaded an Ethereal trace of a "hanged" NFS mount. There
are bunchs of about 7 UDP datagram every few seconds, but the file
transfert is not advancing.
[problem on i386 also]
I have a possibly related issue where mounting a an NFS share on a
RHEL-3.0 AS server works well, then after some time, on the nfs client
running ls -l /path/to/share results in ls hanging and remains
unkillable, even with kill -9. Adding "intr" to the mount options
prevents the unkillable situation, but the problem still occurs. The
nfs-client is an almost identical RHEL-3.0 AS box. The "local"
storage on the nfs server is an EMC CX600 device mounted through EMC's
/dev/emcpower[x] special device. At all times, the entire subtree of
the share on the server is accessible, i.e., (nfs-server)% ls -alR
/nfs/exported/dir, successfully returns all subdirs/files.
Furthermore, shell scripts residing on the nfs share can be run even
though doing "ls script.sh" will hang... hard....
The same problem occurs when mounting disks from a Debian 3-Ware RAID
server to RHEL (Xeon/P4) clients. We moved the server to Debian
because of another bug:
but this apparently means we'll have to go back to using RHEL for the
Is this still an issue on recent RHEL3? Say, RHEL3U9?
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.