[Samba] Cannot delete/write after system update

[Rowland Penny]

On 29/04/15 20:33, Bob Bell wrote:
> On Wed, Apr 29, 2015 at 09:19:32AM +0100, Rowland Penny wrote:
>> 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.
> My goal is to allow for guest access.  This suffices in my home network
> setup.  This is what used to work as "share-level" access control.
>
> I'm aware that the access is being mapped to smbuser.  That's what
> I intend.  The files and directories in question (not all, but these
> specific ones) are owned by the smbuser and the smbuser group.  That's
> all by design, and why I believe that the 775 permissions should be
> sufficient.
>
> -- Bob

Try reading 'man smb.conf' , I gave you a hint, but I will be more 
explicite, change 'map to guest = Bad Password' to 'map to guest = Bad 
User'

'Bad Password' expects the user to exist but the password is wrong, 'Bad 
User' expects neither.

Rowland