Bug 137057 - file permission problem with NFS exported GFS filesystem to Solaris client
file permission problem with NFS exported GFS filesystem to Solaris client
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gfs (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Wendy Cheng
GFS Bugs
:
Depends On:
Blocks: 137219
  Show dependency treegraph
 
Reported: 2004-10-25 12:39 EDT by Erling Nygaard
Modified: 2010-01-11 22:00 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-04 11:36:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Erling Nygaard 2004-10-25 12:39:26 EDT
Description of problem:

NFS server is RHEL with GFS, exporting to Solaris NFS client.
'cp' command on client causes permission denied error, destination
file is created with 0 byte length.  This error does not occur on RHEL
clients NFS mounting the same GFS filesystem.

The problem affects all user except root.

We can:
- move / copy files on a NFS-exported ext3 filesystem if he is on a
RHEL NFS client as any non-root user
- move / copy files on a NFS-exported ext3 filesystem if he is on a
RHEL NFS client as the user "root"
- move / copy files on a NFS-exported ext3 filesystem if he is on a
Solaris NFS client as any non-root user
- move / copy files on a NFS-exported ext3 filesystem if he is on a
Solaris NFS client as any non-root user

- move / copy files on the NFS-exported GFS-filesystem if he is on a
RHEL NFS client as any non-root user
- move / copy files on the NFS-exported GFS-filesystem if he is on a
RHEL NFS client as the user "root"
- move / copy files on the NFS-exported GFS-filesystem if he is on a
Solaris NFS client as the user "root"

If the non-root user logs into the NFS server he can move /copy files.

The user CAN NOT:
- move / copy files on the NFS-exported GFS-filesystem if he is on a
Solaris NFS client as any non-root user


Something we tried: 

mounted the remote filesystem from the Solaris client with: 
mount -F nfs san1:/u1/public /gfs 

Mount took. cd to user directory with permissions: 
drwxrwsr-x   2 sconnors     3864 Sep  1 17:01 ./ 

File "junk" is permissioned for the user (sconnors) 444 

Attempted to copy a 444 (permissions) file as root and checked: 
22 hurricane # cp junk junk10 
23 hurricane # ls -la junk10 
-r--r--r--   1 root           10 Sep  1 17:01 junk10 

Attempted to copy a 444 (permissions) file as sconnors and checked: 
sconnors@hurricane{46}cp junk junk20 
cp: cannot create junk20: Permission denied 
Exit 2



Version-Release number of selected component (if applicable):
rh-gfs-en-6.0-4

How reproducible:
Always

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 michael conrad tadpol tilstra 2005-07-18 16:18:42 EDT
wonder if the setgid bit is confusing/complicating things.
Comment 4 Wendy Cheng 2006-03-20 12:04:34 EST
This is a very old bugzilla that could be very much out of date. For now:

(a) If Solaris client runs NFS v2/v3, I see no problem at all during cthon06.
(b) If Solaris client is running NFS v4, NFS does have some cleaning up to do. 

If the original case is (a), I would like to close this as "being fixed". If the
original case is (b), we need to transfer this bugzilla to NFS team. After nfs
v4 clean up work is completed, we'll check to see how GFS works. 
Comment 5 Wendy Cheng 2006-05-04 11:36:52 EDT
This is a very old bug and we could no longer get the customer contact info.
Also if this is on NFS v2/v3, it works fine. Will close this as insufficient info. 

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