[Samba] 3.0.9->3.0.37 Deleting files not working

[IngeKo at gmx.net]

Hello,

we were using Samba 3.0.9 on Solaris 10 x86 and Sparc in a productive environment and upgraded to 3.0.37 to fix a security vulnerability.
Now we experience problems in some circumstances when we try to delete a file from a share mounted by a Windows Client.

The share is named ZENTRAL. This is the share entry:
[ZENTRAL]
comment=Ablage ZENTRAL
path=/daten/ablagen/ZENTRAL
case sensitive=no
create mask=0770
valid users=@ZENTRAL
write list=@ZENTRAL
force group=ZENTRAL

These are the unix rights:
drwxrwx---   2 root     other        512 Aug  8 11:15 .
drwxrwx--x  35 root    ZENTRAL     2048 Aug  8 10:26 .. (This is the share root directory: /daten/ablagen/ZENTRAL)
-rwxrwxrwx   1 user1  ZENTRAL        0 Aug  8 11:15 neu.txt

user1 belongs to the groups other and ZENTRAL and is able to delete this file Using a unix shell and navigate to the directory but he is not able to delete it using the samba share. He gets a permission denied.

This behaviour is new. With 3.0.9 it is possible to delete this file. When i chgrp the directory "." to ZENTRAL everything works as expected with 3.0.37 too. The problem only exists, when the "." directory does not have the same group as the share.

If needed, here is our global section. Some of these entries could be plain wrong respectively not needed, but we are not able to change them easily because of company guidelines.

[global]
os level=65
password level=1
security=user
encrypt passwords=yes
smb passwd file=/usr/local/samba/private/smbpasswd
workgroup=ourgroup
guest account=nobody
max log size=30
share modes=yes
locking=yes
strict locking=yes
lock directory=/var/adm/samba/locks
;   max log size = 5000
log level=1
log file=/var/adm/samba/smb.log
pid directory=/var/run
server string=%h
force directory mode=0770
browseable=no
follow symlinks=no
preserve case=no
short preserve case=no
case sensitive=no
oplocks=no
level2 oplocks=no
wins support=yes


The question is: Is this a bug or feature? If feature, then what is the intention behind this feature, as the user has delete rights for this file using unix and so should have this rights using samba too i think.
Is there a conf parameter that we can set to get back the old behaviour? 

With kind regards,
Björn