Leszek Szczepanowski
2022-Dec-14 11:49 UTC
[Samba] Different "Domain Users" GIDs created by rid backend
Hi,
I was investigating why one user cannot write to the share.
I recognized by using temporary 777 rights on that share, that despite it
coming as exactly the same group as mine that is "Domain Users", the
files
are created with different GID.
drwxrwxrwx+ 2 25360 100513 4096 Dec 14 11:27 FFFF
drwxrwxrwx+ 2 47740 10513 4096 Dec 14 12:22 TEst123
First one is mine
second one is his
[root at fs01 MK]# wbinfo -U 10513
S-1-5-21-725345543-1060284298-1708537768-513
[root at fs01 MK]# wbinfo -U 100513
S-1-5-21-725345543-1060284298-1708537768-513
[root at fs01 MK]# wbinfo -Y
"S-1-5-21-725345543-1060284298-1708537768-513"
100513
[root at fs01 MK]# wbinfo
--lookup-sids="S-1-5-21-725345543-1060284298-1708537768-513"
S-1-5-21-725345543-1060284298-1708537768-513 -> <none>\Domain Users 2
[root at fs01 MK]# wbinfo -n "XXX\domain users"
S-1-5-21-725345543-1060284298-1708537768-513 SID_DOM_GROUP (2)
[root at fs01 MK]# wbinfo -n "domain users"
S-1-5-21-725345543-1060284298-1708537768-513 SID_DOM_GROUP (2)
[root at fs01 MK]# wbinfo -g "Domain Users 2"
[full output of all AD groups]
wbinfo -g "Domain Users gfdsgfdsfdsfdsfdsa"
[same output of all AD groups"
Here smb.conf:
[global]
logging = syslog
clustering = yes
security = ads
realm = XXX.REDKNEE.COM
map acl inherit = yes
workgroup = XXX
kerberos method = secrets and keytab
idmap config * : backend = tdb
ctdb:registry.tdb = yes
netbios name = FS
idmap config XXX: backend = rid
idmap config * : range = 1000-7999
winbind enum users = yes
winbind enum groups = yes
winbind refresh tickets = yes
dedicated keytab file = /etc/krb5.keytab
log level = 3
password server = 172.16.32.5
idmap config XXX: range = 10000-199999
[symptoms]
read only = no
inherit acls = yes
guest ok = no
browseable = yes
path = /mnt/glusterfs/symptoms/
create mask = 0777
force create mode = 0777
directory mask = 0777
force directory mode = 0777
Please note that 777 is temporary, for debugging purposes :)
Please advice why is that?
--
Leszek A. Szczepanowski
twinsen at mspanc.net
Leszek Szczepanowski
2022-Dec-14 12:07 UTC
[Samba] Different "Domain Users" GIDs created by rid backend
Hi, Some more info: [root at fs01 symptoms]# onnode all 'id "XXX\lszczepa"'>> NODE: 10.254.94.11 <<uid=25360(XXX\lszczepa) gid=100513(XXX\domain users) groups=100513(XXX\domain users),25360(XXX\lszczepa) [...]>> NODE: 10.254.94.12 <<uid=25360(XXX\lszczepa) gid=10513(XXX\domain users) groups=10513(XXX\domain users),25360(XXX\lszczepa) [...]>> NODE: 10.254.94.13 <<uid=25360(XXX\lszczepa) gid=10513(XXX\domain users) groups=10513(XXX\domain users),25360(XXX\lszczepa) [...]>> NODE: 10.254.94.14 <<uid=25360(XXX\lszczepa) gid=10513(XXX\domain users) groups=10513(XXX\domain users),25360(XXX\lszczepa) [...]>> NODE: 10.254.94.15 <<uid=25360(XXX\lszczepa) gid=10513(XXX\domain users) groups=10513(XXX\domain users),25360(XXX\lszczepa) [...]>> NODE: 10.254.94.16 <<uid=25360(XXX\lszczepa) gid=10513(XXX\domain users) groups=10513(XXX\domain users),25360(XXX\lszczepa) [...] But why just on one node, there is different mapping, if there is the same smb.conf for all nodes? [global] clustering = yes ctdb:registry.tdb = yes include = registry And the registry 'net conf list' I provided in my previous post. ?r., 14 gru 2022 o 12:49 Leszek Szczepanowski <twinsen at mspanc.net> napisa?(a):> Hi, > > I was investigating why one user cannot write to the share. > I recognized by using temporary 777 rights on that share, that despite it > coming as exactly the same group as mine that is "Domain Users", the files > are created with different GID. > > drwxrwxrwx+ 2 25360 100513 4096 Dec 14 11:27 FFFF > drwxrwxrwx+ 2 47740 10513 4096 Dec 14 12:22 TEst123 > > First one is mine > second one is his > > [root at fs01 MK]# wbinfo -U 10513 > S-1-5-21-725345543-1060284298-1708537768-513 > [root at fs01 MK]# wbinfo -U 100513 > S-1-5-21-725345543-1060284298-1708537768-513 > [root at fs01 MK]# wbinfo -Y "S-1-5-21-725345543-1060284298-1708537768-513" > 100513 > [root at fs01 MK]# wbinfo > --lookup-sids="S-1-5-21-725345543-1060284298-1708537768-513" > S-1-5-21-725345543-1060284298-1708537768-513 -> <none>\Domain Users 2 > [root at fs01 MK]# wbinfo -n "XXX\domain users" > S-1-5-21-725345543-1060284298-1708537768-513 SID_DOM_GROUP (2) > [root at fs01 MK]# wbinfo -n "domain users" > S-1-5-21-725345543-1060284298-1708537768-513 SID_DOM_GROUP (2) > [root at fs01 MK]# wbinfo -g "Domain Users 2" > [full output of all AD groups] > wbinfo -g "Domain Users gfdsgfdsfdsfdsfdsa" > [same output of all AD groups" > > Here smb.conf: > > [global] > logging = syslog > clustering = yes > security = ads > realm = XXX.REDKNEE.COM > map acl inherit = yes > workgroup = XXX > kerberos method = secrets and keytab > idmap config * : backend = tdb > ctdb:registry.tdb = yes > netbios name = FS > idmap config XXX: backend = rid > idmap config * : range = 1000-7999 > winbind enum users = yes > winbind enum groups = yes > winbind refresh tickets = yes > dedicated keytab file = /etc/krb5.keytab > log level = 3 > password server = 172.16.32.5 > idmap config XXX: range = 10000-199999 > > [symptoms] > read only = no > inherit acls = yes > guest ok = no > browseable = yes > path = /mnt/glusterfs/symptoms/ > create mask = 0777 > force create mode = 0777 > directory mask = 0777 > force directory mode = 0777 > > Please note that 777 is temporary, for debugging purposes :) > > Please advice why is that? > -- > Leszek A. Szczepanowski > twinsen at mspanc.net >-- -- Leszek A. Szczepanowski twinsen at mspanc.net
Rowland Penny
2022-Dec-14 12:14 UTC
[Samba] Different "Domain Users" GIDs created by rid backend
On 14/12/2022 11:49, Leszek Szczepanowski via samba wrote:> Hi, > > I was investigating why one user cannot write to the share. > I recognized by using temporary 777 rights on that share, that despite it > coming as exactly the same group as mine that is "Domain Users", the files > are created with different GID. > > drwxrwxrwx+ 2 25360 100513 4096 Dec 14 11:27 FFFF > drwxrwxrwx+ 2 47740 10513 4096 Dec 14 12:22 TEst123I would have thought this was impossible using the 'rid' idmap backend, untill I saw that this was a CTDB cluster. Are you using the exact same smb.conf on all the cluster members, or is it possible that you are using 'rid' on this machine and 'ad' on others ? The 'rid' idmap backend calculates the ID from this formula: ID = low range + RID So in your case: ID = 10000 + 513 Which becomes: 10513 = 100000 + 513 I suggest you run 'net cache flush' and try again (after ensuring that all the smb.conf files match). Rowland