I’m right – it seems to be permissions. The console log is filling up with this:
9/6/09 5:58:03 PM com.apple.launchd[1] (org.jivesoftware.openfire[1925]) posix_spawn("/usr/local/openfire/bin/extra/openfire-launchd-wrapper.sh", …): Permission denied
looks like that might be the problem to begin with… the permission should be 754. Change it and give it a try.
BTW - I can cd into the /usr/local/ but not into /usr/local/openfire. That is the way it should be.
You are in the group staff (probably) and /usr/local/xxxx/ is in the group admin or something else, so there is no way you can cd into it. That is the way it should be.
Progress. A bit ago I found a discussion on Apple’s forums about essentially the same thing. Someone had something they used to be able to run in /usr/local that they now couldn’t because of the perms on the directory. So apparently I’m not alone here…
Anyway, before I saw your suggestion I went with 755 on /usr/local. That helped; Openfire would start on reboot but the Pref pane still didn’t work (i.e. I couldn’t toggle Openfire on or off nor set it to start automatically). That was with Openfire already installed; so my next step is to get rid of it again and reinstall with the permissions set correctly on /usr/local and see where I get.
Give that a shot. I still think it needs to be 754 to ensure security. I’ve attached my entire directory structure with permissions for you reference. hope that helps.
openfire_dir_permissions.txt.zip (5338 Bytes)
I re-read your post again. you say “Openfire would start on reboot”. did it start automatically on startup? If it is why worry about the pref pane? I rarely use that if ever.
I know; I guess I just like to have everything hang together properly. Also, I wasn’t completely sure it was running properly. After I configured the admin account, the server wouldn’t let me turn around and log in with the account I had just set up.
Anyway, this whole thing is bizarre. I set the permissions to 754 as you suggested (I agree), but then I couldn’t browse /usr/local anymore. Weird! So I put 'em back to 755 and reinstalled Openfire. Success this time – it runs and the pref pane works.
Thought I was stuck on the admin account again as it still wouldn’t let me log in, but I restarted the server and that fixed that. I seem to be good to go now, weird permissions and all.
Thanks very much for your help getting this working – I really appreciate it!
cmontyburns wrote:
After I configured the admin account, the server wouldn’t let me turn around and log in with the account I had just set up.
There is a bug in 3.6.4, which prevents you from logging in right after the last step of the setup. You have to restart Openfire.
Thanks for the information. I did determine the restart part but hadn’t thought to check if it were a bug. Guess I won’t submit it.
I tried this but get an error Permission denied. I have tried the other suggestions with no luck at all. Any ideas? Thanks and regards
My knowledge is limited how to change permissions 754? 755? thanks and regards
In terminal type either one of the commands below at the prompt:
“chmod 754 <directory_name>” (as root) OR
“sudo chmod 754 <directory_name>” (as yourself but then you will need to provide the root password when prompted)
You can also type “man chmod” for info. Hope that helps.
Akaran
Thank you so much. Finally went with
sudo chmod 755 /usr/local/
and openfire is up and runnig. I am smiling. From what I read
“chmod 755 means read and execute access for everyone and also write access for the owner of the file. When you perform **chmod 755 filename** command you allow everyone to read and execute the file, owner is allowed to write to the file as well.”
Will this chmod 755 affect in any way any other application or system feature? Is there any risk when changing access attributes?
Thanks and Regards
Will this chmod 755 affect in any way any other application or system feature?
My guess is no, but if there were files in there that needed “write” permission for the “group” or “everyone” then that could affect an application or system feature i.e. if there were files under the /usr/local/ tree that had 77x or 777 permission you potentially have changed it. Tough to say if that is an issue at all, but that is one scenario I can think of.
Is there any risk when changing access attributes?
Again there is slim chance that if a hacker or malicious software gets access to your machine now they/it can access and execute program under the /usr/local/ tree.
i registred all the way through here just to say, i’m sorry but Crap0la
it just doesn’t work
-
you have to change the system permissions (not just openfire dir but also /usr/local/ itself too )
-
prefpanes doesn’t work (doesn’t accept user click, display error msg)
when you finaly get the prefpane to accept commands,it doesn’t work all the time (sometimes i need to
press the button “start the server” 3 or 4 time until it finally decide to start)
-
login in the browser based admin console doesn’t work either (here too need to mess with terminal and system permissions)
-
once you finaly get the prefpane to accept user input, once you finally get the server to start, and finally be able to access the admin console
and configure it all: in ichat sometime it works sometimes it doesn’t …
i explain myself, i got it working once, and after a while i rebooted the system, and then after the reboot it wouldn’t work anymore (don’t remember the exact output but ichat said couldn’t use openfire … just displaying error message "cannot connect) …
so i tryed to install and set it all up Again, and now i get ichat to say: "msn.localhost: (null) …
this despite in admin console "test connection reports ok.
finaly,
… it doesn’t come with an uninstall option, you have to clean the mess by hand (there again terminal)
its flakey at best … it feels like a dev alpha test build.
i hope next version will address the problems.
all this for that shitty msn protocol i need to use to communicate with my "micro$oft lover zombie co-workers
i didn’t mean to just bash and criticize, i wanted to report my experience so maybe it can help avoiding thoses problems in next versions.
so this is what i got, trying openfire. tnx for listening.
fully agree with you…
I have been trying to install it and get it running fine on my OS X computer… (Snow Leopard)
everything ‘seems’ to be fine… but cannot/stop it in PrefPane and once I get into the Admin page, the ‘admin’ authentification is denied (credentials are good) I tried 5 times to re-install , I modified the permissions… same issue
I’ll give a try on my Linux/Debian server later… I thought OS X install & setup would run faster
unfortunatly not !
[UPDATE]
I installed it now on my Debian server, it’s fully operational… easy install no access right issue
so OS X install script must be checked …