Re: [Samba] 3.0.9-3.0.37 Deleting files not working
Nope. We are really using Samba 3.0.37 on x86 with ZFS and were using 3.0.9 there too. We are not using any of the extended ACLs provided by the ZFS file system at all and are experiencing the same problem on UFS too, so i assume the problem is not ZFS related. Any other ideas on this problem? Ho do other samba versions react on the ACLs stated below? I cannot try other samba versions here easily. Original-Nachricht Datum: Thu, 09 Aug 2012 09:43:25 -0400 Von: Gaiseric Vandal gaiseric.van...@gmail.com An: samba@lists.samba.org Betreff: Re: [Samba] 3.0.9-3.0.37 Deleting files not working Samba 3.0.x from source code does not include the zfs modules. The version bundled with the OS (from Sun) has it backported.Assuming you are using the version from Sun? They should be up to 3.5.x. Samba permissions with UFS did not cause as much headache for me. On 08/09/12 03:02, ing...@gmx.net wrote: x86 zfs and Sparc ufs. Problem happens on both platforms though. On 08/08/12 08:01, gaiseric.van...@gmail.com wrote: zfs or ufs? On 08/08/12 08:01, ing...@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 other512 Aug 8 11:15 . drwxrwx--x 35 rootZENTRAL 2048 Aug 8 10:26 .. (This is the share root directory: /daten/ablagen/ZENTRAL) -rwxrwxrwx 1 user1 ZENTRAL0 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 -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] 3.0.9-3.0.37 Deleting files not working
x86 zfs and Sparc ufs. Problem happens on both platforms though. On 08/08/12 08:01, gaiseric.van...@gmail.com wrote: zfs or ufs? On 08/08/12 08:01, ing...@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 other512 Aug 8 11:15 . drwxrwx--x 35 rootZENTRAL 2048 Aug 8 10:26 .. (This is the share root directory: /daten/ablagen/ZENTRAL) -rwxrwxrwx 1 user1 ZENTRAL0 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
Re: [Samba] 3.0.9-3.0.37 Deleting files not working
I ran into issues when I switched to zfs. the problem is that ZFS ACL's seem be more similar to NTFS ACL's (compared to UFS-NTFS compatibility.) But you can run into an issue were perms that are additive in unix are interpreted as least permissive or deny trumps all in Windows. For example, a 770 perm in unix means user and group are granted full perms, no perms are granted to anyone else.In Windows this can get interpreted as deny the world even if the user or group had explicitly been granted permissions. Samba 3.0.x from source code does not include the zfs modules. The version bundled with the OS (from Sun) has it backported.Assuming you are using the version from Sun? They should be up to 3.5.x. I added some vfs and nfs parameters in my share configs. I had to open a support ticket with Sun/Oracle, since Office files would get deleted on the 5th or 7th save when Office tried to rewrite the entire file. [projects] path = /export/Projects #valid users = @group1, user1 read only = No create mask = 0770 force create mode = 0600 directory mask = 0775 force directory mode = 0600 vfs objects = zfsacl nfs4: mode = special zfsacl: acesort = dontcare inherit acls = Yes nfs4:acedup = merge nfs4:chown = yes The inheritance thing is also a little tricky - even tho zfs supports inheritance, I think the Window inheritance rules are uses for the Windows clients- which is fine. (the latest kernel update seems to have changed something tho.) Setting zfs ACL perms via command line is a PITA. It is probably easier for the windows owner of the file to reset permissions- he or she may get a message that the perms are incorrectly ordered, and he/she may need to clear out explicit deny access control entries. I skipped the valid users entry in the share config , since the permissions are enforced via ACL's anyway. Samba permissions with UFS did not cause as much headache for me. On 08/09/12 03:02, ing...@gmx.net wrote: x86 zfs and Sparc ufs. Problem happens on both platforms though. On 08/08/12 08:01, gaiseric.van...@gmail.com wrote: zfs or ufs? On 08/08/12 08:01, ing...@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 other512 Aug 8 11:15 . drwxrwx--x 35 rootZENTRAL 2048 Aug 8 10:26 .. (This is the share root directory: /daten/ablagen/ZENTRAL) -rwxrwxrwx 1 user1 ZENTRAL0 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
[Samba] 3.0.9-3.0.37 Deleting files not working
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 other512 Aug 8 11:15 . drwxrwx--x 35 rootZENTRAL 2048 Aug 8 10:26 .. (This is the share root directory: /daten/ablagen/ZENTRAL) -rwxrwxrwx 1 user1 ZENTRAL0 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
Re: [Samba] 3.0.9-3.0.37 Deleting files not working
zfs or ufs? On 08/08/12 08:01, ing...@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 other512 Aug 8 11:15 . drwxrwx--x 35 rootZENTRAL 2048 Aug 8 10:26 .. (This is the share root directory: /daten/ablagen/ZENTRAL) -rwxrwxrwx 1 user1 ZENTRAL0 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
