Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 1053766
Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.
+++ This bug was initially created as a clone of Bug #947583 +++ Description of problem: Error deleteing object When trying to delete an object #!ERROR [LDAP: error code 66 - Not Allowed On Non-leaf] The following error msg occurs when attempting to delete an object that has tombstonNumSubordinates. #!CONNECTION ldap://lgnrca10.lnx.local:636 #!DATE 2014-01-13T13:11:34.972 #!ERROR [LDAP: error code 66 - Not Allowed On Non-leaf] dn: ou=auto.home,ou=mounts,dc=ca,dc=gov changetype: delete Version-Release number of selected component (if applicable): 389-ds-base-1.2.11.15-31.el6_5.x86_64 389-ds-base-libs-1.2.11.15-31.el6_5.x86_64 389-ds-console-doc-1.2.7-1.el6.noarch 389-ds-console-1.2.7-1.el6.noarch How reproducible: Unknown Steps to Reproduce: 1. Setup multi-master DS environment 2. Need to create an object that has tombonNumSubordinates 3. Attempt to delete it. Actual results: Directory server returns non-leaf entry while trying to remove a leaf entry. Expected results: Successful deletion... Additional info:
I can no longer reproduce any errors. All versions seem to be working now after I redid my setup.
I am sort of reproducing this error, but I get an operations error first:
... ... deleting children of: uid=mark180,ou=people,dc=example,dc=com removing uid=mark35,ou=people,dc=example,dc=com ldap_delete: Operations error (1) ldap_delete: Operation not allowed on non-leaf (66)
So we get an error 1(operations error) when trying to delete uid=mark180, then ldapdelete just tries to delete the parent ou=people,dc=example,dc=com", which of course returns error 66 as there are still many entries beneath it:
[07/Apr/2014:10:32:14 -0400] conn=5 op=293 DEL dn="uid=mark180,ou=people,dc=example,dc=com" [07/Apr/2014:10:32:15 -0400] conn=5 op=293 RESULT err=1 tag=107 nentries=0 etime=1 csn=5342b6f1000000040000 [07/Apr/2014:10:32:15 -0400] conn=5 op=294 DEL dn="ou=people,dc=example,dc=com" [07/Apr/2014:10:32:15 -0400] conn=5 op=294 RESULT err=66 tag=107 nentries=0 etime=0
So the error 66 is expected and normal in this case, but the operations error on the previous delete is not. Still investigating.
attachment 0001-Ticket-47736-Import-incorrectly-updates-numsubordina.patch
I could recreate numsubordinates being incorrectly updated during imports when processing tombstone entries. Leaving the parent entry with a numsubordinate count higher than expected - which would lead to an error 66 if you try to delete the subtree. This is isolated to 1.2.11, as 1.3.1 and up have the correct logic. Patch attached.
Thanks, Mark. If you could also adjust the comment, I'd appreciate it. It's totally wrong... :(
git merge ticket47736 Updating 9f174da..73d6372 Fast-forward ldap/servers/slapd/back-ldbm/import-threads.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)
git push origin 389-ds-base-1.2.11 9f174da..73d6372 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 73d6372 Author: Mark Reynolds mreynolds@redhat.com Date: Mon Apr 14 15:49:33 2014 -0400
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 1.2.11.30
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/704
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.