Telling ML Server where service data location is (again).

Question

Hello,
I've seen this a couple of times and think it's a bug. Maybe somebody knows how to resolve this properly. Mini Server with 10.8.2 and OS X Server v2.2 running, all services configured. Service data is moved via Server->Settings->Service Data to another volume.
The customer moves the physical location of the server, probably forgets to attach the external drive containing the service data on boot. Server starts with other (local) settings rather than what was configured and run already successfully with service data located on external drive.
After stopping all services, setting the service data location to the external drive fails with "Existing Service Data - The volume “Data” already contains service data in /Library/Server. Please delete or move the data and try again, or choose a different volume.".
Yes, we want to use the service data of the external volume. This is desired. How to resolve this?
Alex

Answer 1

Hi,
ran several times into the same problem. Our service data was moved to an external RAID 1 volume and there it should be. For whatsoever reason the volume containing /Library/server was disconnected and upon automatic reconnection (or restart) the server could not find the service data again and therefore the osx server set the default location of service data to boot volume/Library/Server... I thought I was about to go mad... How to point the server to correct service data manually. It seemed there was no option to do this in ML OS X server. So being almost hopeless, I renamed the original service data folder on RAID 1 volume to /Library/Server_old. In the menawhile i noticed that although Finder showed correctly mounted RAID 1 volume with the initial name ("Pool") in fact in /Volumes there were /Volumes/Pool and /Volumes/Pool1 which pointed to the RAID server. Ridiculous. The OSX mounted the RAID 1 volume incorrectly or the server tried to save some sort of service data BEFORE the server data RAID 1 volume was at least mounted correctly and thus created a directory named /Volmes/Pool that fooled the server completely and corrupted it as it could not found any correct service data on /Volumes/Pool... Googling around showed that the problematic service might be Messages "_jabber". So In Server.app turn off every service available and quit. In disc tool eject the external volume containing real service data. Then in terminal delete recursively the undesired "ghost" folder ( /Volumes/Pool in my case). Pay attention not to delete the real volume containing the service data! Then again mount the external volume with the service data. Check in terminal that it was mounted correctly in /Volumes. In the meanitme act quickly. I needed to delete the gost folder several times until there was not any ghost folder anymore before mounting the true service data external volume. It is difficult to completely shut down all the server services that access service data although the Server.app shows everything offline. Then launch server.app again move the almost empty default service location to the real external Volume already mounted correctly. Now comes the brute part. On the external volume delete in terminal recursively the /Library/Server and rename the backup /Library/Sever_old to back to /Library/Server. I prayed it would work at that point. And upon restart it did work. Good luck!