Bug 8660 - file ACEs not inherited on NFSv4 mountpoints (directories are okay)
file ACEs not inherited on NFSv4 mountpoints (directories are okay)
Status: NEW
Product: Samba 3.6
Classification: Unclassified
Component: VFS Modules
3.6.1
All Solaris
: P5 major
: ---
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-14 11:45 UTC by sven friedmann
Modified: 2012-01-13 11:16 UTC (History)
1 user (show)

See Also:


Attachments
samba build details (12.95 KB, text/plain)
2011-12-14 11:47 UTC, sven friedmann
no flags Details
smb.conf (2.29 KB, application/octet-stream)
2011-12-14 11:47 UTC, sven friedmann
no flags Details
aces not inherited on nfsv4 mountpoint (941.92 KB, text/x-log)
2011-12-14 11:48 UTC, sven friedmann
no flags Details
aces inherited on zfs mountpoint (1.09 MB, text/x-log)
2011-12-14 11:48 UTC, sven friedmann
no flags Details
truss output create new file on nfs4 (no rename) (172.88 KB, application/octet-stream)
2011-12-15 14:21 UTC, sven friedmann
no flags Details
samba log creating new file (no rename) (358.78 KB, text/x-log)
2011-12-15 14:26 UTC, sven friedmann
no flags Details
truss output create new file on zfs (no rename) (191.71 KB, application/octet-stream)
2011-12-15 14:34 UTC, sven friedmann
no flags Details
samba log - file upload by debian smbclient 3.6.1 (119.15 KB, text/x-log)
2011-12-21 09:24 UTC, sven friedmann
no flags Details
windows xp - cmd create rename file (224.91 KB, text/x-log)
2012-01-10 17:11 UTC, sven friedmann
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description sven friedmann 2011-12-14 11:45:19 UTC
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]#
Comment 1 sven friedmann 2011-12-14 11:47:09 UTC
Created attachment 7179 [details]
samba build details
Comment 2 sven friedmann 2011-12-14 11:47:45 UTC
Created attachment 7180 [details]
smb.conf
Comment 3 sven friedmann 2011-12-14 11:48:14 UTC
Created attachment 7181 [details]
aces not inherited on nfsv4 mountpoint
Comment 4 sven friedmann 2011-12-14 11:48:32 UTC
Created attachment 7182 [details]
aces inherited on zfs mountpoint
Comment 5 Jeremy Allison 2011-12-15 00:47:07 UTC
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.
Comment 6 Jeremy Allison 2011-12-15 01:00:23 UTC
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.
Comment 7 sven friedmann 2011-12-15 14:21:12 UTC
Created attachment 7190 [details]
truss output create new file on nfs4 (no rename)
Comment 8 sven friedmann 2011-12-15 14:22:36 UTC
(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.
Comment 9 sven friedmann 2011-12-15 14:26:03 UTC
Created attachment 7191 [details]
samba log creating new file (no rename)
Comment 10 sven friedmann 2011-12-15 14:34:49 UTC
Created attachment 7192 [details]
truss output create new file on zfs (no rename)
Comment 11 Jeremy Allison 2011-12-19 23:04:16 UTC
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.
Comment 12 sven friedmann 2011-12-20 09:47:46 UTC
(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.
Comment 13 Jeremy Allison 2011-12-20 23:39:28 UTC
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.
Comment 14 Jeremy Allison 2011-12-20 23:47:29 UTC
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.
Comment 15 sven friedmann 2011-12-21 09:24:05 UTC
Created attachment 7210 [details]
samba log - file upload by debian smbclient 3.6.1
Comment 16 sven friedmann 2011-12-21 09:24:29 UTC
(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]#
Comment 17 Jeremy Allison 2011-12-21 22:41:26 UTC
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.
Comment 18 sven friedmann 2011-12-22 17:02:25 UTC
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?
Comment 19 Jeremy Allison 2012-01-07 00:39:25 UTC
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.
Comment 20 sven friedmann 2012-01-10 17:11:14 UTC
Created attachment 7235 [details]
windows xp - cmd create rename file
Comment 21 sven friedmann 2012-01-10 17:14:56 UTC
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]#
Comment 22 Jeremy Allison 2012-01-12 18:53:21 UTC
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.
Comment 23 sven friedmann 2012-01-13 11:16:16 UTC
(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.