Hello, just one hour ago I figured out a VERY strange behaviour using tar # tar -xvzf package.tgz which gave me: # ls -al drwxr-xr-x 4 user user 10 Jan 31 07:05 . drwxr-xr-x 5 user user 5 Jan 31 07:05 .. drwxr-xr-x 2 user user 12 Jan 31 07:05 check ---------- 1 user user 9338 Jun 17 2010 common.sh drwxr-xr-x 2 user user 23 Jan 31 07:05 impl ---------- 1 user user 17807 Jul 29 2013 new_project.sh ---------- 1 user user 38451 May 2 2012 new_project.wsf The permissions of ALL files are not there! It should be noted I write on a Solaris 11 host using NFS/ZFS. But with FreeBSD 9.1 I had no problems. Does anyone know what is behind? a solution? Thanks!! N. Grundmann
I should note, that this behaviour is not only related to tar. For example, if I compile software manually, using clang, the generated *.o files have no rights. Doing the same with gcc46, the results are ok, which means the *.o files have the permissions what they should have... See: [clang/samtools-0.1.19] > ll *.o ---------- 1 appl admin 74232 Feb 1 07:11 bam.o ---------- 1 appl admin 56496 Feb 1 07:11 bam2bcf.o ---------- 1 appl admin 104392 Feb 1 07:11 bam2bcf_indel.o ---------- 1 appl admin 21832 Feb 1 07:11 bam2depth.o ---------- 1 appl admin 46512 Feb 1 07:11 bam_aux.o and: [gcc/samtools-0.1.19] > ll *.o -rw-r--r-- 1 appl admin 90488 Feb 1 07:10 bam.o -rw-r--r-- 1 appl admin 57864 Feb 1 07:10 bam2bcf.o -rw-r--r-- 1 appl admin 88256 Feb 1 07:10 bam2bcf_indel.o -rw-r--r-- 1 appl admin 22400 Feb 1 07:10 bam2depth.o -rw-r--r-- 1 appl admin 52272 Feb 1 07:10 bam_aux.o -rw-r--r-- 1 appl admin 17128 Feb 1 07:10 bam_cat.o and another thing related to this: untar a package on a mounted NFS/ZFS volumne which resides in a FreeBSD 10.0 computer gives me no problem. I think the whole thing is realted to: FreeBSD 10 NFS client <---> Solaris 11 NFS Server Hopefully someone could help me :-) Norbert
Additional info from an extraction of tar with tcpdump and wireshark: 17 0.009073 128.x.z.135 128.x.y.33 NFS 182 V3 GETATTR Reply (Call In 16) Regular File mode: 0000 uid: 200 gid: 100 ... 23 0.016886 128.x.z.135 128.x.y.33 NFS 186 V3 LOOKUP Reply (Call In 22) Error: NFS3ERR_NOENT Norbert
Hello, my FreeBSD box does not work, too. In use NFSv3, the all permissions are none. In use NFSv2, the all permissions are right, but the result of df is bad. Thanks. NFS Server % uname -a SunOS expserv 5.11 11.1 i86pc i386 i86pc % showmount -e export list for expserv: /home/exp (everyone) NFS Client % uname -a FreeBSD ###########.ics.es.osaka-u.ac.jp 9.2-RELEASE-p4 FreeBSD 9.2-RELEASE-p4 #0: Tue Apr 8 18:05:06 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 % cd /tmp/work % df -k . Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ada0p4 507420 4204 462624 1% /tmp % ls ports_gtar.tar.gz % tar --version bsdtar 2.8.5 - libarchive 2.8.5 % tar tvzf ports_gtar.tar.gz drwxr-xr-x 0 root wheel 0 Apr 2 20:05 ./gtar/ drwxr-xr-x 0 root wheel 0 Apr 2 20:05 ./gtar/files/ -rw-r--r-- 0 root wheel 640 Jan 23 00:44 ./gtar/pkg-descr -rw-r--r-- 0 root wheel 1663 Jan 23 00:16 ./gtar/pkg-plist -rw-r--r-- 0 root wheel 125 Jan 23 00:30 ./gtar/distinfo -rw-r--r-- 0 root wheel 1136 Mar 14 01:11 ./gtar/Makefile -rw-r--r-- 0 root wheel 670 Nov 19 01:40 ./gtar/files/patch-configure % tar xvzf ports_gtar.tar.gz x ./gtar/ x ./gtar/files/ x ./gtar/pkg-descr x ./gtar/pkg-plist x ./gtar/distinfo x ./gtar/Makefile x ./gtar/files/patch-configure % ls -alR total 16 drwxr-xr-x 3 user wheel 512 Apr 25 16:30 ./ drwxrwxrwt 8 root wheel 1024 Apr 25 16:29 ../ drwxr-xr-x 3 user wheel 512 Apr 2 20:05 gtar/ -rw-r--r-- 1 user user 1970 Apr 25 16:21 ports_gtar.tar.gz ./gtar: total 28 drwxr-xr-x 3 user wheel 512 Apr 2 20:05 ./ drwxr-xr-x 3 user wheel 512 Apr 25 16:30 ../ -rw-r--r-- 1 user wheel 1136 Mar 14 01:11 Makefile -rw-r--r-- 1 user wheel 125 Jan 23 00:30 distinfo drwxr-xr-x 2 user wheel 512 Apr 2 20:05 files/ -rw-r--r-- 1 user wheel 640 Jan 23 00:44 pkg-descr -rw-r--r-- 1 user wheel 1663 Jan 23 00:16 pkg-plist ./gtar/files: total 12 drwxr-xr-x 2 user wheel 512 Apr 2 20:05 ./ drwxr-xr-x 3 user wheel 512 Apr 2 20:05 ../ -rw-r--r-- 1 user wheel 670 Nov 19 01:40 patch-configure % tar xvpzf ports_gtar.tar.gz x ./gtar/ x ./gtar/files/ x ./gtar/pkg-descr x ./gtar/pkg-plist x ./gtar/distinfo x ./gtar/Makefile x ./gtar/files/patch-configure % ls -alR total 16 drwxr-xr-x 3 user wheel 512 Apr 25 16:30 ./ drwxrwxrwt 8 root wheel 1024 Apr 25 16:29 ../ drwxr-xr-x 3 user wheel 512 Apr 2 20:05 gtar/ -rw-r--r-- 1 user user 1970 Apr 25 16:21 ports_gtar.tar.gz ./gtar: total 28 drwxr-xr-x 3 user wheel 512 Apr 2 20:05 ./ drwxr-xr-x 3 user wheel 512 Apr 25 16:30 ../ -rw-r--r-- 1 user wheel 1136 Mar 14 01:11 Makefile -rw-r--r-- 1 user wheel 125 Jan 23 00:30 distinfo drwxr-xr-x 2 user wheel 512 Apr 2 20:05 files/ -rw-r--r-- 1 user wheel 640 Jan 23 00:44 pkg-descr -rw-r--r-- 1 user wheel 1663 Jan 23 00:16 pkg-plist ./gtar/files: total 12 drwxr-xr-x 2 user wheel 512 Apr 2 20:05 ./ drwxr-xr-x 3 user wheel 512 Apr 2 20:05 ../ -rw-r--r-- 1 user wheel 670 Nov 19 01:40 patch-configure % showmount -e server Exports list on server: /home/server Everyone % sudo mount -t nfs -o nfsv3 server:/home/server /mnt % df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on server:/home/server 2097403588 121916992 1975486596 6% /mnt % cd /mnt/work % tar xvzf ports_gtar.tar.gz x ./gtar/ x ./gtar/files/ x ./gtar/pkg-descr x ./gtar/pkg-plist x ./gtar/distinfo x ./gtar/Makefile x ./gtar/files/patch-configure % ls -alR total 7 drwxr-x--- 3 user user 4 Apr 25 16:35 ./ drwxr-xr-x 24 root wheel 24 Apr 25 16:20 ../ drwxr-xr-x 3 user user 7 Apr 2 20:05 gtar/ -rw-r--r-- 1 user user 1970 Apr 25 16:21 ports_gtar.tar.gz ./gtar: total 12 drwxr-xr-x 3 user user 7 Apr 2 20:05 ./ drwxr-x--- 3 user user 4 Apr 25 16:35 ../ ---------- 1 user user 1136 Mar 14 01:11 Makefile ---------- 1 user user 125 Jan 23 00:30 distinfo drwxr-xr-x 2 user user 3 Apr 2 20:05 files/ ---------- 1 user user 640 Jan 23 00:44 pkg-descr ---------- 1 user user 1663 Jan 23 00:16 pkg-plist ./gtar/files: total 5 drwxr-xr-x 2 user user 3 Apr 2 20:05 ./ drwxr-xr-x 3 user user 7 Apr 2 20:05 ../ ---------- 1 user user 670 Nov 19 01:40 patch-configure % cd / % sudo umount /mnt Password: % sudo mount -t nfs -o nfsv2 server:/home/server /mnt % cd /mnt/work % df -k . Filesystem 1024-blocks Used Avail Capacity Mounted on server:/home/server -50080415 121917082 -171997497 -243% /mnt % rm -rf gtar % tar xvzf ports_gtar.tar.gz x ./gtar/ x ./gtar/files/ x ./gtar/pkg-descr x ./gtar/pkg-plist x ./gtar/distinfo x ./gtar/Makefile x ./gtar/files/patch-configure % ls -alR total 7 drwxr-x--- 3 user user 4 Apr 25 16:44 ./ drwxr-xr-x 24 root wheel 24 Apr 25 16:20 ../ drwxr-xr-x 3 user user 7 Apr 2 20:05 gtar/ -rw-r--r-- 1 user user 1970 Apr 25 16:21 ports_gtar.tar.gz ./gtar: total 12 drwxr-xr-x 3 user user 7 Apr 2 20:05 ./ drwxr-x--- 3 user user 4 Apr 25 16:44 ../ -rw-r--r-- 1 user user 1136 Mar 14 01:11 Makefile -rw-r--r-- 1 user user 125 Jan 23 00:30 distinfo drwxr-xr-x 2 user user 3 Apr 2 20:05 files/ -rw-r--r-- 1 user user 640 Jan 23 00:44 pkg-descr -rw-r--r-- 1 user user 1663 Jan 23 00:16 pkg-plist ./gtar/files: total 5 drwxr-xr-x 2 user user 3 Apr 2 20:05 ./ drwxr-xr-x 3 user user 7 Apr 2 20:05 ../ -rw-r--r-- 1 user user 670 Nov 19 01:40 patch-configure
Okay so it seems that this bug is also specific to NFSv3. Tried a few tests with Solaris 10 server exporting NFSv3/NFSv2 filesystems to Freebsd 10 clients. If we mount the filesystem specifically with NFSv2 specified in the /etc/fstab the problem goes away. Yet when we switch directly to NFSv3 in /etc/fstab the problem is back. It seems to be specific to regular files as directories are created correctly with proper permissions. The files are also created with correct ownership but the permissions are 0000. It doesn't have anything to do with the tar specifically. For example on the Freebsd 10 client I created: root@NFSClient:/tmp # ls -ld foobar/* -rw-r--r-- 1 root wheel 0 Jun 26 10:55 foobar/jack -rw-r--r-- 1 simon wheel 0 Jun 26 10:55 foobar/simon -rw-r--r-- 1 tom wheel 0 Jun 26 10:55 foobar/tom root@NFSClient:/tmp # tar cf foobar.tar foobar root@NFSCLient:/tmp # tar tvf foobar.tar drwxr-xr-x 0 root wheel 0 Jun 26 10:55 foobar/ -rw-r--r-- 0 tom wheel 0 Jun 26 10:55 foobar/tom -rw-r--r-- 0 root wheel 0 Jun 26 10:55 foobar/jack -rw-r--r-- 0 simon wheel 0 Jun 26 10:55 foobar/simon It seems that if I untar this file into the NFS filesystem (with the server allowing root on the client to create files/chown/chmod) the perms are: root@NFSCLient:/tmp # cd <NFSMOUNT> root@NFSClient:/<NFSMOUNT> # tar xf /tmp/foobar.tar root@NFSClient:/<NFSMOUNT> # cd foobar root@NFSClient:/<NFSMOUNT>/foobar # ls -l total 2 ---------- 1 root wheel 0 Jun 26 10:55 jack ---------- 1 simon wheel 0 Jun 26 10:55 simon ---------- 1 tom wheel 0 Jun 26 10:55 tom Yet if I copy the tar file into the <NFSMOUNT> directory and go to the NFS server and extract the same file the permissions are correct: root@NFSCLient:/<NFSMOUNT> # cp /tmp/foobar.tar . root@NFSServer:/<NFS-Exported-Filesystem> # tar xf foobar.tar root@NFSServer:/<NFS-Exported-Filesystem> # cd foobar root@NFSServer:/<NFS-Exported-Filesystem>/foobar # ls -l total 3 -rw-r--r-- 1 root root 0 Jun 26 10:55 jack -rw-r--r-- 1 simon root 0 Jun 26 10:55 simon -rw-r--r-- 1 tom root 0 Jun 26 10:55 tom So now the creation of the tar file is not the issue. It seems that only when the files are extracted on the NFSv3 mounted filesystem does this occur. If you change the NFS mount option to NFSv2 the problem goes away...
Hi, the same problem here, it seems that Solaris NFS server ignores "Mode" field of "Set file attributes" command issued by FreeBSD 10 NFS client. The same command issued by FreeBSD 8 NFS client was handled as expected including "Mode" field, only difference is in access and modification time flags, FreeBSD 8 uses "set to server time" flag, while FreeBSD 10 uses "set to client time" flag (see request/response dumps below). I will be grateful for any advices or workarounds. Martin. FreeBSD 10 request: NFS: Proc = 2 (Set file attributes) NFS: File handle = [6837] NFS: D06911FA089EF0630A003400000000001D901C010A000400000000007BC91B01 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 = (not set) NFS: Size = (not set) NFS: Access time = 04-Oct-14 18:10:43.000000 GMT (set to client time) NFS: Modification time = 04-Oct-14 18:10:43.000000 GMT (set to client time) Solaris 11 reply to FreeBSD 10 request: NFS: Proc = 2 (Set file attributes) NFS: Status = 0 (OK) NFS: Pre-operation attributes: NFS: Size = 0 bytes NFS: Modification time = 11-Jan-36 14:28:33.-574173475 GMT NFS: Attribute change time = 04-Oct-14 18:10:43.524178180 GMT 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 = 1176821104663, File id = 52 NFS: Last access time = 04-Oct-14 18:10:43.000000000 GMT NFS: Modification time = 04-Oct-14 18:10:43.000000000 GMT NFS: Attribute change time = 04-Oct-14 18:10:43.525300934 GMT FreeBSD 8 request: NFS: Proc = 2 (Set file attributes) NFS: File handle = [D037] NFS: D06911FA089EF0630A00380000000000A9901C010A000400000000007BC91B01 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 = (not set) NFS: Size = (not set) NFS: Access time = (set to server time) NFS: Modification time = (set to server time) Solaris 11 reply to FreeBSD 8 request: NFS: Proc = 2 (Set file attributes) NFS: Status = 0 (OK) NFS: Pre-operation attributes: NFS: Size = 0 bytes NFS: Modification time = 07-Feb-80 10:25:04.2130706433 GMT NFS: Attribute change time = 04-Oct-14 18:22:26.916078703 GMT 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 = 0, Group ID = 0 NFS: File size = 0, Used = 512 NFS: Special: Major = 4294967295, Minor = 4294967295 NFS: File system id = 1176821104663, File id = 56 NFS: Last access time = 04-Oct-14 18:22:26.917191243 GMT NFS: Modification time = 04-Oct-14 18:22:26.917191299 GMT NFS: Attribute change time = 04-Oct-14 18:22:26.917215996 GMT
Hi All, I can confirm Martin's NFS traces. I installed a brand new Solaris 11.2 server. I didn't configure anything except networking. Exported /var/mnt from the Solaris 11.2 server to a Freebsd 10.0 client and got the following traces: Freebsd 10.0 Client NFSv3 Request: NFS: ----- Sun NFS ----- NFS: NFS: Proc = 2 (Set file attributes) NFS: File handle = [FBA3] NFS: 1E59EFB108C388D40A00200000000000F8B80 5000A0004000000000052E40100 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 = (not set) NFS: Size = (not set) NFS: Access time = 02-Oct-14 14:47:23.000000 GMT (set to client time) NFS: Modification time = 02-Oct-14 14:47:23.000000 GMT (set to client time) Solaris 11.2 NFS Server Response NFS: ----- Sun NFS ----- NFS: NFS: Proc = 2 (Set file attributes) NFS: Status = 0 (OK) NFS: Pre-operation attributes: NFS: Size = 0 bytes 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: 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 14:47:23.000000000 GMT NFS: Modification time = 02-Oct-14 14:47:23.000000000 GMT NFS: Attribute change time = 02-Oct-14 10:47:57.038686069 GMT Freebsd 8.0 Client NFS: ----- Sun NFS ----- NFS: NFS: Proc = 2 (Set file attributes) NFS: File handle = [27D9] NFS: 1E59EFB108C388D40A0021000000000025C205000A0004000000000052E40100 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 = (not set) NFS: Size = (not set) NFS: Access time = (set to server time) NFS: Modification time = (set to server time) Solaris 11.2 NFS Server response NFS: ----- Sun NFS ----- NFS: NFS: Proc = 2 (Set file attributes) NFS: Status = 0 (OK) NFS: Pre-operation attributes: NFS: Size = 0 bytes NFS: Modification time = 13-Nov-87 14:32:33.2130706433 GMT NFS: Attribute change time = 02-Oct-14 14:03:35.971683411 GMT NFS: 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 = 0, Group ID = 0 NFS: File size = 0, Used = 512 NFS: Special: Major = 4294967295, Minor = 4294967295 NFS: File system id = 1198295941134, File id = 33 NFS: Last access time = 02-Oct-14 14:03:35.979188718 GMT NFS: Modification time = 02-Oct-14 14:03:35.979188834 GMT NFS: Attribute change time = 02-Oct-14 14:03:35.979237259 GMT So it looks like (to me) that with FreeBSD 8.0 it would send set file attributes in one request and set access time/modification time in a follow up request. As of FreeBSD 9.0 and onwards the FreeBSD client sends a file mode request and access time request in one packet. Solaris is responding OK in with respect to the access time and modification time change but ignoring the file mode additional change. You can see in the FreeBSD 8.0 the Access time/Modification time is not set in the mode change. Any way we can go back to doing this again? Right now NFSv3 is broken until this gets resolved. I own a Oracle Contract support right now so I've also filed a ticket with them. Yet this issue seems to be not prevalent with linux or Solaris Clients. For example a Scientfic Linux Client 6.3 and Solaris 11.2 response was the following: Scientfic Linux NFS Client 6.3 NFS: ----- Sun NFS ----- NFS: NFS: Proc = 2 (Set file attributes) NFS: File handle = [07A3] NFS: 1E59EFB108C388D40A001F00000000003BB805000A0004000000000052E40100 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 = (not set) NFS: Size = (not set) NFS: Access time = (do not set) NFS: Modification time = (do not set) Solaris 11.2 NFS Server Response NFS: ----- Sun NFS ----- NFS: NFS: Proc = 2 (Set file attributes) NFS: Status = 0 (OK) NFS: Pre-operation attributes: NFS: Size = 0 bytes NFS: Modification time = 05-Sep-14 21:14:33.000000000 GMT NFS: Attribute change time = 02-Oct-14 10:32:12.444447250 GMT NFS: 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 = 1061, Group ID = 2500 NFS: File size = 0, Used = 512 NFS: Special: Major = 4294967295, Minor = 4294967295 NFS: File system id = 1198295941134, File id = 31 NFS: Last access time = 02-Oct-14 14:33:15.191601635 GMT NFS: Modification time = 05-Sep-14 21:14:33.000000000 GMT NFS: Attribute change time = 02-Oct-14 10:32:12.457265934 GMT So it looks like both Linux and FreeBSD pre 9.X does not have the issue. The question is it legal to request both modification time changes and mode changes within the same packet? What happens if you could change the mode but not the access time what would you expect to get back from the server Status NOT OK?
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.
Now the somewhat good news. So after getting the SR report back from Oracle I started to dive into the FreeBSD NFS client code. So this is what I modified and how I got the issue (which seems to be) resolved. On my FreeBSD 10 station: # uname -a FreeBSD NFSCLIENT 10.1-BETA1 FreeBSD 10.1-BETA1 #4 r271672M: Tue Oct 7 16:52:00 EDT 2014 NFSCLIENT:/usr/obj/usr/src/sys/GENERIC amd64 I edited the files: nfs_subs.c NFSCLIENT:/usr/src/sys/nfsclient # ls nfs.h nfs_krpc.c nfs_subs.c nfsargs.h nfsnode.h nfs_bio.c nfs_nfsiod.c nfs_vfsops.c nfsm_subs.h nfsstats.h nfs_kdtrace.c nfs_node.c nfs_vnops.c nfsmount.h nlminfo.h I commented out the following lines in this file if (va->va_atime.tv_sec != VNOVAL) { // if ((va->va_vaflags & VA_UTIMES_NULL) == 0) { // tl = nfsm_build_xx(3 * NFSX_UNSIGNED, mb, bpos); // *tl++ = txdr_unsigned(NFSV3SATTRTIME_TOCLIENT); // txdr_nfsv3time(&va->va_atime, tl); // } else { tl = nfsm_build_xx(NFSX_UNSIGNED, mb, bpos); *tl = txdr_unsigned(NFSV3SATTRTIME_TOSERVER); // } I also blocked out the following: // if ((va->va_vaflags & VA_UTIMES_NULL) == 0) { // tl = nfsm_build_xx(3 * NFSX_UNSIGNED, mb, bpos); // *tl++ = txdr_unsigned(NFSV3SATTRTIME_TOCLIENT); // txdr_nfsv3time(&va->va_mtime, tl); // } else { tl = nfsm_build_xx(NFSX_UNSIGNED, mb, bpos); *tl = txdr_unsigned(NFSV3SATTRTIME_TOSERVER); // } How I read this is if the vaflags are set to NULL then let the NFS server set the atime and mtime based on the server's Clock. We're not done yet. To use this code you also seem to have to mount the filesystem with the "oldnfs" flag. For example in my /etc/fstab I have: NFSSERVER:/var/mnt /mnt oldnfs rw,soft 0 0 Now once I re-compiled the FreeBSD kernel to take the above changes into account and of course mount the filesystem with the "oldnfs" flags in place the problems (for what I see) went away. For example: NFSCLIENT:/# mount /mnt NFSCLIENT:/# mount NFSSERVER:/var/mnt on /mnt (oldnfs) NFSCLIENT:/# cd /mnt NFSCLIENT:/mnt# tar xf ~user/foo.tar Now foo.tar has only one file in it BOB which has perms of 0644. Now doing a directory listing: # ls -l NFSCLIENT:/mnt # ls -l total 1 -rw-r--r-- 1 user group 0 Oct 8 10:28 BOB So far so good. Now this seems to resolve my problem right now but I'm not sure whether or not this is going to open up other problems in the future.
I will work on a mount option that forces the client to set the times to the server's value as a work around for this. I'll leave this open until the mount option has been implemented. Fyi, the NFSv3 protocol (RFC-1813) does not provide any way to set an ACL. (That is a Solaris unpublished protocol, unless you are using NFSv4.) Also, there is nothing in RFC-1813 that suggests that only one attribute can be set in a Setattr RPC.
A commit references this bug: Author: rmacklem Date: Sun Dec 28 21:13:53 UTC 2014 New revision: 276347 URL: https://svnweb.freebsd.org/changeset/base/276347 Log: r245508 modified the NFS client's Setattr RPC to use VA_UTIMES_NULL to indicate whether it should set the time to the current tod on the server. This had the side effect of making the NFS client use the client's timestamp for exclusive create, starting with FreeBSD9.2. Unfortunately a bug in some Solaris NFS servers causes these servers to return NFS_OK to the Setattr RPC done during exclusive create, but not actually set the file's mode, leaving the file's mode == 0. This patch restores the NFS client's behaviour to use the server's tod for the exclusive open's Setattr RPC, to avoid the Solaris server bug and to restore the pre-FreeBSD9.2 NFS behaviour. Discussed on: freebsd-fs PR: 186293 MFC after: 3 months Changes: head/sys/fs/nfsclient/nfs_clport.c
To originators/assignees of this PR: A commit to the tree references this PR, however the PR is still in a non-closed state. Please review this PR and close as appropriate, or if closing the PR requires a merge to stable/10, please let re@ know as soon as possible. Thank you. Glen
Hi All, I've tested the patch and it works great I no longer have any issues. This bug can be closed.
Closing per comment #12.