samba - Nov 2022 - accidentally upgraded DC to 4.17.3 ... didn't work

Am 29.11.22 um 18:34 schrieb Michael Tokarev:
> 25.11.2022 18:38, Stefan Weichinger via samba wrote:
>> I am wondering why noone replies here.
>> Do I miss some FAQ topic maybe?
> 
> It looks like no one knows what the problem is
> and from which side to come to it - that's why.
> 
> A freshly built DC which has been successfully joined,
> should not have problems with replication.
> 
> To be fair, myself, I completely lost track of what problem
> do you have - was it a replication problem, or some timeout
> when accessing sysvol, or something else entirely.? Either
> way, I've no idea how you're able to manage to install a
> non-working DC.
> 
> Again, I, for one, haven't seen this happen here (yet), -
> my installs were unsuccessful at times, but this is always
> due to one or another obvious reason, for example some
> stale data somewhere in /var/lib/samba/ which I forgot
> to remove before a (re)join (or - the one which Rownald
> likes very much - forgot to update DNS adding the newly
> joined DC :) ).? So I don't have much experience in this
> area - dealing with a failing DC.
> 
>> As I read it in that other thread: maybe I have to copy that idmap ... 
>> ? Because basically that readded DC is a new DC ? If that's needed,
>> why it isn't mentioned in the wiki article?
> 
> /var/lib/samba/private/idmap.tdb needs to be transferred
> together with the sysvol replication. It *is* mentioned
> in the wiki.? But this will not cause a timeout when
> accessing this DC, - it will return something like EACCESS
> (permission denied) right away, - the result, eg, a win10
> client just isn't applying GPOs, that's all.
Michael, thanks for the reply.

The state: the replication seems to work, but winbind doesn't work 
correctly (afaik) on that adc1.

So shares like SYSVOL aren't accessible.

It seems I can only retry demoting, cleaning up and join again, plus 
transfer that idmap.tdb.

Packages are up to date, I *should* have all necessary packages installed.

Am 30.11.22 um 09:05 schrieb Stefan G. Weichinger via samba:
> The state: the replication seems to work, but winbind doesn't work 
> correctly (afaik) on that adc1.
> 
> So shares like SYSVOL aren't accessible.
> 
> It seems I can only retry demoting, cleaning up and join again, plus 
> transfer that idmap.tdb.
> 
> Packages are up to date, I *should* have all necessary packages installed.
So I repeated:

* demote adc1

* clear /var/lib/samba, smb.conf, /run/samba, /var/cache/samba, 
/var/log/samba (is that dir important? anyway)

* join successfully

* cp idmap.ldb (yes, in the wiki at 
https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_Existing_Active_Directory#Joining_the_Active_Directory_as_a_Domain_Controller,
but not mentioned in 
https://wiki.samba.org/index.php/Upgrading_a_Samba_AD_DC#Updating_Multiple_Samba_Domain_Controllers
  .. that's where I started)

* start ad-dc service

Result:

* replication OK according to "samba-tool  drs showrepl"

* smbclient -L localhost -N
session setup failed: NT_STATUS_INTERNAL_ERROR

# wbinfo -t
could not obtain winbind interface details: WBC_ERR_WINBIND_NOT_AVAILABLE
could not obtain winbind domain name!
checking the trust secret for domain (null) via RPC calls failed
failed to call wbcCheckTrustCredentials: WBC_ERR_WINBIND_NOT_AVAILABLE
Could not check secret

* # ps axf | egrep "winbindd"
   81207 pts/0    S+     0:00          \_ grep -E winbindd
   80980 ?        S      0:00  |   \_ samba: task[winbindd] pre-fork master
   80985 ?        Ss     0:00  |           \_ /usr/sbin/winbindd -D 
--option=server role check:inhibit=yes --foreground
   81004 ?        S      0:00  |               \_ winbindd: domain child 
[ARBEITSGRUPPE]

-

So basically the same result as last week. This is 4.17.3+dfsg-2~bpo11 
from bullseye-backports.

I can only think of checking installed packages and maybe remove and 
reinstall stuff. Maybe something is missing or ...