From owner-freebsd-bugs@FreeBSD.ORG Wed Oct 8 14:41:32 2014 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F21C702 for ; Wed, 8 Oct 2014 14:41:32 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA2BD9C8 for ; Wed, 8 Oct 2014 14:41:31 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s98EfVYB049454 for ; Wed, 8 Oct 2014 14:41:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 186293] tar(1): Problems with tar on FreeBSD 10.0 Date: Wed, 08 Oct 2014 14:41:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jnaughto@ee.ryerson.ca X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 14:41:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186293 --- Comment #7 from jnaughto@ee.ryerson.ca --- I got my response back from Oracle with respect to this issue. This is what they had to say: --------------------------- Oracle's SR Response ----------------------------------- Hi Jason, I tried to extract a tar file to a NFSv3 share from a Solaris 11 client. Below is the part of snoop while NFS created the file on share. client: 10.163.223.163 server: 10.163.209.210 bash-3.2# snoop -r -i net2.cap.1 -p 32,33 32 0.00000 10.163.223.163 -> 10.163.209.210 NFS C CREATE3 FH=0599 (GUARDED) vnet.log 33 0.00026 10.163.209.210 -> 10.163.223.163 NFS R CREATE3 OK FH=5A3B Above snoop showed the client sent create request to server. Below are the expanded snoops containing detailed information on NFS. Packet 32: Client sent create file request with proper acl information on file. NFS: ----- Sun NFS ----- NFS: NFS: Proc = 8 (Create file) NFS: File handle = [0599] NFS: 059000020000000B000A0000093A918C00000000000A0000093A918C00000000 NFS: File name = vnet.log NFS: Method = Guarded NFS: Mode = 0644 NFS: Setuid = 0, Setgid = 0, Sticky = 0 NFS: Owner's permissions = rw- NFS: Group's permissions = r-- NFS: Other's permissions = r-- NFS: User ID = (not set) NFS: Group ID = 0 NFS: Size = 0 NFS: Access time = (do not set) NFS: Modification time = (do not set) NFS: NFS: Packet 33: Server create the file with correct acl: NFS: ----- Sun NFS ----- NFS: NFS: Proc = 8 (Create file) NFS: Status = 0 (OK) NFS: File handle = [5A3B] NFS: 059000020000000B000A00002D6EEA350000004F000A0000093A918C00000000 NFS: Post-operation attributes: NFS: File type = 1 (Regular File) NFS: Mode = 0644 NFS: Setuid = 0, Setgid = 0, Sticky = 0 NFS: Owner's permissions = rw- NFS: Group's permissions = r-- NFS: Other's permissions = r-- NFS: Link count = 1, User ID = 4294967294, Group ID = 4294967294 NFS: File size = 0, Used = 0 NFS: Special: Major = 4294967295, Minor = 4294967295 NFS: File system id = 1529008357378, File id = 762243637 NFS: Last access time = 08-Oct-14 01:38:13.152404410 GMT NFS: Modification time = 08-Oct-14 01:38:13.152404410 GMT NFS: Attribute change time = 08-Oct-14 01:38:13.152404410 GMT NFS: NFS: Pre-operation attributes: NFS: Size = 790 bytes NFS: Modification time = 08-Oct-14 01:37:35.189977830 GMT NFS: Attribute change time = 08-Oct-14 01:37:35.189977830 GMT NFS: NFS: Post-operation attributes: NFS: File type = 2 (Directory) NFS: Mode = 01777 NFS: Setuid = 0, Setgid = 0, Sticky = 1 NFS: Owner's permissions = rwx NFS: Group's permissions = rwx NFS: Other's permissions = rwx NFS: Link count = 7, User ID = 0, Group ID = 3 NFS: File size = 855, Used = 8192 NFS: Special: Major = 0, Minor = 0 NFS: File system id = 1529008357378, File id = 154833292 NFS: Last access time = 08-Oct-14 01:38:05.372080530 GMT NFS: Modification time = 08-Oct-14 01:38:13.152486310 GMT NFS: Attribute change time = 08-Oct-14 01:38:13.152486310 GMT NFS: NFS: Let's compare the same operation in the snoop taken on FreeBSD. Below are the packets doing this job. bash-3.2$ snoop -i mole-eccles2.snoop -p 17,18 17 0.00000 dhcp-whq2op4-172-16-20-63.us.voip.oraclecorp.com -> dhcp-whq2op4-172-16-20-68.us.voip.oraclecorp.com NFS C CREATE3 FH=71FF (EXCLUSIVE) BOB 18 0.00679 dhcp-whq2op4-172-16-20-68.us.voip.oraclecorp.com -> dhcp-whq2op4-172-16-20-63.us.voip.oraclecorp.com NFS R CREATE3 OK FH=FBA3 Pakcet 17: Client sent request to create file, however with no acl information. NFS: ----- Sun NFS ----- NFS: NFS: Proc = 8 (Create file) NFS: File handle = [71FF] NFS: 1E59EFB108C388D40A0004000000000052E401000A0004000000000052E40100 NFS: File name = BOB NFS: Guard = 5159D4651080B693 NFS: Packet 18: As a consequence, server doesn't know how to set acl on the new file. The option left is to put blank on it. NFS: ----- Sun NFS ----- NFS: NFS: Proc = 8 (Create file) NFS: Status = 0 (OK) NFS: File handle = [FBA3] NFS: 1E59EFB108C388D40A00200000000000F8B805000A0004000000000052E40100 NFS: Post-operation attributes: NFS: File type = 1 (Regular File) NFS: Mode = 00 NFS: Setuid = 0, Setgid = 0, Sticky = 0 NFS: Owner's permissions = --- NFS: Group's permissions = --- NFS: Other's permissions = --- NFS: Link count = 1, User ID = 0, Group ID = 0 NFS: File size = 0, Used = 512 NFS: Special: Major = 4294967295, Minor = 4294967295 NFS: File system id = 1198295941134, File id = 32 NFS: Last access time = 02-Oct-14 10:47:57.031549787 GMT NFS: Modification time = 10-Oct-78 12:33:23.1364841573 GMT NFS: Attribute change time = 02-Oct-14 10:47:57.031549787 GMT NFS: NFS: Pre-operation attributes: NFS: Size = 2 bytes NFS: Modification time = 05-Sep-14 21:14:33.000000000 GMT NFS: Attribute change time = 02-Oct-14 10:47:57.022257425 GMT NFS: NFS: Post-operation attributes: NFS: File type = 2 (Directory) NFS: Mode = 0755 NFS: Setuid = 0, Setgid = 0, Sticky = 0 NFS: Owner's permissions = rwx NFS: Group's permissions = r-x NFS: Other's permissions = r-x NFS: Link count = 2, User ID = 1061, Group ID = 2500 NFS: File size = 3, Used = 1536 NFS: Special: Major = 4294967295, Minor = 4294967295 NFS: File system id = 1198295941134, File id = 4 NFS: Last access time = 02-Oct-14 14:47:23.000000000 GMT NFS: Modification time = 02-Oct-14 10:47:57.031876316 GMT NFS: Attribute change time = 02-Oct-14 10:47:57.031876316 GMT NFS: NFS: It looks like the issue happened while the file was being created. FreeBSD should have given correct acl to server but for some reason it didn't. I guess this is more like a FreeBSD issue. Can you try the same test with another NFS client other than FreeBSD? ------------------------------------------------------------------ So as I kinda expected the Oracle Engineers pointed the issue back to FreeBSD with what appears to be strong evidence that the FreeBSD NFS client code is not functioning properly. -- You are receiving this mail because: You are the assignee for the bug.