Date: Wed, 17 Dec 2014 23:27:03 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 193128] NFSv3 Solaris 10 Server < - > NFSv3 Freebsd 10.1 Client Message-ID: <bug-193128-3630-ZIRJlowH6q@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-193128-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-193128-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193128 --- Comment #2 from Rick Macklem <rmacklem@FreeBSD.org> --- This sounds like a reported case of a problem that was pretty clearly a Solaris server bug. From the wireshark trace I have, the client: - does an exclusive open, which succeeds - does a setattr with mode 0644, which succeeds --> Then the file's attributes are returned by the subsequent write with mode 0, even though it replied NFS_OK to the setattr for mode 0644 When I tried to contact someone in the NFS Solaris engineering group, I got a "we don't talk to anyone without a maintenance contract". The person who reported this via email tried making a bug report to Solaris, but ended up converting his server to FreeBSD to fix the problem. His test case for the above mentioned wireshark trace was extracting a small tarball with one small file in it. You could try the same test and see if the you get the same result. If unrolling the tarball doesn't cause the problem, you could email me a packet trace for the failure, but please try and make it as small as possible. (Or look at it in wireshark and look for an Exclusive CREATE, followed by a SETATTR that sets the mode, both returning NFS_OK.) I guess you are stuck with NFSv2 (which does file creation differently) or bugging Oracle/Solaris about the bug. Also, if the simple "tar xpf <file>" fails for FreeBSD 10 but succeeds for FreeBSD8.3 against the Solaris server, I could look at a packet trace from the FreeBSD8.3 case and see how it differs. (It still seems clear it is a Solaris server bug, but maybe a client change could be created to work around it.) To get a packet trace, you can do the following on the FreeBSD client: # tcpdump -s 0 -w <file>.pcap host <server-hostname> Good luck with it, rick ps: I'll email the packet trace I have to you, so you can look at it in wireshark. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-193128-3630-ZIRJlowH6q>