[Samba] unique index violation on objectSid

mathias dufresne infractory at gmail.com
Tue Jun 28 14:44:25 UTC 2016


I love diving : )

2016-06-28 16:44 GMT+02:00 mathias dufresne <infractory at gmail.com>:

>
>
> 2016-06-28 14:22 GMT+02:00 valera <valera at zvn.p98.belkam.com>:
>
>> 28.06.2016 15:50, mathias dufresne:
>> > Here I'm thinking of two workarounds. The first one would be to list
>> > deleted objects RIDs, to verify RID=2002 is really the last one used,
>> > being sure there is no deleted object with RID=2003 and so on. Then once
>> > you get the last RID used, you could change RidNextRid to match this
>> > maximum value of used RID.
>> It is safe to change RidNextRid? I correctly understand that RidNextRid
>> should be changed on the DC, where rIDPreviousAllocationPool contains
>> RID of last created object?
>>
>
> No idea if it is safe. I just meant that's I would try : )
>
> About where to change it, not much more idea. I would change it on the DC
> you tried to add user because this is the DC which refused to use the RID
> pool it was given because RidNextRid contains a value too low compared to
> already given RID.
> I did searched on my FSMO owner for " CN=RID Set" and I receive one answer
> per DC. Each with different rIDAllocationPool of course.
>
> I believe I read something here about something not replicated (no time to
> re-read the whole thread carefully enough, sorry), if you change rIDNextRID
> by hand just check on others DC your change is replicated, to keep a DB
> consistent. I expect it is replicated, that would be a simple way for FSMO
> RID master to know it has to give more RIDs pools.
>
>
>>
>> > The second would be a lazy action: change tombstoneLifetime which is by
>> > default 180 days to only 1 day. Doing that tomorrow all deleted objects
>> > will be deleted and if you are lucky - I can't guaranty that will work -
>> > you will able to reuse these RIDs.
>> No, to only 1 day is it impossible:
>> https://technet.microsoft.com/en-us/library/dd392260(v=ws.10).aspx If
>> the value is less than 3 days, the tombstone lifetime is 3 days.
>>
>
> 1 day is accepted by Samba DB. I did tried : )
> I'm not sure if my objects were deleted just 24 hours after the change or
> earlier or later. Anyway 1 or 3 days could be an acceptable delay to
> auto-solve an unsolvable issue. At least for me it seems acceptable ;)
>
> The point of that change is you are diving into unknown when playing with
> RID pool data seems a bit of a dive.
>
>
>>
>> >
>> > Hoping this helps...
>> And I...
>>
>> Valery
>>
>
>


More information about the samba mailing list