Bug 166458 - relocating/restarting nfs services results in permission denied (EACCES in lstat)
relocating/restarting nfs services results in permission denied (EACCES in ls...
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: rgmanager (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Steve Dickson
Cluster QE
Depends On:
Blocks: RHEL4NFSFailover
  Show dependency treegraph
Reported: 2005-08-21 18:58 EDT by Axel Thimm
Modified: 2009-04-24 09:54 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-24 09:54:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Axel Thimm 2005-08-21 18:58:20 EDT
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):

How reproducible:

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"/>
Comment 1 Lon Hohberger 2005-10-04 17:28:21 EDT
Assigning to NFS maintainer, but staying on CC list for now.
Comment 2 Lon Hohberger 2005-11-16 10:01:08 EST
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 14:53:40 EST
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 05:01:08 EST
Although I can't test this anymore on RHEL4 I think this bug should be closed as
Comment 5 Lon Hohberger 2009-04-24 09:54:21 EDT
RHCS 4.3 and later.

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