After upgrade, setup wont go away

I followed the steps on how to Upgrade from Wildfire to Openfire using: -openfire-upgrade.html

but now when I try go to admin console it keeps going to the setup pages. That errors out with



Caused by:

     at org.jivesoftware.database.EmbeddedConnectionProvider.destroy(
     at org.jivesoftware.database.DbConnectionManager.setConnectionProvider(

on the embeded database step. From the Spark side everything seems to be working except for the search. I want to know if there is something I can do to get to the admin page to check the search plugin.


So what I am hoping someone could tell me is what file or directory could possibly be deleted so that it will stop going into the setup?


If you ran through the install without a hitch try looking at your

openfire.xml file and make sure the follwing is not set to “False”, it should be near the end of file.


I commented that line out with <!-- and --> and restarted the server, but it still goes into the setup. Is there any more I should delete?

EDIT: My bad I re-read your message and see that it should be in there and it is.

the line in the openfire.xml should read as if you have successfully configured openfire. Are any of your setting parameters showing in the xml file. It may have the wrong permissions on it so that it can not be altered.

Exactly! I just updated my openfire and fired it up. The setup appears and wont go away. Tried to set <setup></setup> in openfire.xml to true/false but nothing happen. I Can’t finish the setup because of the same internal server error. Then i’ve noticed that my openfire.xml has chmod 644, i set them to 777 and fired of up again. Now i am able to login into the admin console without entering the setup. But i am not sure about the chmod 777 - is this really the right way? …


chmod 777 is a very bad idea, please realize a couple of things. Your openfire.xml file is not a script, so it doesn’t need to be executed, so the hack would have been to set 666 permissions. Anyway, that isn’t a good idea either, as any user on your system could potentially edit the file. You need to see which user is running Openfire. This is often found in the /etc/sysconfig/openfire file as OPENFIRE_USER. You can also look at your current running processes and see who owns the openfire process (ps auxw | grep openfire). Then set the ownerships of the file to whoever is running openfire and make the permissions 600, which would be the most secure. Or 664.


Yeah thanks! I know that chmod 777 is a very bad idea, but it was the only way to fire up openfire without entering the setup process! However, before updating i set the file manually to chmod 644 and right after updating i switched back to chmod 664 I only wanted to let the people know how they can get rid of this bug/feature… But youre explanation is a good one and may help some people understand it better!