Firefox user.js and profile remain inaccessible with “Access denied” even as Administrator, and Firefox Refresh does not fix it
I am having an unusual problem with my main Firefox profile on Windows 10. The affected profile is:
C:\Users\Adam\AppData\Roaming\Mozilla\Firefox\Profiles\2giwv8i8.default-release-1746901618396
Firefox reports that this profile contains a user.js file. I cannot read, rename, move, modify or delete this user.js, even from an elevated Administrator CMD or PowerShell session. Attempts return “Access is denied.”
The unusual part is that Windows permissions appear correct. icacls shows my user account, SYSTEM and Administrators all have Full Control. The file is not encrypted, is not read-only, is not a reparse point, and Firefox is completely closed when I test it.
I also tested writing a new file directly into this Firefox profile directory and receive Access Denied. Other older Firefox profile directories on the same NTFS drive are writable, so the behaviour appears specific to certain Firefox profiles.
I have already performed a Firefox Refresh/reset, but the problem remains and user.js is still present.
I am investigating this because I am also experiencing unusual behaviour specifically with this main Firefox profile when using YouTube. Other Firefox profiles do not reproduce the same behaviour. I therefore want to completely eliminate any persistent profile configuration as a cause.
Can someone explain:
What could prevent access to an entire Firefox profile despite NTFS ACLs showing Full Control? Can Firefox, Firefox Sync, Enterprise Policies, an extension, or another Firefox mechanism protect or recreate user.js? Why would Firefox Refresh leave or recreate user.js? Is there an official/safe way to identify which preferences are being loaded from user.js when Windows itself refuses access to the file? Is there a way to reset all non-default preferences in this profile without losing bookmarks and saved passwords?
I can provide about:support, about:config, profiles.ini, ACL output and other diagnostics if required.
I would particularly appreciate advice on diagnosing why the profile directory itself returns Access Denied despite Full Control, rather than simply creating another profile, because I would like to identify the underlying cause.
Всички отговори (2)
No. Firefox cannot prevent Windows Administrator or SYSTEM accounts from reading, renaming, or deleting files when the browser is closed.
Could you clarify a few details about your system?
- Is this a personal PC or a domain-managed machine?
- Is Windows Roaming User Profiles or Offline Files enabled?
- Does the issue persist in Windows Safe Mode?
Thanks. I checked those points.
This is a personal Windows 10 PC and is not domain managed:
PartOfDomain : False Domain : WORKGROUP UserName : Adam
Windows Offline Files also does not appear to be active. CscService reports:
Status : Stopped StartType : Disabled
I have not yet performed the Windows Safe Mode test. That will be my next test.
One additional detail that may be relevant: fltmc shows the ESET eamonm filesystem minifilter attached to C:. However, ESET itself shows no logged event corresponding to the access denial.
In normal Windows, the affected Firefox profile remains inaccessible even after Firefox is completely terminated. Other Firefox profiles on the same NTFS volume are writable.
I will test the exact affected profile in Windows Safe Mode and report whether I can:
read user.js; create a test file in the profile directory; rename/copy user.js.
If all three operations work in Safe Mode, would that point toward a third-party filesystem filter/service rather than Firefox?
You must log in to your account to reply to posts. Please start a new question, if you do not have an account yet.