Bugzilla – Bug 134370
Nfsv4 : Pynfs test failing - Set attrs {33: 480} not equal to got attrs {33: 511}
Last modified: 2006-05-09 03:57:38 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}
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..
I think it's pointless to try to change a symlink to anything other than mode 777. We should ignore this failure.
Neil, could you track this one, please? Thanks!
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
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.
I guess the information is provided...
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.
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.
I think it is unanimous then :-) WONTFIX it is.