Mac OS Server Open Directory Will Not Turn On

I've had the same problem after having zero issues with the Server 3 update for OSx 10.9 Mavricks.

It was repairing the permissions and then rebuilding the authdata which fixed mine. The authdata permissions were quite foobar'd, as was my /Users directory.

Up and running again. Thank you everyone.

From my bash history:

sudo launchctl unload /System/LIbrary/LaunchDaemons/org.openldap.slapd.plist

diskutil repairPermissions /

sudo db_recover -cv -h /var/db/openldap/openldap-data/

sudo /usr/libexec/slapd -Tt

sudo db_recover -cv -h /var/db/openldap/authdata/

sudo /usr/libexec/slapd -Tt

sudo launchctl load /System/LIbrary/LaunchDaemons/org.openldap.slapd.plist

This worked like a charm. We've been barking up an entire forrest of trees after our OD randomly corrupted and finaly found this. THANK YOU!!!

Hi guys

First off, I'm a rookie thats managed to work things out as they happen, but this is getting annoying.

This original list of instructions helped me get the users list back allowing them to login and continue working, but I seem to have a continuing error/coruption of my database within 30mins of completing the fix.

I am even supecting that when one of the users tries to log in that this is when the error happens. I think it also happens when this user shutsdown/sleepmode her computer that the dropout in the server happens. Is this possible and how can I fix this?

Below is part of the error log from the LDAP Log. It repeats everything until I hit it on the head again with the fix. Of further interest I can actually skip all the internal steps and just complete these 2 steps and the list of users returns. But I have completed the full list of steps a number of times already over the past 4 days.

sudo launchctl unload /System/LIbrary/LaunchDaemons/org.openldap.slapd.plist

sudo launchctl load /System/LIbrary/LaunchDaemons/org.openldap.slapd.plist

Dec 9 14:48:02 server.local slapd[13071]: bdb(dc=server,dc=local): PANIC: fatal region error detected; run recovery\

Dec 9 14:48:02 server.local slapd[13071]: bdb_db_close: database "dc=server,dc=local": close failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30974)\

Dec 9 14:48:03 server.local slapd[13071]: slapd stopped.\

Dec 9 14:49:32 server.local slapd[75364]: @(#) $OpenLDAP: slapd 2.4.28 (Jul 4 2013 21:47:41) $\

root@b1026.apple.com:/private/var/tmp/OpenLDAP/OpenLDAP-208.5~1/servers/slapd\

Dec 9 14:49:32 server.local slapd[75364]: daemon: SLAP_SOCK_INIT: dtblsize=8192\

Dec 9 14:49:32 server.local slapd[75364]: bdb_db_open: database "dc=server,dc=local": unclean shutdown detected; attempting recovery.\

Dec 9 14:49:32 server.local slapd[75364]: bdb_monitor_db_open: monitoring disabled; configure monitor database to enable\

Dec 9 14:49:32 server.local slapd[75364]: slapd starting\

Dec 9 14:49:32 server.local slapd[75364]: daemon: posting com.apple.slapd.startup notification\

Dec 9 15:18:32 server.local slapd[75364]: bdb(dc=server,dc=local): file entryCSN.bdb has LSN 1/4864619, past end of log at 1/3825871\

Dec 9 15:18:32 server.local slapd[75364]: bdb(dc=server,dc=local): Commonly caused by moving a database from one database environment\

Dec 9 15:18:32 server.local slapd[75364]: bdb(dc=server,dc=local): to another without clearing the database LSNs, or by removing all of\

Dec 9 15:18:32 server.local slapd[75364]: bdb(dc=server,dc=local): the log files from a database environment\

Dec 9 15:18:32 server.local slapd[75364]: => bdb_idl_insert_key: c_put id failed: Operation not permitted (1)\

Dec 9 15:18:32 server.local slapd[75364]: conn=1224 op=3: attribute "entryCSN" index add failure\

Dec 9 15:31:32 server.local slapd[75364]: bdb(dc=server,dc=local): DB_ENV->log_flush: LSN of 1/4864619 past current end-of-log of 1/3826132\

Dec 9 15:31:32 server.local slapd[75364]: bdb(dc=server,dc=local): Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment\

Dec 9 15:31:32 server.local slapd[75364]: bdb(dc=server,dc=local): PANIC: DB_RUNRECOVERY: Fatal error, run database recovery\

Dec 9 15:31:32 server.local slapd[75364]: bdb(dc=server,dc=local): entryCSN.bdb: unable to flush page: 1\

Dec 9 15:31:32 server.local slapd[75364]: bdb(dc=server,dc=local): txn_checkpoint: failed to flush the buffer cache: DB_RUNRECOVERY: Fatal error, run database recovery\

Dec 9 15:32:11 server.local slapd[75364]: bdb(dc=server,dc=local): PANIC: fatal region error detected; run recovery\

Dec 9 15:32:11: --- last message repeated 2 times ---\

Dec 9 15:32:11 server.local slapd[75364]: CFDictionaryRef odusers_copy_effectiveuserpoldict(struct berval *): No entry associated with cn=server.local$,cn=computers,dc=server,dc=local\

Dec 9 15:32:11 server.local slapd[75364]: int slap_sasl_bind(Operation *, SlapReply *): could not retrieve effective policy for: cn=server.local$,cn=computers,dc=server,dc=local\

Dec 9 15:32:11 server.local slapd[75364]: SASL [conn=1256] Error: attempting server step after doneflag\

Dec 9 15:32:11 server.local slapd[75364]: bdb(dc=server,dc=local): PANIC: fatal region error detected; run recovery\

Dec 9 15:32:11 server.local slapd[75364]: int slap_sasl_bind(Operation *, SlapReply *): Error to increment failed login count for cn=server.local$,cn=computers,dc=server,dc=local\

Dec 9 15:32:11 server.local slapd[75364]: bdb(dc=server,dc=local): PANIC: fatal region error detected; run recovery\

Dec 9 15:32:41: --- last message repeated 17 times ---\

Dec 9 15:32:59 server.local slapd[75364]: bdb(dc=server,dc=local): PANIC: fatal region error detected; run recovery\

Dec 9 15:33:32: --- last message repeated 1 time ---\

Dec 9 15:33:32 server.local slapd[75364]: bdb(dc=server,dc=local): PANIC: fatal region error detected; run recovery\

Dec 9 15:34:32 server.local slapd[75364]: bdb(dc=server,dc=local): PANIC: fatal region error detected; run recovery\

Dec 9 15:35:11 server.local slapd[75364]: bdb(dc=server,dc=local): PANIC: fatal region error detected; run recovery\

Dec 9 15:35:11: --- last message repeated 2 times ---\

Hi S-N-Y, thanks you , the sudo db_recover -cv -h /var/db/openldap/authdata/ step worked correctly.

I had upgraded to 10.9.1 and my OD would not start. This has reinstated it.

great tip!

W

Hong Kong

Adding a note of caution on this solution; but db_recover won't resurrect a failed OD for everyone.

In my case - many different causes of OD failing I suppose - the above command restored the wrong Generated UIDs for my users so no one could log into IMAP etc. and there continued to spew forth other very worrying system log messages from a corrupted password server.

What did work for me - huge sigh of relief! (we are at OS X 10.9.1; Server.app 3.0.2) was to

slapconfig -restoredb  /Volumes/Macintosh\ HD2/OD\ Master\ Backups/ODArchive.sparseimage

We have upgraded our OS X Server from ML to Mavericks incrementally over recent years in the vain hope that OD will become more stable. For us it has always seemed very fragile and our paranoid creation of OD Archives has saved my bacon more than once.

I don't suppose our solution will apply to all, but I hope some are encouraged to archive OD when it appears to be working smoothly, and that it helps them like it has helped us.

I had the same issue, but my problem was in /var/db/openldap/authdata/

also, the catastrophic recovery would continuously report that it failed and to run DB_RECOVERY, so I ran

sudo db_recover -v -h /var/db/openldap/authdata/

and to my surprise it reported authdata was healthy, and I was able to start after following the rest of the instructsion. Apparently, I should have read further down to sing S-N-Y's comment with directly addressed my issue.

thanks for the insight!

Thank you, worked fine!

Thank you so much. Saved me..

Thanks for these detailed instructions. Unfortunately that command didn't help me either. This is the output I get:

sudo db_recover -cv -h /var/db/openldap/authdata/

Finding last valid log LSN: file: 37 offset 379146

db_recover: file unknown has LSN 37/8513802, past end of log at 37/379146

db_recover: Commonly caused by moving a database from one database environment

db_recover: to another without clearing the database LSNs, or by removing all of

db_recover: the log files from a database environment

Recovery starting from [36][28]

db_recover: Log sequence error: page LSN 20 8843547; previous LSN 35 10479300

db_recover: Recovery function for LSN 36 6763 failed on forward pass

db_recover: PANIC: Invalid argument

db_recover: process-private: unable to find environment

db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery

Any ideas what to do there?

Quick update: I was able to fix this using the following command:

sudo slapconfig -restoredb <full path to backup>/var/backups/ServerBackup_OpenDirectoryMaster.sparseimage

Hopefully this comes in handy for others as well. 🙂

TheLostLibrary THANK YOU!!!! U a super star!!!

That code helped fix my OD problem perfectly. Running Maverick Server 3.2.1

Server had to be forced shutdown as it was freezing. After restart no users and no groups in the OD, only local users.

OD does not enable in the GUI of Server.

I suspected some permissions problem but normal Disk Repair and Permission repair had no effect.

THANK YOU AGAIN!!!

Thank you TheLostLibrary

your list of commands did the trick for me.

here they are again

sudo launchctl unload /System/LIbrary/LaunchDaemons/org.openldap.slapd.plist

diskutil repairPermissions /

sudo db_recover -cv -h /var/db/openldap/openldap-data/

sudo /usr/libexec/slapd -Tt

sudo db_recover -cv -h /var/db/openldap/authdata/

sudo /usr/libexec/slapd -Tt

sudo launchctl load /System/LIbrary/LaunchDaemons/org.openldap.slapd.plist

Mac OS X 10.8.5 server version 2.2.4

When my OD fails to start after a crash and db_recover commands don't work, it's always worked for me to restore the odmaster from a backupusing the command:

sudo slapconfig -restoredb /private/var/backups/ServerBackup_OpenDirectoryMaster.sparseimage

I'm careful to keep an independent OD backup with Carbon Copy Cloner and this preflight script.

You can also grab an earlier version of the sparse image ServerBackup_OpenDirectoryMaster.sparseimage from a Time Machine backup. It's also possible to rsync the database files directory from a Time Machine backup.

Thanks S-N-Y, this worked for me also.

Saved my Butt!!!