#47736 ldapdelete returns non-leaf entry error while trying to remove a leaf entry
Closed: wontfix None Opened 10 years ago by mreynolds.

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.

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

7 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata