Escalated to Bugzilla from IssueTracker
Customer has a auto-mounted NFS share /kickstart from NetApp filer. --snip-- netappfiler> exportfs /ks -actual=/some/vol/ks,sec=sys,rw,root=a.b.c:b.b.c:c.b.c --snip-- .. machine is not in "root" allowed list mount -v ------------ automount(pid3817) on /kickstart type autofs (rw,fd=5,pgrp=3817,minproto=2,maxproto=4) ls -al /kickstart/etc/testfile -rw------- 1 root other 20 Mar 20 14:00 /kickstart/etc/testfile more /kickstart/etc/testfile cat /kickstart/etc/testfile cat: /kickstart/etc/testfile: Input/output error mount -v automount(pid3817) on /kickstart type autofs (rw,fd=5,pgrp=3817,minproto=2,maxproto=4) filer1:/vol/admin/local/kickstart/etc on /kickstart/etc type nfs (ro,tcp,noacl,noacl,rsize=8192,wsize=8192,addr=10.1.17.10) --- Why does the "more" command not complain about 'permission denied' ? Why did the "cat" give an I/O error instead of a 'permission denied' ? This event sent from IssueTracker by jlayton [Support Engineering Group] issue 90713
Customer: --------- >So the behavior they're seeing sounds correct and reasonable to me >given the situation. Please understand, that RHEL3 and RHEL4 behave different! Hopefully only behavior of RHEL4 sounds correct/reasonable for you: RHEL4: # ll /ks/etc/testfile -rw------- 1 root other 20 Mar 20 14:00 /ks/etc/testfile # more /ks/etc/testfile /ks/etc/testfile: Permission denied # cat /ks/etc/testfile /ks/etc/testfile: Permission denied RHEL3: # ll /ks/etc/testfile -rw------- 1 root other 20 Mar 20 14:00 /ks/etc/testfile # more /ks/etc/testfile (no output, expected: "/ks/etc/testfile: permission denied") # cat /ks/etc/testfile cat: /ks/etc/testfile: Input/output error /ks/etc/tesfile is nfs-mounted volume with options "ro,noacl,rsize=wsize=8192", either from solaris/VxFS or netapp-filer or RHEL4-nfs-server. So I'm asking once again to fix this "noacl"-problem/bug on RHEL3, (as it has been done in RHEL4), to not have to think about switching off "rootsquash"-option on our nfs-servers and its implications. Internal Status set to 'Waiting on SEG' Status set to: Waiting on Tech This event sent from IssueTracker by jlayton [Support Engineering Group] issue 90713
Added some code around the readpage: section of do_generic_file_read. It looks like the EIO comes from there. Apparently, this returns 0: error = mapping->a_ops->readpage(filp, page); ...and then generic_file_readahead() doesn't set F_ATOMIC in the flags, so we return -EIO: do_generic_file_read: setting desc error on read of testfile to -5 This section of code is quite a bit different upstream, so still looking at what it does differently.
2.4.32 never even calls do_generic_file_read for the file, so some of the calling functions must be returning EACCES before it even gets to that point.
Created attachment 133319 [details] patch 1 This patch seems to correct the problem and looks to be the right approach. When noacl is specified, RHEL3 skips the NFS ACCESS call to the server and relies on vfs_permission, which just uses the mode bits. This is obviously wrong in a root squash situation. The 2.4.32 nfs_permission routine is very different from the one in RHEL3, but I've not been able to track down the upstream patches that made those changes. Still, when it comes to this situation it seems to follow the same logic.
Actually, it looks like that line was changed as part of the NFS ACL patch, and that patch never went upstream. So patch 1 should be ok.
Changing back to ASSIGNED based on feedback from Ingo M. I'm going to respin this patch so that this behavior is contingent on a new mount option noacl_safe.
Created attachment 134240 [details] patch 2 This patch adds a "noacl_safe" mount option for nfs, and makes the "correct" behavior contingent upon it. The regular noacl option should behave as it has up until now. I'll also clone this BZ and post the corresponding patch for mount to it.
Peter S. indicated that this is just a bug plain and simple, and patch 2 really serves no purpose. So, I'll stick with proposing patch 1.
Product Management has reviewed and declined this request. You may appeal this decision by reopening this request.
QE ack for 3.9.
Moving to "Documentation" component for release note tracking.
There have been no updates to this issue in the past month. This issue will now be closed due to inactivity. If this is in error, please reopen the issue and check to make sure that it is current and in the proper status. If the issue is something which is on a longer timeline than a month, please change the status to one of the long term selections to avoid closure due to inactivity. This event sent from IssueTracker by AutoCloser [EMEA Production Escalation] issue 90713