I tried the fix as automated by this script and also by hand as described in several sites (either via GUI or by deconstructing the command line from the linked script) and it would fail every time I went to write. I also twigged upon an annoying (possibly related, who knows exactly what upsets the thing) issue relating to accounts created with workgroup manager rather than with server.app - they have an incorrect entry (untitled_1 rather than the user's shortname) in AltSecurityIdentities. I won't swear that it's cured, because I thought that I had it cured two days ago and I was wrong, but it's run for 12 hours without screwing up totally, which is an improvement on where it's been since 2-1/2 days ago. Comment by "Ranj" on this page (with "service" commands that don't work for me) Restart LDAP launchctl load /System/Library/LaunchDaemons/Īnd at this point you might just as well reboot, too. You will see some harmless warnings during slapadd. It’s needed.ĥ) recreate the database from the LDIF format file cd /var/root/opendirectory cd /var/db/openldap/openldap-dataīe sure you don’t move, rename or delete the file named DB_CONFIG. ldif file will be empty - so check that it seems reasonable, and if not, start digging into backups.Ĥ) move the old (corrupt) database files out of the way (or remove them). If you don't do the repairs (or I suppose, if they don't work) the. As modified for my system.After doing the above repairs (you can skip the load step above)Ģ) shutdown LDAP (if you started it again) launchctl unload /System/Library/LaunchDaemons/ģ) dump a copy of the Open Directory database to an LDIF format text file mkdir /var/root/opendirectory The users were restive, the sysadmin was sleep-deprived and grumpy.Įventually I found a procedure that once again had to be somewhat modified on a site I'll try to link to again, as a comment on an answer similar to the above process.
It would work for a relatively short time, then crap out again. Rebooting or not seemed to make little difference. $ sudo launchctl load /System/Library/LaunchDaemons/
Macos server ldap partial replica mac os x#
$ sudo db_recover -h /var/db/openldap/openldap-data/ # Mac OS X 10.6 (this one too, even on 10.7) $ sudo db_recover -h /var/db/openldap/authdata/ # Mac OS X 10.7 So, on my Lion system (10.7.5) running Server.app 10.7.5(1.5.0), I'd have to do: $ sudo launchctl unload /System/Library/LaunchDaemons/
Macos server ldap partial replica how to#
The answer I linked to in a comment above ( How to fix failing Open Directory (database "cn=authdata" cannot be opened, err 12) after hang) seemed helpful, but the problem recurred within a few hours at most - and I actually had to run what by the answer's lights would be both 10.6 and 10.7 commands for even that to work. Suggestions in the wild seem to be split between 10.6 and 10.7 commands even when they say lion server, or perhaps there are early and late 10.7 command changes I certainly don't recall precisely. I find that I don't recall exactly what I did when I originally asked this question - I think I may have ended up recreating the database (as in painfully by hand.) Anyway, two years on it happened again (and exactly the same start condition - shutdown did not shutdown when time machine had been "stopping" for days without stopping, or backing up, so the machine had to be powered off.) At least I have the files, but any better insight than that provided by the linked topics would be appreciated. It's going to be a late night trying to get my fileserver back in shape before other people arrive and want to use it. This topic at AFP548 (first I've heard of that forum) seems related, but applying it may be difficult given that my self-signed certs are expired rather than removed. Server has rebooted many times and LDAPv3 has been happy up until today. Presumably the problem occurred at first reboot after they expired That does not actually seem to be true however, looking at the expiry dates. Reboot after that - still doesn't seem to help. Server Alerts indicates self-signed certificates expired. LDAPv3/127.0.0.1 couldn't be opened because an unexpected error of type -14006 occurred" is the helpful, friendly response. Logged in the local administrative user - when trying to get to LDAP from workgroup manager " The node. When it came back up, there was a red ball at the right of the username box with a nastygram indicating that network accounts were not available. Shut down hung - after 15 minutes or so I powered it off. Shut down Lion Server 10.7.5 (on a 2011 Mini Server) today after Time Machine got itself in a tizzy and failed to backup for several hours while claiming it was "stopping" (presumably unrelated to problem, just the why of restarting it.) Similar to slapd daemon can't start but despite being accepted, the answer didn't really work for the asker.
0 kommentar(er)
