Currently Being ModeratedApr 30, 2013 1:08 PM (in response to Alex33)
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!
Currently Being ModeratedJun 24, 2013 7:27 AM (in response to Dfundy)
Thank you very much for your suggestion! This pretty much worked for me. The only strange thing is that when I do an ls -al in /Volumes, the "ghost", which in my case was "Data 1" shows up again. I can rm -r and delete it, only for it to pop up again. Any ideas? My guess is some other service is still trying to use the wrong service data location, but I can't figure out what. All I am running is File Sharing, NetInstall (whose service data location is defined separately) and Software Update.
Currently Being ModeratedJun 24, 2013 11:59 AM (in response to visonep)
Maybe check the content of the /Library/Server on the "ghost" volume to see what service tried to write data there. In my case it was "Messages" _jabber. it may however be other service as well. Then google how to shut it down. It's pitty that you can't just shut down all services in one step in server.app
Currently Being ModeratedJun 24, 2013 12:51 PM (in response to Dfundy)
Thanks for the reply. I was able to check the contents of the /Library/Server of the ghost volume and it was indeed pointing to settings for _jabber. I don't know why it was trying to save settings for jabber/messages because I don't even have them enabled! Anyway, I ended up running the command:
sudo serveradmin settings jabber
Here I was able to verify which setting was being pointed to the ghost volume. In my case it was message_archives and jabberd2.db. I changed the path by running the following command:
sudo serveradmin settings jabber:jabberdDatabasePath = "/path/to/correct/location"
That pretty much did the trick. Thanks again! Pat