[Samba] messy replication

Rowland penny rpenny at samba.org
Mon Jul 22 12:01:09 UTC 2019

On 22/07/2019 12:41, Adam Weremczuk via samba wrote:
> Hi Rowland,
> On 18/07/19 15:52, Rowland penny via samba wrote:
>> my plan would be to:
> I did it on Friday afternoon after my numerous attempts to demote DC2 
> failed.
> This fixed one issue - made the network shares appear again across all 
> clients.
> A new one has been discovered though on one of our CentOS 5.11 boxes.

I am beginning to think we should rename this thread to 'messy network' ;-)

I do hope you have 'I must upgrade the dead OS Centos 5' on your to-do list.

> Any command (like sudo or ssh) that needs authentication or user name 
> lookup takes a long time to complete.
> This doesn't only make working with this machine very difficult but 
> also makes lots of complex scripts to fail due to timeouts.
> Even though DC2 ( has been powered off for almost 3 days 
> I can still see this client trying to connect to it when I ssh from 
> another terminal:
> [root at centos log]# lsof | grep
> sshd      6630      root    7u     IPv4              24776 0t0        
> TCP centos.company.co.uk:57423-> (SYN_SENT)
> sshd      6642      root    7u     IPv4              24812 0t0        
> TCP centos.company.co.uk:57425-> (SYN_SENT)
> At the same time I can see a lot of successful TCP flags (ESTABLISHED, 
> CLOSE_WAIT) against DC1.
> Since no configuration changes have been made on this CentOS box I'm 
> assuming it must be DC1 advertising DC2 to clients.
If DC2 is still in the database, it will be.
> Is removing references to DC2 from DC1 the only option to resolve it 
> or are there any quick tricks available to try?
> E.g. some cache still needs to expire or needs to be forced to do so.

You could try restarting Samba, this should recreate any caches, but I 
think you will need to remove DC2. There are two ways of doing this, 
manually with ldbdel etc or starting climbing the Samba versions until 
you get to a point that you can backup everything and be able to run the 
demote with '--remove-other-dead-server'


>> Remove any trace of DC2 from DC1
> I'm assuming I need to try exactly the same thing as last time?
> ldbedit -e vim -H /var/lib/samba/private/sam.ldb --cross-ncs
> Any difference running it with samba running vs samba stopped?
> Apart from DDNS updates there should be no modifications made to AD 
> during the edit process (e.g. no machines or users added, removed, no 
> password changed etc.).
>> Run 'samba-tool dbcheck --fix --yes --cross-ncs'
>> Hopefully this will fix DC1, but your Samba is that old, I cannot 
>> remember if that will run on your DC.
>> Your main problem is that your DC is in production, that is why I 
>> said to back everything up before you start. 
> I've skimmed through: 
> https://wiki.samba.org/index.php/Back_up_and_Restoring_a_Samba_AD_DC
> and my understanding is both online and offline samba-tool backups are 
> only available in the very latest versions 4.9 and 4.10.
> So the only option I have is a manual data backup.
> Is it sufficient to back up /var/lib/samba folder (containing *.ldb, 
> sysvol and netlogon) and restore it entirely if a disaster strikes?
> Any benefit of stopping samba before creating a tarball?
> Thanks,
> Adam

More information about the samba mailing list