Trying to install 73.0 Beta 11 but keeps failing with "patch apply failed." I think this is a workstation permissions issue but I need more info...
I'm currently on 73.0b5 (64-bit) on Windows 10. I'm trying to use the "Update to 73.0 Beta 11" button from the "About" screen to update the browser. This normally works but today, it's having problems and I suspect it's due to our corporate policies being changed around.
I'm going to submit a request to our enterprise idiot to have this fixed in their whitelists, etc. but before I can do that, I need to know what kinds of permissions to request. What's responsible for the update process and what folders need to have which permissions for this to work?
Because right now, pressing the "Update to 73.0 Beta 11" button results in Firefox downloading the update but when it tries to install it, it fails with the "Update failed. Download the latest version" message in the "About" screen (when it was working last week without a single hitch).
According to my about:support details, I'm seeing the following:
- Update Folder: C:\ProgramData\Mozilla\updates\<Long String> - Application Binary: C:\Program Files\Firefox Developer Edition\firefox.exe - Profile Folder: C:\Users\<my username>\AppData\Roaming\Mozilla\Firefox\Profiles\<string>.dev-edition-default - Antivirus, Antispyware, and Firewall are all governed by McAfee Endpoint Security (which hasn't been an issue in the past).
I suspect that all of this is due to our enterprise guys modifying the permissions that our "elevated permissions" has... So once I have a better understanding of what things need which permissions, I'll be able to request that the elevated permissions be modified accordingly.
Any insight into this would be appreciated. It's a shame we don't have logs that clearly explain what folders or files lack whatever permissions to better understand bottlenecks like this. Maybe we do have that and I'm just not aware of it?
All Replies (1)
hi, when you go to the update folder that's indicated in about:support and take a look in the /update-subdirectory there you might find log files there that contain more information about where the update process is going wrong.