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
