samba - Sep 2020 - cifsacl not working

On 9/24/20 8:53 AM, Aur?lien Aptel wrote:
> Ken Bass via samba <samba at lists.samba.org> writes:
>> I installed a new Ubuntu 20.4 LTS system (smbd 4.11.6) . Initially I
>> tried using the SSSD and 'realm' to join the domain. Everything
worked
>> similar to my Centos 7 install and I thought I was finished.
>>
>> The one thing not working is? cifs shares showing the proper id
mapping.
>> Based on some online posts, including from Rowland, I got rid of SSSD
>> and configured samba/winbind only. Lots of posts saying 'winbind is
not
>> sssd'. Still doesn't work.
> Do you have /etc/request-keys.conf setup to call cifs.idmap?
Hi Aur?lien,

I don't have a? /etc/request-keys.conf, but there is a 
/etc/request-key.d directory with a? cifs.idmap.conf file. It contains:

create? cifs.idmap??? * * /usr/sbin/cifs.idmap %k

However I don't know if it is being used. For example, I temporarily 
renamed the above cifs.idmap to cifs.idmap.DISABLED and saw no 
difference. (I restarted smbd, winbind, and ran net cache flush).
Since mount.cifs man page says
' If either upcall to cifs.idmap is not setup correctly or winbind is 
not configured and running, ID mapping will? fail.
 ???????? In? that case uid and gid will default to either to those 
values of the share or to the values of uid and/or gid mount
 ???????? options if specified.'

So I am not sure how much my troubleshooting step tells me.

My smb.conf is:

testparm -s
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER

# Global parameters
[global]
 ??? dedicated keytab file = /etc/krb5.keytab
 ??? disable spoolss = Yes
 ??? interfaces = lo 192.168.2.0/24
 ??? kerberos method = secrets and keytab
 ??? load printers = No
 ??? log file = /var/log/samba/%m.log
 ??? printcap name = /dev/null
 ??? realm = MYDOM.XYZ.NET
 ??? security = ADS
 ??? server string = xyz
 ??? template homedir = /home/%U
 ??? template shell = /bin/bash
 ??? username map = /etc/samba/user.map
 ??? winbind enum groups = Yes
 ??? winbind enum users = Yes
 ??? winbind refresh tickets = Yes
 ??? winbind use default domain = Yes
 ??? workgroup = MYDOM
 ??? idmap config mydom : unix_primary_group = yes
 ??? idmap config mydom : range = 1000-29999
 ??? idmap config mydom : schema_mode = rfc2307
 ??? idmap config mydom : backend = ad
 ??? idmap config * : range = 30000-39999
 ??? idmap config * : backend = tdb
 ??? cups options = raw
 ??? hosts allow = 127. 192.168.2.
 ??? map acl inherit = Yes
 ??? printing = bsd
 ??? vfs objects = acl_xattr

The request-keys config looks right.

You can check if winbind is properly configured trying to map with the
winbind CLI client called wbinfo. For example:

# wbinfo -i NUC\\administrator
NUC\administrator:*:20501:20514::/home/NUC/administrator:/bin/bash 
                    ^^^^^ ^^^^^
                     uid   gid

Cheers,
-- 
Aur?lien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 N?rnberg, DE
GF: Felix Imend?rffer, Mary Higgins, Sri Rasiah HRB 247165 (AG M?nchen)

On 9/24/20 11:51 AM, Aur?lien Aptel wrote:
> The request-keys config looks right.
>
> You can check if winbind is properly configured trying to map with the
> winbind CLI client called wbinfo. For example:
>
> # wbinfo -i NUC\\administrator
> NUC\administrator:*:20501:20514::/home/NUC/administrator:/bin/bash
>                      ^^^^^ ^^^^^
>                       uid   gid
>
> Cheers,
# wbinfo -i MYDOM\\user
user:*:1001:1001::/home/user:/bin/bash

Those uid/gid are correct. They match the server and also match the 
uid/gid in the AD for the user.
It seems everything is working except for the cifsacl id mapping part.