[Samba] Cannot delete/write after system update

[Rowland Penny]

On 29/04/15 04:04, Bob Bell wrote:
> On Mon, Apr 27, 2015 at 10:56:05AM +0100, Rowland Penny wrote:
>> On 26/04/15 05:38, Bob Bell wrote:
>>> After upgrading one of my home servers, and I can no longer delete or
>>> write files via Samba.  I would very much appreciate assitance.  I
>>> will explain my situation and provide logs for the case of deleting a
>>> simple file.
>>>
>>> My configuration is to access my shares as a guest, which should be
>>> mapped to the smbuser Linux account.
>>>
>>> To achieve this I have set the following globally:
>>>   map to guest = Bad Password ## I added this after the upgrade, to
>>> replace "security = share"
>>>   guest ok = yes
>>>   guest account = smbuser
>>>
>>> And the following on my share:
>>>   public = yes
>>>   writeable = yes
>>>   guest ok = yes ## Redundant, I guess
>>>   create mask = 0664
>>>   directory mask = 6775
>>>
>>> My desire is that if a directory is writable by the smbuser group,
>>> then it is writable via Samba.  But this is not what I see (since the
>>> upgrade).
>>>
>>> If I create a directory owned by smbuser:smbuser with 0777
>>> permissions, I can upload a file, and delete the same file (using
>>> smbclient).  The uploaded file is owned by smbuser:smbuser, confirming
>>> (to me) that the mapping to guest is functioning correctly.
>>>
>>> However, if I remove the other write permission (i.e., drop
>>> permissions to 0775), I can no longer delete files or write files.  I
>>> get an NT_STATUS_ACCESS_DENIED error.
>>>
>>> I'm a seasoned programmer, and I've actually spent hours tried to
>>> debug this, but I am coming up short.  I can see that the
>>> NT_STATUS_ACCESS_DENIED is coming from se_access_check(), because the
>>> delete bit is not cleared, but I really lack the context to understand
>>> WHY.  I would greatly appreciate your assistance.
>>>
>>> I've run through as simple an interaction as I can think of: using
>>> smbclient to attempt to delete a "deleteme" file.  I set debug logging
>>> to 10 for this example, and collected a client-specific log.  I
>>> believe the key log line may be line 1599:
>>>
>>> [2015/04/26 00:07:17.457393, 10, pid=22294, effective(1001, 1001),
>>> real(1001, 0)] ../source3/smbd/open.c:171(smbd_check_access_rights)
>>>   smbd_check_access_rights: file deleteme requesting 0x10000 returning
>>> 0x10000 (NT_STATUS_ACCESS_DENIED)
>>>
>>> Note that the smbuser UID is 1001, and the smbuser GID is 1001.
>>>
>>> I've uploaded the full log file to http://n01se.net/paste/Kmz for
>>> anyone who would be so kind to offer their expertise.
>>>
>>> Thank you in advance,
>>> Bob
>> Any chance you can post your smb.conf ?
>>
>> Rowland
> Rowland,
>
> Thanks for responding.
>
> I've done my best to strip down my smb.conf, and verify that the problem
> is still reproduced (something I should have done from the start,
> really).  Here's the stripped-down smb.conf:
>
> [global]
>          workgroup = workgroup
>          log file = /var/log/samba/log.%m
>          syslog = 0
>          map to guest = Bad Password
>          guest ok = yes
>          guest account = smbuser
> [Video]
>          path = /data/video
>          public = yes
>          writeable = yes
>          guest ok = yes
>          create mask = 0664
>          directory mask = 6775
>
>
> Thanks again,
> Bob
>

I would have used 'map to guest = Bad User', but I don't think that is 
your problem. You are mapping users that enter a bad password to the 
user 'smbuser'. Now, if the directory or files belong to someone (or 
group) else, the 'other' portion of the permissions come into play. This 
means that when the permissions are changed to '775', the '5' is used, 
this means 'allow smbuser to read & execute the file' smbuser cannot 
write to the file and therefore cannot delete it.

I would suggest that you make your users known to your samba server and 
then set the permissions correctly.

Rowland