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
zfs or ufs? On 08/08/12 08:01, IngeKo at gmx.net 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 >
x86 zfs and Sparc ufs. Problem happens on both platforms though. On 08/08/12 08:01, gaiseric.vandal at gmail.com wrote:> zfs or ufs? > > On 08/08/12 08:01, IngeKo at gmx.net 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