[Samba] Samba 4.5.0 dbcheck problems

[Andrew Bartlett]

On Wed, 2016-12-07 at 12:23 +0000, Chris Alavoine via samba wrote:
> Hi all,
> 
> I've now upgraded to Samba-4.5.2 and I've tried running:
> 
> samba-tool domain tombstones expunge
> 
> but I simpley get:
> 
> Removed 0 objects and 0 links successfully, however I'm still seeing
> several hundred errors when running a dbcheck with the "not remocing
> dangling forward link" error.
> 
> I've checked my time.py and it has been renamed so the expunge
> process
> should be using nettime.py.
> 
> Any ideas? Aside from removing the entries manually using ldbedit.
> 
> c:)

We would need to know more about what the dandling forward links are. 
Also, does master do something different (we thought we backported the
patches, but please check to be sure). 

Thanks,

Andrew Bartlett

> On 12 October 2016 at 13:29, Chris Alavoine <chrisa at acs-info.co.uk>
> wrote:
> 
> > Hi all,
> > 
> > I've recently upgraded all our DC's (we have 9 spread over various
> > global
> > Sites) to 4.5.0.
> > 
> > I run a dbcheck on our FSMO-owner DC once per day from a cron job
> > and this
> > threw up a ton of errors on the first pass after the upgrade. After
> > running
> > it several times with the --fix flag I've got the errors down to
> > 603 but
> > these last errors are refusing to be removed.
> > 
> > Here is an example of each type:
> > 
> > Example1:
> > *ERROR: incorrect GUID component for member in object
> > CN=examplegroup,OU=Groups,DC=example,DC=internal,DC=com -
> > <GUID=77ad92b5ade70e449dcc481624928310>;<RMD_ADDTIME=13039347668000
> > 0000>;<RMD_CHANGETIME=130976799640000000>;<RMD_FLAGS=1>;<RMD_INVOCI
> > D=98307faefea70749933e6946b1b14420>;<RMD_LOCAL_USN=1445979>;<RMD_OR
> > IGINATING_USN=303848>;<RMD_VERSION=1>;<SID=010500000000000515000000
> > e8e83f391df4408a63c6a6b4d25a0000>;CN=simon.test,CN=Users,DC=example
> > ,DC=internal,DC=com*
> > 
> > Example2:
> > *ERROR: incorrect DN string component for member in object
> > CN=admin-group-001,OU=Groups,DC=example,DC=internal,DC=com -
> > <GUID=38370cfc-6751-49bb-945e-
> > d2b5e028f0f3>;<RMD_ADDTIME=130941544260000000>;<RMD_CHANGETIME=1309
> > 41560040000000>;<RMD_FLAGS=1>;<RMD_INVOCID=a65d0f39-311e-4031-aa56-
> > a8585bfc1b8f>;<RMD_LOCAL_USN=1443123>;<RMD_ORIGINATING_USN=1443123>
> > ;<RMD_VERSION=1>;<SID=S-1-5-21-960489704-2319512605-3030828643-
> > 1219569>;CN=user.test,OU=Test
> > OU,DC=example,DC=internal,DC=com*
> > 
> > Example3:
> > *unable to find object for DN
> > CN=test.user2,CN=Users,DC=example,DC=internal,DC=com - (No such
> > Base DN:
> > CN=test.user2,CN=Users,DC=example,DC=internal,DC=com)*
> > *Not removing dangling forward link*
> > 
> > I have edited these entries to maintain anonymity.
> > 
> > Any ideas on how to remove these errors?
> > 
> > Replication appears to be working fine between all DCs (aside from
> > one
> > that is showing a WERR_BADFILE error, although I don't think this
> > is
> > related), we are able to use the domain as normal and performance
> > seems
> > good. Would be nice to clean up these errors though.
> > 
> > Thanks,
> > Chris.
> > 
> > 
> > --
> > ACS (Alavoine Computer Services Ltd)
> > Chris Alavoine
> > mob +44 (0)7724 710 730 <07724%20710730>
> > www.alavoinecs.co.uk
> > http://twitter.com/#!/alavoinecs
> > http://www.linkedin.com/pub/chris-alavoine/39/606/192
> > 
> 
> 
> 
> -- 
> ACS (Alavoine Computer Services Ltd)
> Chris Alavoine
> mob +44 (0)7724 710 730
> www.alavoinecs.co.uk
> http://twitter.com/#!/alavoinecs
> http://www.linkedin.com/pub/chris-alavoine/39/606/192