[Bug 186293] tar(1): Problems with tar on FreeBSD 10.0

Wed Oct 8 14:41:32 UTC 2014

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186293

--- Comment #7 from jnaughto at 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.