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

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.

/mjt
> Currently I turned that flaky DC off just to avoid clients timing out
trying to access those non working shares.
> 
> Thanks, Stefan
> 
> 
>

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.