x86 zfs and Sparc ufs. Problem happens on both platforms though. On 08/08/12 08:01, [email protected] wrote:
> zfs or ufs? > > On 08/08/12 08:01, [email protected] wrote: > > 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 > > > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
