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.

(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.

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.

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.

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.

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.