[Samba] 3.0.9->3.0.37 Deleting files not working

[Gaiseric Vandal]

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, IngeKo at gmx.net wrote:
> 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