I'm not a Linux expert but it seems odd that you are able to run as root when clearly not even root/sudo has access to all of the files in the folder. There must be some sort of problem with at least one of the files in all of the folders that is causing this, but I have no idea what that might be.

One thing you might want to try instead is to simple move the entire .mozilla folder (while Firefox is not running), and then start Firefox. This will force Firefox to create a completely new profile. You could then shut down Firefox again and then manually copy in files from the old profile folder to the new one -- only the stuff that you care about, such as your bookmarks, cookies, passwords etc. This article lists which files you'll want to restore/copy over: Recover important data from an old profile

Hope this helps!

- David

Also, as a diagnostic measure, have you tried giving your profile directory & its children ugo+rw permissions? Maybe it's Firefox trying to drop permissions to nobody?

Try to delete the ~/.mozilla/firefox directory.

Hi David, when you run firefox as sudo or root, it will create a ~root/.mozilla directory. It's not accessing my ~jade/.mozilla when one runs firefox as root (or via sudo). I've verified this by looking at ~root's directory and viewing the contents of ~root/.mozilla. It creates the profile.ini fine in the ~root/.mozilla /firefox directory.

It's just, when I run firefox as a regular user (jade), it's not working. As I noted that I had deleted my ~/.mozilla directory and all its contents thinking that the firefox files were corrupted. I deleted it so that it would generate a new profile. And when I attempt to run firefox, it re-created ~/.mozilla/firefox but won't create the profile.ini with the errors I noted above. I've shown the privs of those newly created directories and there's absolutely no reason why firefox has no access to those directories. I even verified that when I launched firefox that I was the owner (jade) of that pid.

Also, as a diagnostic measure, have you tried giving your profile directory & its children ugo+rw permissions? Maybe it's Firefox trying to drop permissions to nobody?

Yeah, I tried that as well and it made no difference. I even went as far as to give permissions to write/read to everyone of my home directory and still made no difference.

Try to delete the ~/.mozilla/firefox directory.

Hi Cor-el, as I noted in my first post, I deleted my ~/.mozilla and all its subdirectories, thinking something was corrupted in my ~/.mozilla. And after launching firefox, the same exact errors occurred. It'll recreate the ~/.mozilla and its subdirectories but won't recreate ~/.mozilla/firefox/profile.ini with the errors noted in my first post. As I've shown, the permissions is not the problem (despite its complaints).

OK, I think I've solved the problem. What I had suspected is that there was something that was corrupted in my login account. So I created myself a new account and sure enough, firefox works again when logged in under this new account.

Though I have no idea what corrupted the old account (nor what part of the account was corrupted because every thing else seemed to run fine except for firefox), at least now in the new account, I can launch firefox as a user!

Had the same problem today on Ubuntu 10.04 with Firefox nightly build. I tried all of these things too (short of creating a new user). Eventually a ls -alR | grep root showed that permissions on some files in ~ were not being changed. This led me to find the ~/.cache folder which contained a mozilla/firefox folder. chown -R me:me mozilla resolved the issue.

I was having this exact problem. Besides firefox only running if I launch it as root, it would also run just fine in other user accounts.

In addition to this, though, I was experiencing *lots* of crashiness with my gtk apps - the file->open or file->save dialog would often crash, for example, on random apps like chrome, emacs, etc.

Here's what fixed it for me:

sudo update-mime-database /usr/share/mime && rm ~/.local/share/mime/mime.cache

I had a similar issue. The problem was the permissions on /root/.cache The current user has to be able to write to that folder in newer versions, as the cache is no longer keep in the same directory as the rest of the profile. So set it to chmod 777.

As did others, I had this issue and traced it down to root ownership of the user's .cache directory.

What I can add to the information here is that, according to posts in the Mageia development ML, this can occur if you use "su" from the userid rather than "su -l". Since I saw the problem on a newly-installed system, I'm guessing that I used su and ran something that needed .cache and was the first to create it, using the user's home directory rather than root's.