FF refuses to start with that message: No running windows found Error launching firefox: There are files in your profile that are owned by a user other than nekrad. firefox can't execute in this condition. Here are some of the files that I found: /home/nekrad/.mozilla/firefox /home/nekrad/.mozilla/firefox/k5eu0o2p.default /home/nekrad/.mozilla/firefox/k5eu0o2p.default/extensions /home/nekrad/.mozilla/firefox/k5eu0o2p.default/bookmarkbackups /home/nekrad/.mozilla/firefox/k5eu0o2p.default/secmod.db /home/nekrad/.mozilla/firefox/k5eu0o2p.default/Cache /home/nekrad/.mozilla/firefox/k5eu0o2p.default/hostperm.1 /home/nekrad/.mozilla/firefox/k5eu0o2p.default/extensions.ini /home/nekrad/.mozilla/firefox/k5eu0o2p.default/localstore.rdf /home/nekrad/.mozilla/firefox/k5eu0o2p.default/signons2.txt ... The listed files are symlinks to the correct files. I *need* it to move off these temporary files from my coda filesystem to get moz illa starting up in an reasonable time. Seamonkey works quite fine that way, but firefox has an silly and useless "test" which fails and refuses any operation. I was not yet able to find the source of that crash, otherwise I already would have kicked off the whole code. Until that bug is fixed, FF is totally unusable for me. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=383273 Reproducible: Always
As you've been told upstream, you should run firefox -P, create a new profile and "select choose folder and select a path to some other file system" [1], not to produce symlinks there... [1] https://bugzilla.mozilla.org/show_bug.cgi?id=383273#c1 Reopen if the above doesn't work for you.
Created attachment 121223 [details, diff] kicks off the broken permission checks
(In reply to comment #1) > As you've been told upstream, you should run firefox -P, create a new profile > and "select choose folder and select a path to some other file system" [1], not > to produce symlinks there... You didn't read carefully and so totally missed the point. As usual. BTW: I've fixed it in my (oss-qm) overlay - works fine.
Funny. "I dont eat what I dont know" or better "what I dont understand is invalid". Just as I though, certain people had their lessons. Obviously not. Not my problem anymore if gentoo ships broken software. I've done my part and fixed it. If you keep your eyes closed, you will (sooner or later) crash against the wall, not me. Not the slightest interest in my contributions, so closing the bug.
I have certainly *no* clue regarding mozilla/firefox, how it works, etc. I just would apply the patch and bump the ebuild, but i'm not in the respective mozilla herd either. Although, maybe the alias didn't get its way into the CC, so I just want to check.
(In reply to comment #5) > I have certainly *no* clue regarding mozilla/firefox, how it works, etc. I just > would apply the patch and bump the ebuild, but i'm not in the respective > mozilla herd either. The patch is wrong; the permissions check is valid and needed, because FF makes kaboom on screwed profile permissions. If you want to fix it properly, then fix it to check the permissions on the real files instead of symlinks (plus as said above, you shouldn't symlink anything there, you should point the profile to a proper location).
(In reply to comment #6) > The patch is wrong; the permissions check is valid and needed, because FF > makes kaboom on screwed profile permissions. Ah, and it's needed to refuse starting, just if it *thinks* that something *may* be wrong ? Well, I really could live with an (uninterruptive) warning. But could you live with that ? > If you want to fix it properly, then fix it to check the permissions > on the real files instead of symlinks The symlinks are not the only problem. Checking just the file mode and ownership is not enough in ACL environments. (I hope you know what ACLs are ...) > (plus as said above, you shouldn't symlink anything there, > you should point the profile to a proper location). Ah, funny how much you seem to know about my environment and its requirements ... Did I alreay mention that FF itself works good with symlinks ? Again, we're at the point where you're dropping my bug reports because you don't like me, or environments one step beside the maintream or of any other silly reason. I'll tell you a secret: whether you accept my bugs is totally irrelevant to me. I've done my part: reported the problem, solved it (or at least gave an workaround) and informed the user maillist about that. That's all.
Enrico, kindly take your rants to /dev/null, they don't belong to bugzilla. Randomly commenting out a part of script you dislike because you simply refuse to create your profile properly is no fix.
first, bugzilla is no place for personal, please be more politely. although, we most probabely all know what ACLs are, so if it's new to someone, that one doesn't need to expect that he's the center of the universe, assuming, that everyone else might need a teaching, too. Enrico, that you're using symlinks, and that jakub knows about just relies on the fact, that we *do* read patches being submitted. And lastly, I do believe, that this is more an upstream bug than distribution dependant, as you'd most probabely and definitely will encounter the very same problem on other distros aswell (that didn't fix it for their own w/o forwarding their patch to upstream). One basic policy for every developer @ gentoo is to keep the ebuild packages as close to upstream as possible, if we find a bug, are able to fix it (or get a fix by a user, just like you), we're highly encouraged to submit the fix to upstream (that is: mozilla.org) as soon as possible, or let the originating author (in this case: you) do it. So far, Christian Parpart.
(In reply to comment #9) > And lastly, I do believe, that this is more an upstream bug than distribution > dependant, as you'd most probabely and definitely will encounter the very same > problem on other distros aswell (that didn't fix it for their own w/o > forwarding their patch to upstream). No, it clearly is not. The upstream has nothing to do with it. The problem comes from the "mozilla-launcher" package, which is an Gentoo invention. I didn't count how often I already said it, but I'll repeat it again: FF works great with symlinks and ACLs. The problem comes from mozilla-laucher's additionally "sanity checks" which totally fail here. Ok, my patch is an very quick and dirty solution, it simply drops this check. Several ideas were posted, so why don't we talk about that ? But the bug is still declared invalid, which doesn't mean anything else than, there was no problem. Obviously no discussion is wanted, closing the eyes and ranting against people reporting such things (as me) is preferred. I'm not upset about that there's a bug. Bugs are vey natural. But: I'm really, really upset about my bugs declared invalid per default. > One basic policy for every developer @ gentoo is to keep the ebuild packages > as close to upstream as possible, Yes, I know about that and I understand why. I think its good this way. But, BTW, I don't agree on the large amount of dirty workarounds which live that long time (ie. slots, installation magic in ebuilds, etc, etc). I'd prefer putting broken packages aside for a while, joining the upstream and solve the problems there. Gentoo really isn't the only distro doing that mistake - in fact most are doing so. Okay, that really gets offtopic - we should discuss these things on the maillists. To get back ontopic: What will now happen to this issue ? Any further works on it or will it still be declared invalid. I have to decide whether it's worth investing any further second on this issue or just a waste of time.
OK, now I feel better posting here. I do agree with Enrico that the check is the wrong approach. not for symlinks or similar, but for general reasons. #1: Nothing says that only the user whom the files belong to can technically edit/create/delete them. ACLs are one thing, but there are numerous other things, e.g. filesystem w/o elaborated permission schemes, NFS, various other issues. OTOH, the owner might be prevented from editing/creating/whatsoever even if he's the owner (think of system capabilities). All of that might happen. #2: The reference in mozilla-launcher to a bug seems to have nothing to do with that check. This is why I would agree that the check should be dumped all together. Also, it is much more Gentoo'ish to let the user shoot himself in his foot rather than doing lots of sanity checks. A reason against might be that firefox is so popular that idiots will come in masses, shoot themselves in their foot (e.g. by extensively using the root account to surf the internet w/o a proper HOME env var) and come here and complain in similar terms as can be read above (my condolences, jakub). However, technically, the check is invalid. In that case, the least common denominator would probably just be to change that "find" call in mozilla-launcher to use the "-L" switch. I'll create a one-line patch and attach it to illustrate the case. In this case, the check properly takes symlinks into account. The whole package is Gentoo-only (i.e. there's no uzpstream). It's maintained by agriffis. I hesitated to put him into CC, but maybe that should be done.
Created attachment 121492 [details, diff] Properly takes symlinks into account -- but is still technically wrong
