I'm running Firefox 41.0.1 (stable channel) on Mac OSX 10.10.5 on a macbook pro (mid-2014). Firefox cannot upgrade to version 42. When I restart it, it just shows a messagebox saying the upgrade "failed". This persists after a reboot. I discussed this with Anthony on https://bugzilla.mozilla.org/show_bug.cgi?id=1225610#c2 and here is the log from app.update.log in the Browser Console: Could not read chrome manifest 'file:///Applications/Firefox.app/Contents/Resources/chrome.manifest'. UTM:SVC TimerManager:registerTimer - id: xpi-signature-verification AUS:SVC Creating UpdateService AUS:SVC gCanCheckForUpdates - able to check for updates AUS:SVC getCanApplyUpdates - testing write access /Users/benoitjacob/Library/Caches/Mozilla/updates/Applications/Firefox/update.test AUS:SVC getCanApplyUpdates - testing write access /Applications/Firefox.app/Contents/MacOS/update.test AUS:SVC getCanApplyUpdates - able to apply updates AUS:SVC readStatusFile - status: failed: 7, path: /Users/benoitjacob/Library/Caches/Mozilla/updates/Applications/Firefox/updates/0/update.status
$ cat /Users/benoitjacob/Library/Caches/Mozilla/updates/Applications/Firefox/updates/0/update.status pending
I removed this update.status file, this caused the upgrade to be re-downloaded, but it still failed in the same way.
Tried the "Refresh Firefox..." button in about:support. Still same problem.
Could you check the ownership and permissions of the Firefox .app bundle (ls -al on the directory where the bundle is located)? Is your user account the owner of the bundle and do you have write access? It could also be that one of the files inside the bundle has an incorrect ownership or permissions. Files in Contents/MacOS or Contents/Resources come to mind.
Is it possible that you ran Firefox as root at some point (from an elevated Terminal for example)? It looks like Contents/Resources/browser is owned by root, which could happen if Firefox previously updated when it was running as root. Correcting the ownership there (and everywhere else where a file is owned by root) should fix this. We are working on elevated updates in bug 394984, but detecting this particular scenario would require additional work.
So, 'browser' belonging to root:wheel is possibly the problem? This is a corporate machine and we have a "managed software centre" that seems to have taken ownership of my Firefox installation... It could be, then, that the only thing you could do on your end, is better diagnostics.
Is it more likely that "managed software centre" has taken ownership of the Firefox installation than the possibility that Firefox was run as root at some point? If that's the case, I'm wondering why "managed software centre" didn't update Firefox yet. We could (and probably should) improve our permissions check, as this would also come handy when we're trying to detect when an update requires elevation in bug 394984. Robert, what are your thoughts on improving the "canApply" check to recursively check the permissions on the files in the bundle instead of creating the update.test file in the root of the bundle?
I certainly don't remember running Firefox as root. And today I went in that "managed software centre" and did update Firefox; it just seems that it doesn't auto-update software without user interaction. I'd close my bug as INVALID at this point, but please do so at your convenience as you're still discussing other things in Comment 8 (thanks for considering this issue, btw).
(In reply to Benoit Jacob [:bjacob] (mostly away) from comment #9) > I'd close my bug as INVALID at this point, but please do so at your > convenience as you're still discussing other things in Comment 8 (thanks for > considering this issue, btw). Thanks, Benoit. You may also want to make your corporation aware of this issue with the "managed software centre" handling Firefox. It's certainly not obvious.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
3 years ago
You need to log in before you can comment on or make changes to this bug.