gid numbers changed after upgrading from 4.1.14 to 4.2.1 SOLVED

Daniele Dario d.dario76 at gmail.com
Thu Apr 23 10:51:50 MDT 2015


I'll do it tomorrow morning, or at least I'll try; -).

Again thank.
On Apr 23, 2015 6:50 PM, "Rowland Penny" <repenny241155 at gmail.com> wrote:

> On 23/04/15 17:38, Daniele Dario wrote:
>
>>
>> On gio, 2015-04-23 at 17:05 +0100, Rowland Penny wrote:
>>
>>> On 23/04/15 16:43, Daniele Dario wrote:
>>>
>>>> On gio, 2015-04-23 at 13:03 +0200, Daniele Dario wrote:
>>>>
>>>>> On mer, 2015-04-22 at 13:42 +0100, Rowland Penny wrote:
>>>>>
>>>>>> On 22/04/15 13:20, Daniele Dario wrote:
>>>>>>
>>>>>>> On mer, 2015-04-22 at 12:34 +0100, Rowland Penny wrote:
>>>>>>>
>>>>>>>> On 22/04/15 12:12, Daniele Dario wrote:
>>>>>>>>
>>>>>>>>> About the libnss_winbind links, kdc01 is a VM with ubuntu 10.04
>>>>>>>>> 32bit so
>>>>>>>>> I have
>>>>>>>>>
>>>>>>>>> [root at kdc01:~]# ll /lib/i386-linux-gnu/libnss_winbind.so*
>>>>>>>>> lrwxrwxrwx 1 root root 38 2014-12-11
>>>>>>>>> 18:03 /lib/i386-linux-gnu/libnss_winbind.so
>>>>>>>>> -> /usr/local/samba/lib/libnss_winbind.so*
>>>>>>>>> lrwxrwxrwx 1 root root 40 2014-12-11
>>>>>>>>> 18:03 /lib/i386-linux-gnu/libnss_winbind.so.2
>>>>>>>>> -> /usr/local/samba/lib/libnss_winbind.so.2*
>>>>>>>>>
>>>>>>>> This is what I would expect on a DC where samba4 was self compiled,
>>>>>>>> the
>>>>>>>> references to libnss_winbind in /lib/i386-linux-gnu are symbolic
>>>>>>>> links
>>>>>>>> to the actual files in /usr/local/samba/lib
>>>>>>>>
>>>>>>>>  kdc03 is a real machine 64bit with ubuntu 12.04
>>>>>>>>>
>>>>>>>>> [root at kdc03:/usr/local/samba/private]#
>>>>>>>>> ll /lib/x86_64-linux-gnu/libnss_winbind.so*
>>>>>>>>> lrwxrwxrwx 1 root root 19 May 19
>>>>>>>>> 2014 /lib/x86_64-linux-gnu/libnss_winbind.so ->
>>>>>>>>> libnss_winbind.so.2*
>>>>>>>>> lrwxrwxrwx 1 root root 24 May 12
>>>>>>>>> 2014 /lib/x86_64-linux-gnu/libnss_winbind.so.2
>>>>>>>>> -> /lib64/libnss_winbind.so*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  And here, the first one appears to be a symbolic link to the
>>>>>>>> second,
>>>>>>>> which appears to be another symbolic link to a file that appears to
>>>>>>>> have
>>>>>>>> nothing to do with the files you compiled in /usr/local/samba.
>>>>>>>>
>>>>>>>> Could these be the remains of the previous samba install ?
>>>>>>>> Try renaming them and then create the symbolic links as per the VM,
>>>>>>>> see
>>>>>>>> here for more info:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://wiki.samba.org/index.php/Setup_a_Samba_AD_Member_Server#Make_domain_users.2Fgroups_available_locally_through_Winbind
>>>>>>>>
>>>>>>>> Rowland
>>>>>>>>
>>>>>>> No, I just created them before the wiki reported that on Debian like
>>>>>>> distros, it was expected to have the links in /lib64, in /usr/lib
>>>>>>> and/or
>>>>>>> in /usr/lib/x86_64-linux-gnu. I found that the application that was
>>>>>>> failing was looking for the lib in /lib/x86... so instead of creating
>>>>>>> the links to /usr/local/samba/lib/... that time I used as source the
>>>>>>> link in /lib64 which was already a link to the correct lib. BTW now I
>>>>>>> fixed the names but that didn't change anything.
>>>>>>>
>>>>>> The problem is that the links need to go in different places based on
>>>>>> what OS & versions you have, for instance I am typing this on a Linux
>>>>>> Mint 17 laptop and this is where the links are:
>>>>>>
>>>>>> rowland at ThinkPad ~ $ locate libnss_winbind
>>>>>> /lib/x86_64-linux-gnu/libnss_winbind.so
>>>>>> /lib/x86_64-linux-gnu/libnss_winbind.so.2
>>>>>>
>>>>>> This is the same  on my Debian 7 backports DC
>>>>>>
>>>>>> The reference to /lib64 is meant for a RHEL based machine, so it is
>>>>>> possible that you need to remake the links as above.
>>>>>>
>>>>>> Rowland
>>>>>>
>>>>>>
>>>>>>  I'm stuck now and really don't know how to go on.
>>>>>>> A brutal force action like removing the group and creating it again
>>>>>>> seems a way but that means to change the ACLs on the root of the
>>>>>>> shares
>>>>>>> and it takes long so I really hope there's another solution.
>>>>>>>
>>>>>>> Daniele.
>>>>>>>
>>>>>>>  Hi samba-team, everybody
>>>>> I'm still trying to understand why I'm getting the strange behavior
>>>>> above.
>>>>>
>>>>> This morning I tried to stop the DC and remove everything from the
>>>>> samba/private folder than re-join it to the domain.
>>>>> Before join I just made a copy of idmap.ldb from the working DC to the
>>>>> one to join.
>>>>> Join went well, replication started and seems ok because an ldapcmp
>>>>> says
>>>>> everything is good but:
>>>>>
>>>>> ldbsearch -H sam.ldb -a name="Ufficio\ Tecnico"
>>>>> # record 1
>>>>> dn: CN=Ufficio Tecnico,OU=groups,OU=saitel,DC=saitel,DC=loc
>>>>> objectClass: top
>>>>> objectClass: group
>>>>> cn: Ufficio Tecnico
>>>>> description: Personale Ufficio Tecnico
>>>>> instanceType: 4
>>>>> whenCreated: 20120924144535.0Z
>>>>> uSNCreated: 3763
>>>>> name: Ufficio Tecnico
>>>>> objectGUID: 2e58f8d0-5a28-47c1-9468-ec7b202cf560
>>>>> objectSid: S-1-5-21-1132727046-140625262-2935381992-1105
>>>>> sAMAccountName: Ufficio Tecnico
>>>>> sAMAccountType: 268435456
>>>>> groupType: -2147483646
>>>>> objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=saitel,DC=loc
>>>>> gidNumber: 4000113
>>>>> whenChanged: 20150423072617.0Z
>>>>> member: ...
>>>>> uSNChanged: 5367
>>>>> distinguishedName: CN=Ufficio
>>>>> Tecnico,OU=groups,OU=saitel,DC=saitel,DC=loc
>>>>>
>>>>> # Referral
>>>>> ref: ldap://saitel.loc/CN=Configuration,DC=saitel,DC=loc
>>>>>
>>>>> # Referral
>>>>> ref: ldap://saitel.loc/DC=DomainDnsZones,DC=saitel,DC=loc
>>>>>
>>>>> # Referral
>>>>> ref: ldap://saitel.loc/DC=ForestDnsZones,DC=saitel,DC=loc
>>>>>
>>>>> # returned 4 records
>>>>> # 1 entries
>>>>> # 3 referrals
>>>>>
>>>>> So "Ufficio Tecnico" has gid 4000113 and sid
>>>>> S-1-5-21-1132727046-140625262-2935381992-1105
>>>>>
>>>>> wbinfo -G 4000113
>>>>> S-1-5-21-1132727046-140625262-2935381992-1105
>>>>>
>>>>> wbinfo -s S-1-5-21-1132727046-140625262-2935381992-1105
>>>>> SAITEL\Ufficio Tecnico 2
>>>>>
>>>>> is correct but trying to get the reverse lookup
>>>>>
>>>>> wbinfo --group-info Ufficio\ Tecnico
>>>>> ufficio tecnico:x:3000022:
>>>>>
>>>>> and
>>>>>
>>>>> wbinfo -G 3000022
>>>>> S-1-5-21-1132727046-140625262-2935381992-1129
>>>>>
>>>>> lbdsearch -H sam.ldb -a
>>>>> objectSid=S-1-5-21-1132727046-140625262-2935381992-1129
>>>>> # record 1
>>>>> dn: CN=UA01,OU=Computers,OU=saitel,DC=saitel,DC=loc
>>>>> objectClass: top
>>>>> objectClass: person
>>>>> objectClass: organizationalPerson
>>>>> objectClass: user
>>>>> objectClass: computer
>>>>> cn: UA01
>>>>> instanceType: 4
>>>>> whenCreated: 20120925094429.0Z
>>>>> whenChanged: 20150223125833.0Z
>>>>> displayName: UA01$
>>>>> uSNCreated: 3747
>>>>> uSNChanged: 3747
>>>>> name: UA01
>>>>> objectGUID: ddbc89cb-68a2-492a-a7f9-6d2c38ebe5ac
>>>>> userAccountControl: 4096
>>>>> codePage: 0
>>>>> countryCode: 0
>>>>> pwdLastSet: 130691699130000000
>>>>> primaryGroupID: 515
>>>>> objectSid: S-1-5-21-1132727046-140625262-2935381992-1129
>>>>> accountExpires: 9223372036854775807
>>>>> sAMAccountName: UA01$
>>>>> sAMAccountType: 805306369
>>>>> operatingSystem: Windows XP Professional
>>>>> operatingSystemVersion: 5.1 (2600)
>>>>> operatingSystemServicePack: Service Pack 3
>>>>> dNSHostName: ua01.saitel.loc
>>>>> servicePrincipalName: HOST/ua01.saitel.loc
>>>>> servicePrincipalName: HOST/UA01
>>>>> objectCategory: CN=Computer,CN=Schema,CN=Configuration,DC=saitel,DC=loc
>>>>> isCriticalSystemObject: FALSE
>>>>> distinguishedName: CN=UA01,OU=Computers,OU=saitel,DC=saitel,DC=loc
>>>>>
>>>>> This is consistent with the other DC but I can't understand why on this
>>>>> DC there is a swap between two sids. The result is that I cannot
>>>>> anymore
>>>>> use the shares owned by the group "Ufficio Tecnico" because trying to
>>>>> connect to the shares all people gets permission deny.
>>>>>
>>>>> Can anybody help me please?
>>>>>
>>>> Sorry for the noise, I know you guys are hardworking on many tasks but I
>>>> really need to understand what's happening or how to fix this problem.
>>>> In Italian ufficio tecnico means R&D and I'm having problems with the
>>>> network share where all R&D stuff is so ... please help!!!
>>>>
>>>> Daniele.
>>>>
>>>>  OK, somebody over on the samba mailing list is having what seems to be
>>> a
>>> similar problem with 4.2.1
>>>
>>> Are you using the internal dns or bind 9 ?
>>> If bind9, find the 'server services' line in smb.conf, change 'winbindd'
>>> to 'winbind', do this on both machines and then restart samba
>>> If using the internal dns, you probably don't have the 'server services'
>>> line, so you will have to add it in this format 'server services
>>> -winbindd +winbind' , again restart samba.
>>>
>>> Try 'getent group Ufficio\ Tecnico' on both machines and see if this
>>> cures your problem, you may have to run 'net cache flush' to clear out
>>> the winbind cache.
>>>
>>> Rowland
>>>
>> Great Rowland.
>>
>> I'm using internal dns on both DCs so I added
>>
>> ...
>> server services = -winbindd + winbind
>> ...
>>
>> started samba again and everything went fine.
>>
>> I remember that I saw that statement in the wiki but didn't get that it
>> was a must and not a suggest because it stated something like "if you
>> need to use winbind add the line ...". I can't find the page right now
>> but I'm pretty sure I read it.
>>
>> Just a side note, today I set up an old machine with 4.2.1 on Ubuntu
>> 12.04 32 bit server and joined as DC (two is better than one). Same
>> smb.conf of the other 2, but here the problem did not appear.
>>
>> Anyway, MILLION THANKS Rowland.
>>
>>
> OK, you have now confirmed there is bug, could you please go and file a
> bug report on it.
>
> Rowland
>


More information about the samba-technical mailing list