Bug 134370

Summary:	Nfsv4 : Pynfs test failing - Set attrs {33: 480} not equal to got attrs {33: 511}
Product:	[openSUSE] SUSE Linux 10.1	Reporter:	Forgotten User b5BnQSUi71 <forgotten_b5BnQSUi71>
Component:	Other	Assignee:	Neil Brown <nfbrown>
Status:	VERIFIED WONTFIX	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None
Version:	Alpha 2
Target Milestone:	---
Hardware:	x86
OS:	SuSE Linux 10.0
Whiteboard:
Found By:	Development	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Forgotten User b5BnQSUi71 2005-11-18 10:19:05 UTC

Pynfs (now called newpynfs), a suite of several Python tools for NFS4 is used
for testing NFSv4 RFC compliance. It can be downloaded here.
http://www.citi.umich.edu/projects/nfsv4/pynfs/

Steps to reproduce the bug:
1. Setup NFSv4 server in SUSE 10.1 Alpha 2
2. Install newpynfs
3. Run the pynfs testserver.py script
./testserver.py --maketree <hostname> all -v
        or
python testserver.py --maketree <hostname> all -v
4. The results will be store in out_last file
5. Redirect results to a text file
./showresults.py out_last > SUSE10.1-acl1.txt
6. The following test is failing
SATT1a   st_setattr.testLink                             : FAILURE
      Set attrs {33: 480} not equal to got attrs {33: 511}

Comment 1 Forgotten User b5BnQSUi71 2005-12-07 12:50:57 UTC

This python test internally tries to do a change mode 740 (SETATTR) on a symlink (linked to /etc/X11) present in NFSv4 mounted directory. It obtains the mode using GETATTR later. It expects both of them to be the same. I manually changed the mode in the python code (hardcoded value) to 755 from 740, even then getattr returned the same value (equivalent to 777). My guess is that problem could be because of getattr code which always fetches equivalent of 777 or may be server code which without setting the attribute, returns true.

Manually iam able to chmod the link present in NFSv4 mount point to 740 which means setattr is going through. 
Just my observation..

Comment 2 Olaf Kirch 2005-12-08 12:01:04 UTC

I think it's pointless to try to change a symlink to anything other
than mode 777. We should ignore this failure.

Comment 3 Olaf Kirch 2005-12-12 10:34:14 UTC

Neil, could you track this one, please? Thanks!

Comment 4 Neil Brown 2005-12-13 00:01:29 UTC

I agree with #2.
POSIX does not allow you to change the mode on a symlink, and WIN32 doesn't have
symlink (I believe) so expecting NFSv4 to support this is somewhat odd.

Some linux filesystems expressly reject a chmod request on a symlink, so
Linux' nfsd quite rejects any such request.

Could you check with the pynfs maintainer if this could be made simply
a warning, or removed altogether (on the basis that even is some servers
might allow it, the mode of a symlink is completely meaningless).

Thanks,
NeilBrown

Comment 5 Forgotten User b5BnQSUi71 2005-12-19 11:18:33 UTC

Neil Wrote:
>>Some linux filesystems expressly reject a chmod request on a symlink, so
>>Linux' nfsd quite rejects any such request.
Could not find concrete information on how filesystems(ext3/reiserfs) handle chmod request on a symlink. But, I was able to do chmod on a symlink on both ext3 & Reiserfs filesystems manually which means both the filesystems support chmod on symlink. Iam not aware of a filesystem which rejects a chmod request on symlink. Could you please let me know.. This information could be useful while taking up this issue with pynfs maintainer.

I found that the test is passing in RHEL 4 AS(2.6.9) which has ext3 file system as default file system. The test is also passing in SUSE 10 (2.6.13-rc6-git13-4) on a ext3 exported path, but fails on default reiserfs exported path.
But the test is failing in SLES10 preview1(2.6.15-rc5-2) on both ext3/reiserfs file systems.

Comment 6 Andreas Jaeger 2006-03-24 08:48:06 UTC

I guess the information is provided...

Comment 7 Ralf Flaxa 2006-05-02 11:43:16 UTC

Suresh, the point in comment #2 is that this is not specified for NFSv4
and should not even be expected to be supported. So Neil, I would close
this as WONTFIX.

Comment 8 Forgotten User b5BnQSUi71 2006-05-02 12:09:14 UTC

I agree. This can be closed as WONT'T FIX. Fred (newpynfs maintainer) has agreed to add some form of priority filter to tests so that it will be easier to ignore failures like this.

Comment 9 Neil Brown 2006-05-09 01:44:13 UTC

I think it is unanimous then :-)
WONTFIX it is.