Johannes Amorosa | Celluloid VFX
2016-Apr-08 06:36 UTC
[Samba] Getting rIDNextRID errors after upgrading two samba ADs to 4.2
We finally managed to upgrade from samba 4.1 to 4.2.9 (sernet packages). We have two replicated samba ADs. After the upgrade everything seems to work as expected, but I'm constantly getting this error message in the logs. They weren't there before the upgrade: We used the Updating samba wiki entry as howto[1] The first dc logs this: Failed extended allocation RID pool operation - Failed to modify RID Set object CN=RID Set,CN=CELL-DC-03,OU=Domain Controllers,DC=celluloidvfx,DC=inc - objectclass_attrs: at least one mandatory attribute ('rIDNextRID') on entry 'CN=RID Set,CN=CELL-DC-03,OU=Domain Controllers,DC=celluloidvfx,DC=inc' wasn't speci#020#001 The second one this: cell-dc-03 samba[1481]: ../source4/dsdb/repl/drepl_ridalloc.c:43: RID Manager failed RID allocation - WERR_DS_DRA_INTERNAL_ERROR - extended_ret[0x0 Is this something to be worried about? Thank you for your time. [1] https://wiki.samba.org/index.php/Updating_Samba -- Johannes Amorosa | Celluloid VFX Celluloid Visual Effects GmbH & Co. KG Paul-Lincke-Ufer 39/40, 10999 Berlin phone +49 (0)30 / 54 735 220 fax +49 (0)30 / 54 735 221
Johannes Amorosa | Celluloid VFX
2016-Apr-08 13:20 UTC
[Samba] Getting rIDNextRID errors after upgrading two samba ADs to 4.2
On 04/08/2016 08:36 AM, Johannes Amorosa | Celluloid VFX wrote:> We finally managed to upgrade from samba 4.1 to 4.2.9 (sernet > packages). We have two replicated samba ADs. After the upgrade > everything seems to > work as expected, but I'm constantly getting this error message in the > logs. They weren't there before the upgrade: > > We used the Updating samba wiki entry as howto[1] > > The first dc logs this: > Failed extended allocation RID pool operation - Failed to modify RID > Set object CN=RID Set,CN=CELL-DC-03,OU=Domain > Controllers,DC=celluloidvfx,DC=inc - objectclass_attrs: at least one > mandatory attribute ('rIDNextRID') on entry 'CN=RID > Set,CN=CELL-DC-03,OU=Domain Controllers,DC=celluloidvfx,DC=inc' wasn't > speci#020#001 > > > The second one this: > cell-dc-03 samba[1481]: ../source4/dsdb/repl/drepl_ridalloc.c:43: RID > Manager failed RID allocation - WERR_DS_DRA_INTERNAL_ERROR - > extended_ret[0x0 > > > Is this something to be worried about? > Thank you for your time. > > > > [1] https://wiki.samba.org/index.php/Updating_Samba >A possible solution is to demote the second DC and rejoin the domain again - any suggestion if this is necessary? JA -- Johannes Amorosa | Celluloid VFX Celluloid Visual Effects GmbH & Co. KG Paul-Lincke-Ufer 39/40, 10999 Berlin
Adam Tauno Williams
2016-Sep-19 13:35 UTC
[Samba] Getting rIDNextRID errors after upgrading two samba ADs to 4.2
On Fri, 2016-04-08 at 15:20 +0200, Johannes Amorosa | Celluloid VFX wrote:> On 04/08/2016 08:36 AM, Johannes Amorosa | Celluloid VFX wrote: > > We finally managed to upgrade from samba 4.1 to 4.2.9 (sernet > > packages). We have two replicated samba ADs. After the upgrade > > everything seems to work as expected, but I'm constantly getting > > this error message in the logs. They weren't there before the > > upgrade:Also just upgraded my Samba DCs... now I am seeing this same condition. Any suggestions? Current Version: sernet-samba-4.2.14-23.el6.x86_64> > We used the Updating samba wiki entry as howto[1] > > The first dc logs this: > > Failed extended allocation RID pool operation - Failed to modify > > RID > > Set object CN=RID Set,CN=CELL-DC-03,OU=Domain > > Controllers,DC=celluloidvfx,DC=inc - objectclass_attrs: at least > > one > > mandatory attribute ('rIDNextRID') on entry 'CN=RID > > Set,CN=CELL-DC-03,OU=Domain Controllers,DC=celluloidvfx,DC=inc' > > wasn't > > speci#020#001 > > > > > > The second one this: > > cell-dc-03 samba[1481]: ../source4/dsdb/repl/drepl_ridalloc.c:43: > > RID > > Manager failed RID allocation - WERR_DS_DRA_INTERNAL_ERROR - > > extended_ret[0x0 > > Is this something to be worried about? > > Thank you for your time. > > [1] https://wiki.samba.org/index.php/Updating_Samba > A possible solution is to demote the second DC and rejoin the > domain again - any suggestion if this is necessary?-- Adam Tauno Williams <mailto:awilliam at whitemice.org> GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA