389-ds-base

#49807 Adding backend entry fails after creating a new instance using dscreate
Closed: wontfix Opened by mmuehlfeldrh.

Closed: wontfix
Reopen Issue

Issue Description

After creating a new instance using dscreate and adding the root suffix, adding entries fail with a ldap_add: No such object (32) error.

Package Version and Platform

389-Directory/1.4.0.11.20180626git749b9f332 B2018.177.825

Steps to reproduce

  1. Use dscreate to create a new instance.

  2. Create the root suffix:
    # ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

    dn: cn="dc=example,dc=com",cn=mapping tree,cn=config
    changetype: add
    cn: dc=example,dc=com
    objectclass: top
    objectclass: extensibleObject
    objectclass: nsMappingTree
    nsslapd-state: backend
    nsslapd-backend: UserData

  3. Try to add an entry:
    # ldapadd -D "cn=Directory Manager" -w password -x
    dn: dc=example,dc=com
    objectClass: top
    objectClass: domain
    dc: example

    adding new entry "dc=example,dc=com"
    ldap_add: No such object (32)

Actual results

Server responds: ldap_add: No such object (32)

Expected results

Adding the entry should work.

What is the access log when you get an error 32? It could be the bind for cn=directory manager, and not the actual add operation.

Metadata Update from @mreynolds:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None

What is the access log when you get an error 32? It could be the bind for cn=directory manager, and not the actual add operation.

[26/Jun/2018:14:11:42.613357138 +0200] conn=2 fd=64 slot=64 connection from ::1 to ::1
[26/Jun/2018:14:11:42.614054870 +0200] conn=2 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[26/Jun/2018:14:11:42.646363253 +0200] conn=2 op=1 ADD dn="dc=example,dc=com"
[26/Jun/2018:14:11:42.651282664 +0200] conn=2 op=2 UNBIND
[26/Jun/2018:14:11:42.651296492 +0200] conn=2 op=2 fd=64 closed - U1
[26/Jun/2018:14:11:42.651324143 +0200] conn=2 op=1 RESULT err=32 tag=105 nentries=0 etime=0.0006086773
[26/Jun/2018:14:11:42.653283270 +0200] conn=2 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0039652304 dn="cn=directory manager"

you also need to add the backen below cn=ldbm database not only the mapping tree entry

I think you are not adding the ldbm backend entry, adding the actual suffix entry should work after adding this entry:

dn: cn=UserData,cn=ldbm database,cn=plugins,cn=config
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: dc=example,dc=com

I think you are not adding the ldbm backend entry, adding the actual suffix entry should work after adding this entry:
dn: cn=UserData,cn=ldbm database,cn=plugins,cn=config
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: dc=example,dc=com

This was the reason and fixed the problem. I will mention this in the docs.

Please close this ticket as NOTABUG.

Metadata Update from @mreynolds:
- Issue close_status updated to: invalid
- Issue status updated to: Closed (was: Open)

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/2866

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: invalid)
Metadata
None
None
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.