Bug 166458 - relocating/restarting nfs services results in permission denied (EACCES in lstat)
Summary: relocating/restarting nfs services results in permission denied (EACCES in ls...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Cluster Suite
Classification: Retired
Component: rgmanager
Version: 4
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks: RHEL4NFSFailover
TreeView+ depends on / blocked
 
Reported: 2005-08-21 22:58 UTC by Axel Thimm
Modified: 2009-04-24 13:54 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-04-24 13:54:21 UTC
Embargoed:


Attachments (Terms of Use)

Description Axel Thimm 2005-08-21 22:58:20 UTC
Description of problem:
When relocating an nfs service or restarting it in place during a write
transaction the mounted filesystem returns EACCES.

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

How reproducible:
always

Steps to Reproduce:
1.Setup an nfs service
2.mount it on another RHEL4 client
3.Start an NFS write
4.Use clusvcadm -R or -r ...

Actual results:
The write operation breaks with Permission denied, any further access to the
mounted filesystem returns Permission denied.

Expected results:
Continuation of the write operation. Filsystem remains accessible 

Additional info:
o Restarting/relocating when NFS is not busy is successful.
o The network connection is GBit, the NFS protocol is 3, connection is via TCP
o slow writes are successful (in restarting/relocating)
o Relevant cluster.conf part:

    <service autostart="1" domain="nfs" name="homes-nfs">
      <ip ref="XXX.XXX.XXX.XXX"/>
      <clusterfs ref="data">
        <nfsexport name="home" path="/data/homes">
          <nfsclient ref="clients"/>
        </nfsexport>
      </clusterfs>
    </service>

Comment 1 Lon Hohberger 2005-10-04 21:28:21 UTC
Assigning to NFS maintainer, but staying on CC list for now.

Comment 2 Lon Hohberger 2005-11-16 15:01:08 UTC
The issue here is that we're calling "exportfs -u" before the request queue is
clear.  Thus, clients get EPERM if they have pending requests on the queue, even
if the IP address has already been torn down.

Comment 3 Lon Hohberger 2006-02-01 19:53:40 UTC
This should be fixed in current CVS and/or the RHCS4U3 packages when they come
out.  Setting to MODIFIED.

Comment 4 Axel Thimm 2007-12-30 10:01:08 UTC
Although I can't test this anymore on RHEL4 I think this bug should be closed as
fixed.

Comment 5 Lon Hohberger 2009-04-24 13:54:21 UTC
RHCS 4.3 and later.


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