Hi, I've already filed this bug with red hat and debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617508 https://bugzilla.redhat.com/show_bug.cgi?id=683372 I tried this with kernels 2.6.32 (both the debian ones and the rhel ones). I also have this on RHEL 5.5 and 5.6. Also verified it with 2.6.38-rc6 from Debian. Say you have a directory A with root:root as the owner and 755 as permissions. In this directory you have a file with owner user:user with permissions 600. If this directory is mounted over NFSv4 and user tries to append to the file before a stat of the file has happened, it will receive a permission denied error. Repeating the append repeats the error. Only after running an explicit stat on the file, the append works. It seems the NFS4 client assumes the same permissions as the directory for the file you're trying to append and therefore refuses the append. When the permissions are requested by the client it works. After a while (a few minutes), the client seems to have forgotten about the correct permissions and the error comes back. I can provide detailed instructions on how to reproduce this if needed. I also have a disk image for a Debian squeeze VM on which I reproduce this if needed. I will rerun my tests and provide a tcpdump as well. Regards, Rik
Created attachment 50582 [details] Network dump I used one system running 2.6.38-rc6 as both the server and client. The client mounted the nfs4 share over the loopback interface. Sequence of commands: - start of tcpdump - mount of filesystem - ping to localhost so i can see it in the dump - run my trigger script (returns error) - ping to localhost - run my trigger script again a few times (always returns error) - ping to localhost - stat the file - ping to localhost - run my trigger script, no error
My trigger script is a ksh script: #! /bin/ksh printf "hello world" >> /mnt/b/datafile I mounted the nfs4 filesystem under /mnt and b is a directory on the mount. The permissions on b are 755 root:root, The permissions on the datafile are 0600 user:user.
Also verified it on Debian Etch r0 2.6.18 kernel. It has the same problem.
Red Hat has debugged this problem and have posted a patch in the bugzilla entry: https://bugzilla.redhat.com/show_bug.cgi?id=683372 I recompiled the RHEL6 kernel with the patch applied and can confirm that it fixes this bug.
Proposed patch on linux-nfs mailing list http://thread.gmane.org/gmane.linux.nfs/40010