gid numbers changed after upgrading from 4.1.14 to 4.2.1
d.dario76 at gmail.com
Thu Apr 23 05:03:42 MDT 2015
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
> 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.
> > 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
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
cn: Ufficio Tecnico
description: Personale Ufficio Tecnico
name: Ufficio Tecnico
sAMAccountName: Ufficio Tecnico
# returned 4 records
# 1 entries
# 3 referrals
So "Ufficio Tecnico" has gid 4000113 and sid
wbinfo -G 4000113
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
wbinfo -G 3000022
lbdsearch -H sam.ldb -a
# record 1
operatingSystem: Windows XP Professional
operatingSystemVersion: 5.1 (2600)
operatingSystemServicePack: Service Pack 3
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?
More information about the samba-technical