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