We have two nfs exports that are being served from a NetApp filer and are
mounted on a RHEL5 x86_64 machine running 2.4.9-e.70smp.

The exports are mounted as such:
192.168.0.20:/vol/www/www.example.com on /var/www/www.example.com type nfs
(ro,nosuid,nodev,noatime,nolock,hard,intr,bg,nfsvers=3,rsize=32768,actimeo=15,addr=192.168.0.20)

192.168.0.20:/vol/www/www.example.com-logs/logs/spool on
/var/log/httpd/nfs/spool type nfs
(rw,nosuid,nodev,noatime,hard,intr,bg,nfsvers=3,rsize=4096,wsize=4096,addr=192.168.0.20)

Note that the mount on /var/www/www.example.com is read-only and the mount on
/var/log/httpd/nfs/spool is read-write.

The export configuration on the filer is valid and is properly exported (and
flushed prior for good measure):
/vol/www/www.example.com-logs    -sec=sys,rw=192.168.0.101
/vol/www/www.example.com    -sec=sys,ro=192.168.0.101

When /vol/www/www.example.com is mounted first, and
/vol/www/www.example.com-logs is mounted second, /vol/www/www.example.com-logs
incorrectly inherits /vol/www/www.example.com's read-only access.

Example:
[root.0.101 ~]# mount -t nfs 192.168.0.20:/vol/www/www.example.com
/var/www/www.example.com -o
ro,nolock,hard,intr,bg,noatime,nodev,nosuid,nfsvers=3,rsize=32768,actimeo=15,async
[root.0.101 ~]# mount | grep nfs
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
192.168.0.20:/vol/www/www.example.com on /var/www/www.example.com type nfs
(ro,nosuid,nodev,noatime,nolock,hard,intr,bg,nfsvers=3,rsize=32768,actimeo=15,addr=10.8.2.20)
[root.0.101 ~]# mount -t nfs
192.168.0.20:/vol/www/www.example.com-logs/logs/spool /var/log/httpd/nfs/spool
-o defaults,rw,hard,intr,bg,noatime,nodev,nosuid,nfsvers=3,rsize=4096,wsize=4096
[root.0.101 ~]# mount | grep nfs
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
192.168.0.20:/vol/www/www.example.com on /var/www/www.example.com type nfs
(ro,nosuid,nodev,noatime,nolock,hard,intr,bg,nfsvers=3,rsize=32768,actimeo=15,addr=10.8.2.20)
192.168.0.20:/vol/www/www.example.com-logs/logs/spool on
/var/log/httpd/nfs/spool type nfs
(rw,nosuid,nodev,noatime,hard,intr,bg,nfsvers=3,rsize=4096,wsize=4096,addr=10.8.2.20)
[root.0.101 ~]# touch /var/log/httpd/nfs/spool/test.txt
touch: cannot touch `/var/log/httpd/nfs/spool/test.txt': Read-only file system

/var/log/httpd/nfs/spool/ shows as being mounted read-write yet I am incorrectly
told it is read-only and prevented from touch a file on it.

When /vol/www/www.redhat.com-logs is mounted first, and /vol/www/www.example.com
is mounted second, /vol/www/www.example.com-logs is properly set to read-write.

Example:
[root.0.101 ~]# umount -a -t nfs
[root.0.101 ~]# mount | grep nfs
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
[root.0.101 ~]# mount -t nfs
192.168.0.20:/vol/www/www.example.com-logs/logs/spool /var/log/httpd/nfs/spool
-o defaults,rw,hard,intr,bg,noatime,nodev,nosuid,nfsvers=3,rsize=4096,wsize=4096
[root.0.101 ~]# mount | grep nfs
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
192.168.0.20:/vol/www/www.example.com-logs/logs/spool on
/var/log/httpd/nfs/spool type nfs
(rw,nosuid,nodev,noatime,hard,intr,bg,nfsvers=3,rsize=4096,wsize=4096,addr=10.8.2.20)
[root.0.101 ~]# mount -t nfs 192.168.0.20:/vol/www/www.example.com
/var/www/www.example.com -o
ro,nolock,hard,intr,bg,noatime,nodev,nosuid,nfsvers=3,rsize=32768,actimeo=15,async
[root.0.101 ~]# mount | grep nfs
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
192.168.0.20:/vol/www/www.example.com-logs/logs/spool on
/var/log/httpd/nfs/spool type nfs
(rw,nosuid,nodev,noatime,hard,intr,bg,nfsvers=3,rsize=4096,wsize=4096,addr=10.8.2.20)
192.168.0.20:/vol/www/www.example.com on /var/www/www.example.com type nfs
(ro,nosuid,nodev,noatime,nolock,hard,intr,bg,nfsvers=3,rsize=32768,actimeo=15,addr=10.8.2.20)
[root.0.101 ~]# touch /var/log/httpd/nfs/spool/test.txt
[root.0.101 ~]# ll /var/log/httpd/nfs/spool/test.txt
-rw-r--r-- 1 root root 0 Sep 28 11:36 /var/log/httpd/nfs/spool/test.txt

This is reproducible every time.

My theory is that the kernel is doing a partial name match on the export name
when determining the type of access it has. This problem does not appear in
older versions of RHEL.

Please advise.