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 ? > > RowlandRowland, 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
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
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