-
All replies
-
Helpful answers
-
Oct 31, 2013 12:23 PM in response to francisfromhavertownby TheLostLibrary,★HelpfulI'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
-
Nov 12, 2013 2:51 PM in response to TheLostLibraryby barons_lab49,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!!!
-
Dec 8, 2013 10:36 PM in response to TheLostLibraryby AcaleusThor,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 ---\
-
Dec 22, 2013 9:20 PM in response to S-N-Yby Warwick Teale,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
-
by Trismegister,Feb 15, 2014 10:32 AM in response to Warwick Teale
Trismegister
Feb 15, 2014 10:32 AM
in response to Warwick Teale
Level 1 (22 points)
Servers EnterpriseAdding 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.sparseimagewhere the path related to a backup I'd made from the OD page of Server.app by choosing "Archive Open Directory Master" a few days before.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.
-
May 28, 2014 8:38 PM in response to neocodesoftwareby Armand Welsh,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!
-
-
Jun 9, 2014 4:37 AM in response to francisfromhavertownby johannfromberlin,Thank you so much. Saved me..
-
Aug 29, 2014 4:31 PM in response to S-N-Yby Miggl,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?
-
Aug 30, 2014 8:31 AM in response to Migglby Miggl,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.
-
Oct 11, 2014 11:48 PM in response to TheLostLibraryby NatureHelps,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!!!
-
Oct 20, 2014 1:46 AM in response to TheLostLibraryby Robert Talevski1,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
-
Dec 9, 2014 3:32 PM in response to francisfromhavertownby essandess,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 backup using 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.
-
-