Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Open Directory - Local Network User/Group - GONE

This morning everything seemed to be working normally, then an email couldn't be sent through my local server. Kept asking me to sign in. Eventually tracked it down to Open Directory playing up. In Server.app, the 'Local Network' option for both Users and Groups was empty. After a restart of the server (and half a dozen more since) there is no longer any pop-up in Users or Groups at all. There's just the list of locals and that's all.


Trying to look into this with either WorkGroup Manager or Directory utility just results in an error, so looks like OD has comprehensively shot itself in the foot, all by itself. Nothing has been done to the server for weeks, this is entirely of its own doing.


Admittedly there's not many Users and/or Groups to re-create, but at the moment I can't even do that as it doesn't even know there's an LDAP directory to add them to. So looks like I'll have to destroy the entire OD setup and start again from scratch. Just what I wanted to do this weekend. Thanks Apple.


Anyone got any info on how Server.app manages to do this and what can be done to fix it and hopefully stop it from occurring again?

Posted on Dec 14, 2013 6:04 AM

Reply
Question marked as Best reply

Posted on Dec 14, 2013 8:50 AM

While I don't have a magic bullet to solve your problem, I can suggest reviewing your logs. OS X does a rather decent job of recording events and something like the corruption and loss of an Open Directory master is likely recorded somewhere. While discovering this moment and possible cause may not result in the ability to fix the issue, it will at least provide some closure to why it happened and when.


Next, it is best practice to backup your Open Directory regardless of how small or large it is. LDAP can be a finicky technology and many things can cause it to flake out. If you were backing up your OD on a regular basis, you would likely be able to simply restore from a backup and everything would be back in place.


The importance of a backup can not be dismissed. Accounts in OS X are backed by GUID values and these can be very difficult to nearly impossible to rebuild in the event of a rebuild of the server. Many of the services in OS X will define access based on the accounts GUID value. If your OD blows up and you simply recreate new accounts, you end up with all new GUID values for the accounts. This can make linking users to data a challenging ordeal.


Now, LDAP does have some tools to attempt to repair an Open Directory database. This has historically not worked well in my experiences. However, you can research the db_recover tool. Generally sudo db_recover -v -h /var/db/openldap/openldap-data/ Research before attempting. Once you are back up and running, make sure you have a backup plan in place.


R-

Apple Consultants Network

Apple Professional Services

Author "Mavericks Server – Foundation Services" :: Exclusively available in Apple iBooks Store

20 replies

Dec 31, 2013 4:36 AM in response to Cookiefan

Sadly, when db_recover does not work, there is not many other options other than a demotion to standalone and then a promotion back to an OD master. This is why a backup of the OD data is so important. I see you've seen some of my other comments. I tend to use the expression trust but verify. With many of Apple's services, I want to trust that they will work, but I tend to verify but adding additional layers of backup. Time Machine is supposed to provide backups, but I tend to manually export an OD archive anyway. This makes me feel safer and I can verify the function of the backup with greater ease.


Now, I know this is a lot of "I told you so" advice. With luck you have a backup that will work as expected. However, it is possible that you will simply never be able to stitch all the pieces back together.


The only other suggestion I have is to look in Console to see if there is any logging information giving you more information on what is preventing the service from starting. You can also place directory services into debug logging. This tends to provide a lot of information and parsing it your first time can be daunting.


R-

Apple Consultants Network

Apple Professional Services

Author "Mavericks Server – Foundation Services" :: Exclusively available in the Apple iBooks Store

Jan 1, 2014 10:31 AM in response to Strontium90

Thanks Strontium90.


Unfortunately, I am even unable to recreate a OD master, as the service refuses to start ! I am also unable to add any user, even local.


Here is the log errors I have.


Dec 29 17:49:38 PasswordService[4778]: -[PasswordServerPrefsObject getSearchBase]: Unable to locate search base: -1 Can't contact LDAP server

Dec 29 17:49:38 PasswordService[4778]: -[PasswordServerPrefsObject loadXMLData]: Unable to locate passwordserver config record's plist attribute: -1 Can't contact LDAP server

Dec 29 17:49:38 PasswordService[4778]: -[PasswordServerPrefsObject getSearchBase]: Unable to locate search base: -1 Can't contact LDAP server

Dec 29 17:49:38 cookie.merkt.li PasswordService[4778]: -[PasswordServerPrefsObject saveXMLData]: ldap_modify_ext_s of the passwordserver config record's plist attribute: -1 Can't contact LDAP server

Dec 29 17:49:39 com.apple.launchd[1] (org.openldap.slapd[4774]): Exited with code: 1

Dec 29 17:49:39 com.apple.launchd[1] (org.openldap.slapd): Throttling respawn: Will start in 7 seconds

Dec 29 17:49:39 PasswordService[4778]: int pwsf_GetPublicKey(char *): ldap_search_ext_s cn=authdata for Public Key returned -1

Dec 29 17:49:39 com.apple.launchd[1] (com.apple.PasswordService[4778]): Exited with code: 1

Dec 29 17:49:39 com.apple.launchd[1] (com.apple.PasswordService): Throttling respawn: Will start in 9 seconds

Jan 1, 2014 4:39 PM in response to Cookiefan

Funny how these things are contagious. I just dealt with this yesterday and today. Conditions are very similar. Customer rebooted the server and smack... OD fails to start. Errors galore in system.log. No users.


Luckily, I make backups of the OD infrastructure. So I used the following to recover:


1: Destroy the corrupted OD master. WARNING!!!!! YOU ARE DELETING ALL USERS, GROUP, GUIDs, etc. Proceed only if you know you can recover cleanly. If you understand, use this command:


sudo slapconfig -destroyldapserver


Server.app is not showing OD as started so you really can't stop and clean up using the UI.


This will restore the machine to stand-alone status. Once this is complete, your system.log should quiet down. Now you can recreate or restore your OD master.

Jan 1, 2014 5:25 PM in response to Strontium90

Thanks so much for your help!


I have done it.


And now shall I recreate everything again and try to import the data (iCal mostly). If yes, how can I attach the data with the new UID?


Or shall I use my Time Machine saves.


Or the archive I had of the OD, but dated November 6, 2013 ?


Thank you for your useful advices. Beginning to see the light!

Jan 2, 2014 1:05 AM in response to Strontium90

Strontium90 wrote:


Funny how these things are contagious. I just dealt with this yesterday and today. Conditions are very similar. Customer rebooted the server and smack... OD fails to start. Errors galore in system.log. No users.

I'm not sure funny is the right word. 😀


There is obviously something seriously wrong with Mavericks Server in the OD department (and others). No wonder Apple dropped the XServe. There's NO way they can pretend this is enterprise quality software.


I had another issue yesterday on both my Mac Pro and MacBook Pro. The former turned out to be minor symptoms cured by a forced restart of Finder, but I suspect it was OD related. The latter was definitley OD, but at the client end as the server was still looking OK, however the MacBook simply couldn't see it and I had the same error as Cookiefan. Directory Utility just couldn't connect to the Server, although the Mac Pro was connected to it perfectly well. I restarted the MacBook and now it's connected OK.


This is hopeless. Software that requires a restart of the entire machine just to work correctly as it should is not something that a giant like Apple should be throwing out and indicates to me they really are lacking the skills they should have. Unfortunately it is becoming more and more common. I remember when the very first OSX took us to unix levels of robustness. It's taken Apple about 10 years to degrade it almost to the fragility of MacOS 9 and earlier systems.


Joking aside, every new version of OSX intoduces more bling and less stability - a worrying trend that probably needs Steve Jobs to fix. 😟

Open Directory - Local Network User/Group - GONE

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.