Problem occurs on Solaris 10 and Solaris 11 (Sparc/x86) with Solaris Samba 3.5.8/3.5.10 and Vanilla 3.3.16/3.6.1 Builds. Setup consists of following parts: NFSv4 Server is a ZFS Storage Appliance serving "/export/circular/groups". NFS Share got mounted on Solaris 11 Client on "/space/groups". Mountpoints: /samba/zfs on rpool/samba/zfs read/write/setuid/devices/rstchown/nonbmand/exec/xattr/atime/dev=1f10009 on Wed Dec 14 11:34:12 2011 /space/groups on 10.1.0.51:/export/circular/groups remote/read/write/setuid/devices/norstchown/xattr/dev=8880001 on Wed Dec 14 11:35:55 2011 1.) failed TEST CASE on CIFS Share "[nfs]" via nfsv4 mountpoint 1.a) ACL on NFSv4 Dir root@supernova2:~ [sol11]# ls -Vd /space/groups/nfs drwxrwx---+ 2 sfriedmann technik 2 Dec 14 11:45 /space/groups/nfs owner@:rwxpdDaARWcCos:fd-----:allow group@:rwxpd-aARWc--s:fd-----:allow user:Administrator:rwxpdDaARWcCos:fd-----:allow group:fileserver admins:rwxpdDaARWcCos:fd-----:allow root@supernova2:/etc/samba [sol11]# 1.b) create file/directory with local user "sfriedmann" root@supernova2:/space/groups/nfs [sol11]# id -a sfriedmann uid=1100(sfriedmann) gid=3000(technik) groups=3000(technik),513(Domain Users),3100(ESX Admins),10000(fileserver admins) root@supernova2:/space/groups/nfs [sol11]# su sfriedmann bash: /root/.bashrc: Permission denied bash-4.1$ pwd /space/groups/nfs bash-4.1$ mkdir test_dir bash-4.1$ touch test_file bash-4.1$ bash-4.1$ bash-4.1$ ls -Vd test_dir/ drwxrwx---+ 2 sfriedmann technik 2 Dec 14 12:23 test_dir/ owner@:rwxpdDaARWcCos:fd-----:allow group@:rwxpd-aARWc--s:fd-----:allow user:Administrator:rwxpdDaARWcCos:fd-----:allow group:fileserver admins:rwxpdDaARWcCos:fd-----:allow bash-4.1$ bash-4.1$ bash-4.1$ ls -Vd test_file -rwxrwx---+ 1 sfriedmann technik 0 Dec 14 12:23 test_file owner@:rwxpdDaARWcCos:-------:allow group@:rwxpd-aARWc--s:-------:allow user:Administrator:rwxpdDaARWcCos:-------:allow group:fileserver admins:rwxpdDaARWcCos:-------:allow bash-4.1$ 1.c) create file/directory via cifs client (see attachment "wxp-dom_create_file-dir_on_nfs4.log")and check ACLs root@supernova2:~ [sol11]# ls -Vd /space/groups/nfs/cifs_dir/ drwxrwx---+ 2 adtest Domain Users 2 Dec 14 12:26 /space/groups/nfs/cifs_dir/ owner@:rwxpdDaARWcCos:fd-----:allow group@:rwxpd-aARWc--s:fd-----:allow user:Administrator:rwxpdDaARWcCos:fd-----:allow group:fileserver admins:rwxpdDaARWcCos:fd-----:allow root@supernova2:~ [sol11]# root@supernova2:~ [sol11]# root@supernova2:~ [sol11]# ls -Vd /space/groups/nfs/cifs_file.txt -rw-r--r-- 1 adtest Domain Users 0 Dec 14 12:26 /space/groups/nfs/cifs_file.txt owner@:rw-p--aARWcCos:-------:allow group@:r-----a-R-c--s:-------:allow everyone@:r-----a-R-c--s:-------:allow root@supernova2:~ [sol11]# 2.) working TEST CASE on CIFS Share "[zfs]" via local zfs mountpoint 2.a) ACL on local ZFS Dir root@supernova2:~ [sol11]# ls -Vd /samba/zfs drwxrwx---+ 2 sfriedmann technik 3 Dec 14 11:47 /samba/zfs owner@:rwxpdDaARWcCos:fd-----:allow group@:rwxpd-aARWc--s:fd-----:allow user:Administrator:rwxpdDaARWcCos:fd-----:allow group:fileserver admins:rwxpdDaARWcCos:fd-----:allow root@supernova2:~ [sol11]# 2.b) create file/directory with local user "sfriedmann" root@supernova2:/samba/zfs [sol11]# id -a sfriedmann uid=1100(sfriedmann) gid=3000(technik) groups=3000(technik),513(Domain Users),3100(ESX Admins),10000(fileserver admins) root@supernova2:/samba/zfs [sol11]# su sfriedmann bash: /root/.bashrc: Permission denied bash-4.1$ pwd /samba/zfs bash-4.1$ mkdir test_dir bash-4.1$ touch test_file bash-4.1$ bash-4.1$ bash-4.1$ ls -Vd test_dir/ drwxrwx---+ 2 sfriedmann technik 2 Dec 14 12:34 test_dir/ owner@:rwxpdDaARWcCos:fd----I:allow group@:rwxpd-aARWc--s:fd----I:allow user:Administrator:rwxpdDaARWcCos:fd----I:allow group:fileserver admins:rwxpdDaARWcCos:fd----I:allow bash-4.1$ bash-4.1$ bash-4.1$ ls -Vd test_file -rwxrwx---+ 1 sfriedmann technik 0 Dec 14 12:34 test_file owner@:rwxpdDaARWcCos:------I:allow group@:rwxpd-aARWc--s:------I:allow user:Administrator:rwxpdDaARWcCos:------I:allow group:fileserver admins:rwxpdDaARWcCos:------I:allow bash-4.1$ 2.c) create file/directory via cifs client (see attachment "wxp-dom_create_file-dir_on_zfs.log")and check ACLs root@supernova2:~ [sol11]# ls -Vd /samba/zfs/cifs_dir/ drwxrwx---+ 2 adtest Domain Users 2 Dec 14 12:35 /samba/zfs/cifs_dir/ owner@:rwxpdDaARWcCos:fd----I:allow group@:rwxpd-aARWc--s:fd----I:allow user:Administrator:rwxpdDaARWcCos:fd----I:allow group:fileserver admins:rwxpdDaARWcCos:fd----I:allow root@supernova2:~ [sol11]# root@supernova2:~ [sol11]# root@supernova2:~ [sol11]# ls -Vd /samba/zfs/cifs_file.txt -rwxrwx---+ 1 adtest Domain Users 0 Dec 14 12:35 /samba/zfs/cifs_file.txt owner@:rwxpdDaARWcCos:------I:allow group@:rwxpd-aARWc--s:------I:allow user:Administrator:rwxpdDaARWcCos:------I:allow group:fileserver admins:rwxpdDaARWcCos:------I:allow root@supernova2:~ [sol11]#
Created attachment 7179 [details] samba build details
Created attachment 7180 [details] smb.conf
Created attachment 7181 [details] aces not inherited on nfsv4 mountpoint
Created attachment 7182 [details] aces inherited on zfs mountpoint
Can you get me a truss output of the succeeding and failing test cases as well please ? I'd like to see what system calls are being made here. My first thought was that it may be a failure of NFS to store the dos attributes in an extended attribute, but that doesn't seem to be the case from the logs. I'm assuming these logs are from 3.6.1 ? Please let me know if this is not the case. Jeremy.
Looking at the logs the client creates 'Neu Textdokument.txt' which is then renamed to cifs_file.txt. I don't see anything that should disturb the ACL inheritance over NFS when 'Neu Textdokument.txt' is created. It would be interesting to see the log when the client simply creates a new file with that name, and not changes the name to cifs_file.txt. Examine the ACL on the file 'Neu Textdokument.txt', and see if it is correct. If it is then the problem occurs on the rename. If it's wrong, then the problem occurs on the create call. That might help to track this down. Jeremy.
Created attachment 7190 [details] truss output create new file on nfs4 (no rename)
(In reply to comment #5) > Can you get me a truss output of the succeeding and failing test cases as well > please ? I'd like to see what system calls are being made here. > > My first thought was that it may be a failure of NFS to store the dos > attributes in an extended attribute, but that doesn't seem to be the case from > the logs. > > I'm assuming these logs are from 3.6.1 ? Please let me know if this is not the > case. > > Jeremy. truss output on attachment. you're right, version is 3.6.1.
Created attachment 7191 [details] samba log creating new file (no rename)
Created attachment 7192 [details] truss output create new file on zfs (no rename)
Ok, I took a close look at the truss output when creating the new document on the NFS mount, and I don't see *any* acl calls to set the acl on the new file at all - which means it doesn't change the inherited ACL in any way from the way it is set on file create. It's also quite happily getting and setting the user.DOSATTRIB extended attributes on the new file, so that isn't the problem. Have you tried just doing a "touch newfile.txt" on the NFS mount from the Solaris client given the directory ACLs set the way they are and seeing if the file is created the same way with the same ACL ? What was the ACL like on the new file created without the rename ? Jeremy.
(In reply to comment #11) > Ok, I took a close look at the truss output when creating the new document on > the NFS mount, and I don't see *any* acl calls to set the acl on the new file > at all - which means it doesn't change the inherited ACL in any way from the > way it is set on file create. > > It's also quite happily getting and setting the user.DOSATTRIB extended > attributes on the new file, so that isn't the problem. > > Have you tried just doing a "touch newfile.txt" on the NFS mount from the > Solaris client given the directory ACLs set the way they are and seeing if the > file is created the same way with the same ACL ? > > What was the ACL like on the new file created without the rename ? > > Jeremy. Hi Jeremy, on solaris client side it's working correctly. root@supernova2:/space/groups/nfs [sol11]# su adtest bash: /root/.bashrc: Permission denied bash-4.1$ id -a uid=1129(adtest) gid=513(Domain Users) groups=513(Domain Users),6666(azubis),2000(gl),3000(technik) bash-4.1$ pwd /space/groups/nfs bash-4.1$ bash-4.1$ ls -Vd . drwxrwx---+ 2 sfriedmann technik 4 Dec 20 2011 . owner@:rwxpdDaARWcCos:fd-----:allow group@:rwxpd-aARWc--s:fd-----:allow user:Administrator:rwxpdDaARWcCos:fd-----:allow group:fileserver admins:rwxpdDaARWcCos:fd-----:allow bash-4.1$ bash-4.1$ touch newfile.txt bash-4.1$ bash-4.1$ ls -Vd newfile.txt -rwxrwx---+ 1 adtest Domain Users 0 Dec 20 2011 newfile.txt owner@:rwxpdDaARWcCos:-------:allow group@:rwxpd-aARWc--s:-------:allow user:Administrator:rwxpdDaARWcCos:-------:allow group:fileserver admins:rwxpdDaARWcCos:-------:allow bash-4.1$ Somewhere in the samba code the ACL/ACE inheritance during filecreation is broken on NFS4 mounts.
I can't see anywhere where the ACL is getting set in attachment 7191 [details] (samba log creating new file (no rename)). What client are you using to create this file ? Can you do the following for me - use smbclient to create a new file test.txt inside the NFSv4 mounted directory, and then terminate the connection. Check if the inherited ACL on test.txt is correct. Jeremy.
FYI - the reason I'm asking for that test is that all it will exercise is the raw Samba create code - no possible other client changes. It will at least tell us if the problem is there. Jeremy.
Created attachment 7210 [details] samba log - file upload by debian smbclient 3.6.1
(In reply to comment #13) > I can't see anywhere where the ACL is getting set in attachment 7191 [details] (samba log > creating new file (no rename)). > > What client are you using to create this file ? I've tried serveral windows clients. winxp x86 sp3, win7 x64 sp1, w2k8r2 sp1 > Can you do the following for me - use smbclient to create a new file test.txt > inside the NFSv4 mounted directory, and then terminate the connection. Check if > the inherited ACL on test.txt is correct. > > Jeremy. Using smbclient to create a new file looks good. See attachment "smbclient_debian_create_new_file.log" * Debian smbclient: sven@debian - 10:15:25 /tmp $ smbclient -U adtest -W circint //10.1.0.102/nfs Enter adtest's password: Domain=[CIRCULAR] OS=[Unix] Server=[Samba 3.6.1] smb: \> put newfile.txt putting file newfile.txt as \newfile.txt (0.0 kb/s) (average 0.0 kb/s) smb: \> exit sven@debian - 10:15:41 /tmp $ * Solaris 11 NFSv4 mountpoint: root@supernova2:/space/groups/nfs [sol11]# ls -Vd newfile.txt -rwxrwx---+ 1 adtest Domain Users 0 Dec 21 2011 newfile.txt owner@:rwxpdDaARWcCos:-------:allow group@:rwxpd-aARWc--s:-------:allow user:Administrator:rwxpdDaARWcCos:-------:allow group:fileserver admins:rwxpdDaARWcCos:-------:allow root@supernova2:/space/groups/nfs [sol11]#
Ok, if the smbclient create makes a file with the correct ACL, then that means there's no error in the core NtCreateX code. What I'd like you to try next is to map the NFS mounted Samba share from a Windows command line cmd.exe, and then create the file using a command line of: echo >testfile.txt instead of using Explorer. Does that also create a file with a correct ACL ? If so, then it's an issue with the way Explorer is doing things and this narrows the investigation down considerably. Jeremy.
So, the cmd style creation is working flawless. Wow. It's seem to be a win explorer problem. What can i do? Do you need a wireshark trace or something else?
If you create the file using: echo >testfile.txt then do a command line rename: ren testfile.txt test1.txt does the same problem occur ? I'm trying to track down the minimal set of operations that cause the difference. Jeremy.
Created attachment 7235 [details] windows xp - cmd create rename file
nor, problem doesn't occur on cmd. file aces are okay. root@supernova2:/space/groups/nfs [sol11]# ls -Vd test1.txt -rwxrwx---+ 1 adtest Domain Users 30 Jan 10 18:02 test1.txt owner@:rwxpdDaARWcCos:-------:allow group@:rwxpd-aARWc--s:-------:allow user:Administrator:rwxpdDaARWcCos:-------:allow group:fileserver admins:rwxpdDaARWcCos:-------:allow root@supernova2:/space/groups/nfs [sol11]#
So, just trying to understand - the command line create and rename log you sent shows success, right (i.e. the ACLs are correct) ? So I should compare this with attachment 7191 [details] showing a log of creating a new file using explorer that corrupts the ACLs, yes ? Jeremy.
(In reply to comment #22) > So, just trying to understand - the command line create and rename log you sent > shows success, right (i.e. the ACLs are correct) ? right! > So I should compare this with attachment 7191 [details] showing a log of creating a new file using explorer that corrupts the ACLs, yes ? yes, there have to be the difference.
I've seen NFS4 mounts work properly with more recent samba versions and vfs nfs4acl_xattr.