On 2021-01-31 11:18 am, Rowland penny via samba wrote:> On 31/01/2021 16:05, Marco Shmerykowsky via samba wrote: >> On 2021-01-31 10:41 am, Marco Shmerykowsky via samba wrote: >>> On 2021-01-31 10:15 am, Rowland penny via samba wrote: >>>> On 31/01/2021 14:42, Marco Shmerykowsky via samba wrote: >>>>> >>>>> I found the errors in the smbd log file on the domain member >>>>> server that contains the file shares.? I have group policies >>>>> for the desktop background and drives shares.? The policies >>>>> seem to be applied since the drive maps show up and I do >>>>> not see any errors when I run gpresult. >>>>> >>>>> The background doesn't show up because the image file is >>>>> stored in one of the drive shares.? Trying to access the >>>>> drive shares results in an error under windows that I do >>>>> not have permission to access the share. >>>>> >>>>>> >>>>>> Is there anything surrounding it (paths etc) >>>>> >>>>> The full line in the log is as follows: >>>>> >>>>> ? chdir_current_service: >>>>> vfs_ChDir(/path/to/domain-member-server/share) failed: Permission >>>>> denied. Current token: uid=11105, gid=10513, 13 groups: 11105 10513 >>>>> 11119 11118 11120 11121 11122 11135 11138 2004 2005 2007 2002 >>>>> >>>>> >>>>> Domain Member server.? It seemed to be working fine until the >>>>> DNS changes. >>>>> >>>>> permissions via getfacl: >>>>> >>>>> # file: path/to/domain-member-server/share >>>>> # owner: root >>>>> # group: domain\040admins >>>>> user::rwx >>>>> user:root:rwx >>>>> group::rwx >>>>> group:domain\040admins:rwx >>>>> group:owners:rwx >>>>> mask::rwx >>>>> other::--- >>>>> default:user::rwx >>>>> default:user:root:rwx >>>>> default:group::r-x >>>>> default:group:domain\040admins:r-x >>>>> default:group:owners:rwx >>>>> default:mask::rwx >>>>> default:other::--- >>>>> >>>>> Permissions via ls -la: >>>>> >>>>> drwxrwx---+? 14 root domain admins? 4096 Jan 25 16:12 share >>>> >>>> >>>> From the data supplied, only root and members of the groups 'Domain >>>> Admins & owners' can enter the share. You are connecting as a user >>>> with the ID 11105 and primary group Domain Users, but does the group >>>> 'owners' have one of these GID's '11119 11118 11120 11121 11122 >>>> 11135 >>>> 11138' >>> >>> I believe the answer is 'yes.'? Under windows, the user attempting to >>> log in is a member of the group 'owners' >>> >>> running 'wbinfo --name-to-sid user' returns: >>> >>> S-1-5-21-816939725-271653577-1537739732-1105 SID_USER (1) >>> ??????????????????????????????????????? ^^^^ >>> >>> running 'wbinfo --name-to-sid group' returns: >>> >>> S-1-5-21-816939725-271653577-1537739732-1118 SID_DOM_GROUP (2) >>> ??????????????????????????????????????? ^^^^ >> >> Correction, the gid seems to be off by 10000. >> > > Yes and no ? > > What you were pointing to, was the RID and you are using the winbind > rid backend, which means the groups GID is calculated from this > formula: > > ID = RID + LOW_RANGE_ID > > Which becomes for you: > > 11105 = 1105 + 10000Ah... Learning, learning, learning> > Does 'getent group owners' produce '11105' as the first number in the > output ? > > If it doesn't, what is the groupname produced by 'getent group 11105' ?'getent group owners' returns: AD-DOMAIN\owners:x:3000025:
On 31/01/2021 16:23, Marco Shmerykowsky via samba wrote:> > On 2021-01-31 11:18 am, Rowland penny via samba wrote: >> On 31/01/2021 16:05, Marco Shmerykowsky via samba wrote: >>> On 2021-01-31 10:41 am, Marco Shmerykowsky via samba wrote: >>>> On 2021-01-31 10:15 am, Rowland penny via samba wrote: >>>>> On 31/01/2021 14:42, Marco Shmerykowsky via samba wrote: >>>>>> >>>>>> I found the errors in the smbd log file on the domain member >>>>>> server that contains the file shares.? I have group policies >>>>>> for the desktop background and drives shares.? The policies >>>>>> seem to be applied since the drive maps show up and I do >>>>>> not see any errors when I run gpresult. >>>>>> >>>>>> The background doesn't show up because the image file is >>>>>> stored in one of the drive shares.? Trying to access the >>>>>> drive shares results in an error under windows that I do >>>>>> not have permission to access the share. >>>>>> >>>>>>> >>>>>>> Is there anything surrounding it (paths etc) >>>>>> >>>>>> The full line in the log is as follows: >>>>>> >>>>>> ? chdir_current_service: >>>>>> vfs_ChDir(/path/to/domain-member-server/share) failed: Permission >>>>>> denied. Current token: uid=11105, gid=10513, 13 groups: 11105 >>>>>> 10513 11119 11118 11120 11121 11122 11135 11138 2004 2005 2007 2002 >>>>>> >>>>>> >>>>>> Domain Member server.? It seemed to be working fine until the >>>>>> DNS changes. >>>>>> >>>>>> permissions via getfacl: >>>>>> >>>>>> # file: path/to/domain-member-server/share >>>>>> # owner: root >>>>>> # group: domain\040admins >>>>>> user::rwx >>>>>> user:root:rwx >>>>>> group::rwx >>>>>> group:domain\040admins:rwx >>>>>> group:owners:rwx >>>>>> mask::rwx >>>>>> other::--- >>>>>> default:user::rwx >>>>>> default:user:root:rwx >>>>>> default:group::r-x >>>>>> default:group:domain\040admins:r-x >>>>>> default:group:owners:rwx >>>>>> default:mask::rwx >>>>>> default:other::--- >>>>>> >>>>>> Permissions via ls -la: >>>>>> >>>>>> drwxrwx---+? 14 root domain admins? 4096 Jan 25 16:12 share >>>>> >>>>> >>>>> From the data supplied, only root and members of the groups 'Domain >>>>> Admins & owners' can enter the share. You are connecting as a user >>>>> with the ID 11105 and primary group Domain Users, but does the group >>>>> 'owners' have one of these GID's '11119 11118 11120 11121 11122 11135 >>>>> 11138' >>>> >>>> I believe the answer is 'yes.'? Under windows, the user attempting to >>>> log in is a member of the group 'owners' >>>> >>>> running 'wbinfo --name-to-sid user' returns: >>>> >>>> S-1-5-21-816939725-271653577-1537739732-1105 SID_USER (1) >>>> ??????????????????????????????????????? ^^^^ >>>> >>>> running 'wbinfo --name-to-sid group' returns: >>>> >>>> S-1-5-21-816939725-271653577-1537739732-1118 SID_DOM_GROUP (2) >>>> ??????????????????????????????????????? ^^^^ >>> >>> Correction, the gid seems to be off by 10000. >>> >> >> Yes and no ? >> >> What you were pointing to, was the RID and you are using the winbind >> rid backend, which means the groups GID is calculated from this >> formula: >> >> ID = RID + LOW_RANGE_ID >> >> Which becomes for you: >> >> 11105 = 1105 + 10000 > > Ah... Learning, learning, learning > >> >> Does 'getent group owners' produce '11105' as the first number in the >> output ? >> >> If it doesn't, what is the groupname produced by 'getent group 11105' ? > > 'getent group owners' returns: > > AD-DOMAIN\owners:x:3000025: > >That, unless something has gone extremely wrong, is on a DC. A DC uses idmap.ldb and all the xidNumber attributes on a DC are in the '3000000' range, at least it proves that 'owners' is a domain group ? What do you get on a Unix domain member ? Rowland
On 2021-01-31 11:23 am, Marco Shmerykowsky via samba wrote:> On 2021-01-31 11:18 am, Rowland penny via samba wrote: >> On 31/01/2021 16:05, Marco Shmerykowsky via samba wrote: >>> On 2021-01-31 10:41 am, Marco Shmerykowsky via samba wrote: >>>> On 2021-01-31 10:15 am, Rowland penny via samba wrote: >>>>> On 31/01/2021 14:42, Marco Shmerykowsky via samba wrote: >>>>>> >>>>>> I found the errors in the smbd log file on the domain member >>>>>> server that contains the file shares.? I have group policies >>>>>> for the desktop background and drives shares.? The policies >>>>>> seem to be applied since the drive maps show up and I do >>>>>> not see any errors when I run gpresult. >>>>>> >>>>>> The background doesn't show up because the image file is >>>>>> stored in one of the drive shares.? Trying to access the >>>>>> drive shares results in an error under windows that I do >>>>>> not have permission to access the share. >>>>>> >>>>>>> >>>>>>> Is there anything surrounding it (paths etc) >>>>>> >>>>>> The full line in the log is as follows: >>>>>> >>>>>> ? chdir_current_service: >>>>>> vfs_ChDir(/path/to/domain-member-server/share) failed: Permission >>>>>> denied. Current token: uid=11105, gid=10513, 13 groups: 11105 >>>>>> 10513 11119 11118 11120 11121 11122 11135 11138 2004 2005 2007 >>>>>> 2002 >>>>>> >>>>>> >>>>>> Domain Member server.? It seemed to be working fine until the >>>>>> DNS changes. >>>>>> >>>>>> permissions via getfacl: >>>>>> >>>>>> # file: path/to/domain-member-server/share >>>>>> # owner: root >>>>>> # group: domain\040admins >>>>>> user::rwx >>>>>> user:root:rwx >>>>>> group::rwx >>>>>> group:domain\040admins:rwx >>>>>> group:owners:rwx >>>>>> mask::rwx >>>>>> other::--- >>>>>> default:user::rwx >>>>>> default:user:root:rwx >>>>>> default:group::r-x >>>>>> default:group:domain\040admins:r-x >>>>>> default:group:owners:rwx >>>>>> default:mask::rwx >>>>>> default:other::--- >>>>>> >>>>>> Permissions via ls -la: >>>>>> >>>>>> drwxrwx---+? 14 root domain admins? 4096 Jan 25 16:12 share >>>>> >>>>> >>>>> From the data supplied, only root and members of the groups 'Domain >>>>> Admins & owners' can enter the share. You are connecting as a user >>>>> with the ID 11105 and primary group Domain Users, but does the >>>>> group >>>>> 'owners' have one of these GID's '11119 11118 11120 11121 11122 >>>>> 11135 >>>>> 11138' >>>> >>>> I believe the answer is 'yes.'? Under windows, the user attempting >>>> to >>>> log in is a member of the group 'owners' >>>> >>>> running 'wbinfo --name-to-sid user' returns: >>>> >>>> S-1-5-21-816939725-271653577-1537739732-1105 SID_USER (1) >>>> ??????????????????????????????????????? ^^^^ >>>> >>>> running 'wbinfo --name-to-sid group' returns: >>>> >>>> S-1-5-21-816939725-271653577-1537739732-1118 SID_DOM_GROUP (2) >>>> ??????????????????????????????????????? ^^^^ >>> >>> Correction, the gid seems to be off by 10000. >>> >> >> Yes and no ? >> >> What you were pointing to, was the RID and you are using the winbind >> rid backend, which means the groups GID is calculated from this >> formula: >> >> ID = RID + LOW_RANGE_ID >> >> Which becomes for you: >> >> 11105 = 1105 + 10000 > > Ah... Learning, learning, learning > >> >> Does 'getent group owners' produce '11105' as the first number in the >> output ? >> >> If it doesn't, what is the groupname produced by 'getent group 11105' >> ? > > 'getent group owners' returns: > > AD-DOMAIN\owners:x:3000025:I think I know how I created this problem. about a week ago when upgrading from samba-4.9-Stretch to samba-4.13-buster I caught an error in the smb.conf that was in there since I set things up The line 'idmap config AD-DOMAIN : range = 10000-999999' had a typo in the word "config" I believe. For some reason, everything continued to work after the correction and then fell apart after I corrected the dns issues (i hope) How do I fix my error, if that is indeed the issue? Thank you.