Тоже нарвался на подобную ситуацию.
Мне помогло следующее решение:
(1) Stop the ldap server
/etc/init.d/ldap stop
Just to be sure the server is stopped,
killall slapd
(2) Make a backup of your existing directory structure:
tar -cvzf ldap.tar.gz /var/lib/ldap/*
Put it someplace safe in case something goes wrong with this procedure.
(3) Perform a recovery:
db_recover -h /var/lib/ldap -v
(4) Dump the directory structure to a text file
slapcat -l ldap.ldif
(sometimes it is needed to delete all bdb files, _but_ "dn2id" and "id2entry", being able to "slapcat" the files)
(5) Verify that the resultant file (ldap.ldif) contains directory entries. If it does not, or if slapcat returned errors in step 4, try running db_recover in catastrophic mode:
db_recover -h /var/lib/ldap -v -c
После этого выполнить шаг 4 еще раз.)
(6) Delete the corrupted LDAP directory with the following command:
rm -fr /var/lib/ldap/*
(7) Recreate the DB_CONFIG file, which contains some basic informations for the bdb backend:
echo -en "set_cachesize 0 15000000 1\nset_lg_bsize 2097152\n" >/var/lib/ldap/DB_CONFIG
(8) Reload the LDAP directory from the ldap.ldif file you produced in step 4 with the following command:
slapadd -l ldap.ldif
(9) The files have to be owned by the user "ldap", hence we have to run
chown -R ldap: /var/lib/ldap
(10) Start the LDAP server
/etc/init.d/ldap start
Взято
отсюда.
Естественно, проставить корректные пути, у slapcat и slapadd откорректировать параметры по необходимости. Содержимое файла DB_CONFIG редактировать по своему усмотрению.
Возможно, кому-нибудь пригодится.