>>> From: "Alberto Viana" <albertocrj@xxxxxxxxx> >>> To: "General discussion list for the 389 Directory server project." <389-users@xxxxxxxxxxxxxxxxxxxxxxx> >>> Sent: Tuesday, March 20, 2018 6:15:46 PM >>> Subject: [389-users] error moving an user >>> >>> Hey Guys, >>> >>> 389 version: 389-Directory/1.3.7.4.20170912git26a9426 B2017.255.1330 >>> >>> I'm trying to move one of my users to another OU and I see this kind of >>> error: >>> >>> Error while moving entry >>> - [LDAP: error code 1 - Operations Error] >>> java.lang.Exception: [LDAP: error code 1 - Operations Error] >>> at >>> >>> >>> In the log I see: >>> >>> [20/Mar/2018:14:12:27.172553808 -0300] - ERR - ldbm_back_modrdn - >>> SLAPI_PLUGIN_BE_TXN_POST_MODRDN_FN plugin returned error but did not set >>> SLAPI_RESULT_CODE >>> >>> I thought that was related to my windows replication, but I disabled it and >>> I'm still getting the error. >>> >>> Any clues? >>> >>> _______________________________________________ >>> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx >>> On Wed, Mar 21, 2018 at 12:00 PM, Simon Pichugin <spichugi@xxxxxxxxxx> wrote: >> Hi, >> could you please enable 16385 errorlog-level (16384 defaults and 1 trace) just before the operation and send us the /var/log/dirsrv/slapd-INSTNAME/errors: >> >> ldapmodify -h localhost -p 389 -D "cn=Directory manager" -w password << EOF >> dn: cn=config >> changetype: modify >> replace: nsslapd-errorlog-level >> nsslapd-errorlog-level: 16385 >> EOF >> >> Thanks, >> Simon Alberto Viana wrote on 3/23/2018 8:08 AM: > Simon, > > I was able to reproduce the problem in a new fresh install (I just imported my database), and It's related to "Referential Integrity Postoperation Plugin" that I use in my environment. When I disable it, the moving works just fine. > > I have a single master, replication to one AD. > > I changed the log level, but it's really hard to find the root cause. > > Do you want to take a look on it? > > > Once it has some info about my tree, I'd prefer to send the link to download the file directly to you. > > Thanks. Was this issue ever resolved? I'm experiencing the same symptom intermittently in a production environment but haven't managed to reproduce it in my test environment. The DN gets updated but the uid (naming attribute) does not. Restarting slapd has helped in one instance (to apparently fix a corrupted entry) but not every instance. [27/Sep/2018:11:29:31.994645991 -0800] - ERR - ldbm_back_modrdn - SLAPI_PLUGIN_BE_TXN_POST_MODRDN_FN plugin returned error but did not set SLAPI_RESULT_CODE It's a single master configuration with two consumer replicas and about 37000 entries. The Referential Integrity Postoperation Plugin is enabled on the master only. using: > rpm -qa | grep 389-ds-base 389-ds-base-1.3.7.5-25.el7_5.x86_64 389-ds-base-libs-1.3.7.5-25.el7_5.x86_64 > uname -a Linux 3.10.0-862.11.6.el7.x86_64 #1 SMP Tue Aug 14 21:49:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
