[Samba] permission denied with windows acls

[Peter Carlson]

On 1/29/24 12:33, Rowland Penny via samba wrote:
> On Mon, 29 Jan 2024 09:27:58 -0800
> Peter Carlson via samba<samba at lists.samba.org>  wrote:
>
>> On 1/29/24 08:17, Rowland Penny via samba wrote:
>>> On Mon, 29 Jan 2024 07:55:05 -0800
>>> Peter Carlson via samba<samba at lists.samba.org>   wrote:
>>>
>>>> Just to make sure this morning, I created another VM and it behaves
>>>> the same, so obviously we have something slightly different in our
>>>> configs. I think we have gone through the client side pretty
>>>> thoroughly and they are the same.  That leaves:
>>>>
>>>>     * our security settings on the share -  but you said that your
>>>> machine isn't in domain users and domain computers doesn't have
>>>> access to the share.  What else there to test here?
>>>>     * file server samba settings
>>>>     * possibly version differences
>>>>         o Client: Version 4.15.13-Ubuntu
>>>>         o File Server: Version 4.19.0pre1-GIT-1e793357906
>>>>         o Domain Controller: Version 4.18.0pre1-GIT-d385058ce7c
>>>>         o I was doing some work on generic user level linux GPOs
>>>> which is why the DC and FS are running from source
>>>>     * or even at the DC.?
>>>>
>>>> What's the easiest way to proceed?  I can post pretty much any
>>>> config needed.
>>>>
>>> The share I am mounting is a simple share on a Unix domain member
>>> using the 'rid' backend (as is the client), these are the
>>> permissions on the share:
>>>
>>> ls -lad /srv/share
>>> drwxrwx--- 3 rowland domain users 4096 Jan 28 21:48 /srv/share
>>>
>>> The share in smb.conf is this:
>>>
>>> [data]
>>>       path=/srv/share
>>>       read only = no
>>>
>>> With that, I can start my VM and find the share in /mnt/test
>>>
>>> I think my next step will have to be to set up a new share on the
>>> server, but this time set the permissions from Windows and see if
>>> that mounts on the Unix client. But it will have to be tomorrow now.
>>>
>>> Rowland
>>>
>> No worries on the timeline, I appreciate the help!
> OK, I thought I had to go and do something, but it got cancelled.
> So I set up yet another couple of shares, one using windows permissions
> like yours, the other giving Domain Users full control, they both mount
> and work.
>
>> here is my windows share permissions:
>> https://pasteboard.co/m6j9vYkRkt3q.png
>>
>> here is my share config:
>>
>> root at fs1:~# ls -lad /data/test
>> drwxrwx--T+ 4 root CARLSON\domain admins 4096 Jan 26 16:13 /data/test
>             ^
>             |----- Where does the big T' come from, I do not get that.
> It is my understanding that it shows the sticky bit is set on 'others',
> but there is no 'x' set.

Just did a quick test, the big T comes after setting permissions in windows

root at fs1:/var/log# cd /data
root at fs1:/data# mkdir -m 1777 test2
root at fs1:/data# chown root:"CARLSON\\domain admins" test2
root at fs1:/data# vi /etc/samba/smb.conf
root at fs1:/data# systemctl restart smbd.service
root at fs1:/data# ls -ald /data/*
drwxrwx--T+ 4 root CARLSON\domain admins 4096 Jan 26 16:13 /data/test
drwxrwxrwt  2 root CARLSON\domain admins 4096 Jan 29 20:43 /data/test2
-------------------------
set permissions in window
-------------------------
root at fs1:/data# ls -ald /data/*
drwxrwx--T+ 4 root CARLSON\domain admins 4096 Jan 26 16:13 /data/test
drwxrwx--T+ 2 root CARLSON\domain admins 4096 Jan 29 20:43 /data/test2

>>
>> [global]
>> server string = %h server (Samba, Ubuntu)
>>      log file = /var/log/samba/log.%m
>>      max log size = 1000
>>      logging = file
>>      panic action = /usr/share/samba/panic-action %d
>> log level = 3
>>
>> kerberos method = secrets and keytab
>> realm = CARLSON.LAB
>> workgroup = CARLSON
>> template homedir = /home/%U@%D
>> template shell = /bin/bash
>> security = ads
>> idmap config CARLSON : range = 2000000-2999999
>> idmap config CARLSON : backend = rid
>> idmap config * : range = 10000-999999
>> idmap config * : backend = tdb
>>
>> vfs objects = acl_xattr
>> map acl inherit = yes
>>
>> winbind use default domain = no
>> winbind refresh tickets = yes
>> winbind offline logon = yes
>> winbind enum groups = no
>> winbind enum users = no
>>
>> apply group policies = yes
>>
>> #======================= Share Definitions =======================
>> [Test]
>>       path = /data/test
>>       comment = test
>>       writable = yes
>>
>>
> There are some differences between my smb.conf and yours, but nothing
> major except that I have:
>
> dedicated keytab file = /etc/krb5.keytab
>
> I am not sure if that has any bearing.
>
> Rowland
>
I can test the dedicated keyring in a bit and report back.