On Fri, Jul 22, 2016 at 10:36 AM, Thomas Gambier <thomas.gambier@xxxxxxxxx> wrote: > On Fri, Jul 22, 2016 at 3:05 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >> On Fri, Jul 22, 2016 at 5:36 AM, Thomas Gambier >> <thomas.gambier@xxxxxxxxx> wrote: >>> Hello, >>> >>> when doing more tests with TCL, I found a more critical problem. >>> >>> If I create a directory and just after I create a read only file (mode >>> 0444) inside it, I got a permission denied error. See the attached C >>> source code. As the previous error, it is random but I always have it >>> fail before the 10th execution. >>> >>> I attach the network traffic but it seems that the problem is again in >>> the client. >>> >>> Olga, could you test this new testcase on the newest kernel ? >> >> Works fine for me on the RHEL7.2 and upstream. >> > This is strange because I just tested on CentOS7.2 (my kernel is > 3.10.0-327.el7.x86_64) and I have the problem. I retested .327 RHEL7.2 against a linux server (and not netapp server). It fails. The test app works in upstream against both servers. > >>> >>> Regards. >>> >>> Thomas. >>> >>> On Thu, Jul 21, 2016 at 8:10 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >>>> On Thu, Jul 21, 2016 at 1:14 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: >>>>> On Thu, Jul 21, 2016 at 04:54:36PM +0200, Thomas Gambier wrote: >>>>>> On Mon, Jul 18, 2016 at 4:09 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: >>>>>> > On Mon, Jul 18, 2016 at 03:44:48PM +0200, Thomas Gambier wrote: >>>>>> >> Hello, >>>>>> >> >>>>>> >> thanks for your answer. See my comments below. >>>>>> >> >>>>>> >> On Wed, Jul 13, 2016 at 3:26 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: >>>>>> >> > On Mon, Jul 11, 2016 at 07:40:11PM +0200, Thomas Gambier wrote: >>>>>> >> >> Hello, >>>>>> >> >> >>>>>> >> >> I just discovered a problem with NFSv4 file system. I was using TCL >>>>>> >> >> scripts that were doing some file manipulation (mkdir, copy, ...) on >>>>>> >> >> my NFSv4 file system and sometimes the scripts failed with "permission >>>>>> >> >> denied" error. >>>>>> >> >> >>>>>> >> >> I ran strace and I found that the system call returning the error was: >>>>>> >> >> open("d1/in.txt", O_WRONLY|O_CREAT|O_TRUNC, 0100444) = -1 EACCES >>>>>> >> >> (Permission denied) >>>>>> >> > >>>>>> >> > Is that even allowed? The open(2) man page says posix leaves behavior >>>>>> >> > in that case unspecified, and doesn't say anything I can find about >>>>>> >> > Linux behavior in this case. >>>>>> >> > >>>>>> >> You're right. I will send a mail to TCL mailing list to know why they >>>>>> >> put this flag in the open call. >>>>>> >> >>>>>> >> > I guess it would be nicer for client or server to do something >>>>>> >> > predictable, though. First steps might be to confirm what happens other >>>>>> >> > filesystems, then do a network trace (watch the traffic in wireshark) to >>>>>> >> > see if it's the client rejecting this open, or the client passing >>>>>> >> > through that bit in the mode and the server returning the error. >>>>>> >> >>>>>> >> I agree. For other filesystem, I only tested with ext4 which works >>>>>> >> fine. Let me know if you want me to test specific filesystems. >>>>>> >> >>>>>> >> I attach the wireshark capture of a test with 8 open call working fine >>>>>> >> and the 9th one failing. For me, it seems the activity on the network >>>>>> >> is exactly the same for the failing case (same call from client to >>>>>> >> server and same answer from server to client). It would mean that the >>>>>> >> client itself is messing things up... >>>>>> > >>>>>> > Agreed, sounds like the client's only deciding to fail the open after >>>>>> > the OPEN call to the server succeeds. >>>>>> > >>>>>> > Unfortunately, the client open logic is (necessarily) pretty >>>>>> > complicated--a few minutes digging around wasn't enough for me to figure >>>>>> > uot where the error's coming from. >>>>>> > >>>>>> >>>>>> I'm not sure if I can help... I don't know the NFS source code at all. >>>>>> I can do more tests if you need, though. >>>>> >>>>> It doesn't look like a high priority based just on what we know >>>>> (slightly odd behavior in an undefined case), so I think we'll just have >>>>> to leave it at that until somebody gets curious. Thanks for the report. >>>>> >>>> >>>> Hi Thomas, >>>> >>>> I don't know exactly what was fixed or when but I thought I'd note >>>> that I don't see the problem on the upstream 4.7-rc7 but I can >>>> reproduce the problem on RHEL7.2 kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html