[Samba] Cannot delete/write after system update

[Bob Bell]

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