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

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!

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.

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

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

Hi Dfundy, sorry for the reply after 1 year. But last night I ran in a similar situation (https://discussions.apple.com/thread/6110379?answerId=25533393022#25533393022). The initial cause is a little bit different, but appearantly (the volume renaming) had the same bizar effect. And now being completely stressed out, not sleeping and having googled the Web heavily, I finally stumbled upon your case. And reading this all, the solution does make sense. However, before I try this too, I do have two questions. Just to make sure I understand it well and not messing things up more. Would you be so kind as to reply to this?

- Why not rename the ghost volume or does this help? Because I did rename the ghost volume, and in Terminal I could see that this showed up with the new name. From then on I could dismount/mount the original volume again. Wouldn't this avoid the hassle and perhaps the mistake for deleting the wrong volume?

- From what I understand in your last sentences (after finally rmoving the ghost volume), you say (if I understood correctly):

1. Restart Server.app

2. Change/Edit the Services Data to the original volume again (with the "Library/Server" on the original volume already renamed to "Library/Server_old"

3. Then (in Terminal) remove the now newly created "Library/Server" recursively (on the original volume)

4. Finally (in Terminal), on the original volume, rename "Library/Server_old" to "Library/Server"

5. Reboot.

Did I understand it correctly?

many thanks in advance,

Tanya

Ok, I actually just did change all the 'deleting' into 'renaming' and such. And it all worked just fine. See my thread https://discussions.apple.com/thread/6110379?answerId=25536566022#25536566022 too. So thanks for the whole thread. It helped me BIG TIME 😉

thanks, thanks, thanks,

Tanya

You're welcome Tanya. Good to hear that renaming the ghost volume works just fine. Initially I was sort of afraid to rename the folders with automounted volumes. I coud not imagine how the system might react.

Regards

D.