53

Yesterday I installed Windows 8 and am now trying to understand why I am getting an "Access Denied" message when accessing localstorage. The page is being served on the same PC with the browser (http://localhost). My feeling is that one of the security settings in IE 10 is wrong, but I haven't figured out which one.

The line of JavaScript code triggering the error is:

if(window.localStorage.getItem('phone') == null)

The code works fine in the latest version of Chrome.

MrCode
  • 63,975
  • 10
  • 90
  • 112
Clint Brown
  • 629
  • 1
  • 6
  • 12
  • Can't repeat, works just fine here. Could you try to get a demo working at [jsfiddle](http://jsfiddle.net)? – Joachim Isaksson Oct 27 '12 at 16:59
  • I have the feeling it may have worked for you due to different security settings? I'm going to try fiddling with mine a little more before I work up a demo. If your settings are different, then it's likely the demo will work for you also. If I discover the answer I'll post it. – Clint Brown Oct 27 '12 at 17:45
  • I've got things narrowed down a little. When I use the F12 Developer Tools on http://localhost, entering a watch for window.localStorage issues an Access Denied error. Doing that on a publicly available website (microsoft.com) shows a Storage Object. So it's likely that a demo on jsfiddle won't work because that's a public site. I'm going to try fishing around in the IE10 security settings between Internet and Local Intranet to see if that catches what's different. – Clint Brown Oct 27 '12 at 18:02
  • 2
    I've noticed that window.localStorage issues the Access Denied error but that window.sessionStorage does not. In this case I should have been using sessionStorage anyway, so I'm going to retrofit the application. However, it would still be nice to understand what's happening. The code worked fine in Win7/IE9. – Clint Brown Oct 27 '12 at 18:31
  • I'm running the code you provided from localhost, and it works well. The computer I'm using is a default installed Win8 (non domain connected) with IE pretty much just started, not tweaked. Are you in a domain that adds security settings to your computer? – Joachim Isaksson Oct 27 '12 at 18:59
  • Not to be nitpicking, but I believe this question belongs on Superuser, since your question isn't really code related. If you had searched SuperUser, you might have found my [question](http://superuser.com/questions/509712/logging-into-stackexchange-sites-with-google-not-working-on-ie10/511952#511952) with a similar problem. Just saying ;) – programstinator Nov 28 '12 at 18:30
  • 2
    I wasn't aware of the SuperUser site. Looks like a nice tool to add to the toolkit. I did realize that the original question was more user oriented than code oriented, but the problem was happening due to code I had written. By that line of reasoning I thought someone else coding the same thing might look on StackOverflow also. – Clint Brown Nov 30 '12 at 02:49
  • I can also repro this on win8 enterprise, domain connected, x64 workstation. – x0n Apr 17 '13 at 00:50

8 Answers8

78

Our users were having issues with web sites using the LocalStorage feature (including Twitter) on Windows 8 with IE 10. When accessing one of these sites with the F12 Developer Tools open, a SCRIPT5: Access is denied message appeared on the console.

After working with Microsoft support, we identified the cause. It turned out to be a problem with the settings on the C:\Users\username\Appdata\LocalLow folder in their user profile.

Each folder on your computer has an integrity setting. More information about the purpose of this setting is here: http://msdn.microsoft.com/en-us/library/bb625964.aspx

The integrity setting on the AppData\LocalLow folder (and its subfolders) in each user's profile is supposed to be set to "Low" (hence the name). In our case, the integrity level was not set correctly on this folder. To rectify the problem, run the following command in a command prompt window:

icacls %userprofile%\Appdata\LocalLow /t /setintegritylevel (OI)(CI)L

(If there is more than one user account on the computer and the other users are having the same issue, the command needs to be run under each affected user's account.)

As for how this setting got changed in the first place? In our case, it was caused by a problem in the customized Windows 8 image we deployed to our workstations. For others that are having the issue, my research has revealed that the use of a "system cleaner" utility may be to blame.

Tweek
  • 895
  • 6
  • 7
  • 5
    Make sure you close IE before running ICALS – Eric Labashosky Nov 21 '14 at 16:37
  • 9
    If instead you want to reproduce the bug, run `icacls %userprofile%\Appdata\LocalLow /t /setintegritylevel (OI)(CI)H`. The H sets the integrity mode to "high" (whatever that means) and then IE will be anal about localStorage. – skrebbel Jun 11 '15 at 15:28
  • 3
    To reproduce, like @skrebbel suggests, run the CMD as administrator. (start > search "cmd" > right click > run as administrator > `icacls %userprofile%\Appdata\LocalLow /t /setintegritylevel (OI)(CI)H`) – Simon Epskamp Apr 26 '16 at 13:08
  • Great topic! I think you might find this link interesting too. The problem is not only in IE11 https://answers.microsoft.com/en-us/ie/forum/ie10-windows_7/ie10-script5-access-is-denied/e87bdb30-7f2a-4510-bfa3-a22b995f777b – Volodymyr Khmil Aug 16 '19 at 06:28
8

Doubtless there might be many causes of the same symptoms, but here is what fixed this issue for me.

I had just one of many Windows 7 PCs with IE11 exhibiting the symptom of "Access Denied" on attempting any JavaScript involving window.localStorage from otherwise reputable and well-behaved web sites. Use of Process Explorer revealed that the proximal cause was an ACCESS DENIED when taskhost.exe (acting on behalf of Internet Explorer) tried to open DOMStore\container.dat for Generic Read-Write. In fact, it was worse than that: if I deleted container.dat, the same ACCESS DENIED occurred, even through the file did not exist any more. And, if I deleted the (hidden) DOMStore folder, when taskhost.exe attempted to recreate it, that received ACCESS DENIED as well.

After two days of chasing false leads, the final solution was this:

The registry entry:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\LowCache\Extensible Cache\DOMStore\CachePath

(do note the LowCache in that string) was incorrectly set to:

%USERPROFILE%\AppData\Local\Microsoft\Internet Explorer\DOMStore

when it should be:

%USERPROFILE%\AppData\LocalLow\Microsoft\Internet Explorer\DOMStore

with the consequence that low-integrity localStorage requests were being directed to medium-integrity regions of AppData disk storage, thus generating ACCESS DENIED errors, and killing the use of JavaScript window.localStorage.

This registry entry must have been wrong for many years: perhaps a side-effect of enthusiastic take-up of buggy platform previews and so on. This error survived a total removal and re-installation of IE11.

There is a similar-looking registry entry for the medium-integrity cache:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Extensible Cache\DOMStore\CachePath

and that is correctly left as:

%USERPROFILE%\AppData\Local\Microsoft\Internet Explorer\DOMStore

and should not be changed.

Robin Walker
  • 81
  • 1
  • 1
3

Try enabling the Enhanced Protected Mode in the IE settings, under the Advanced tab, in the Security sub-list. This enables the Microsoft XSS filter. I had similar issues when logging into SE, and fetching google+ notifications, and my first workaround was starting IE with admin privileges. But I think the EP mode will do the trick in your case too.

Related links: Understanding Enhanced Protected Mode

programstinator
  • 1,354
  • 3
  • 12
  • 31
3

Mark Russinovich always says: "when in doubt, use Process Monitor":

localStorage data gets stored in XML files in the following folder: C:\Users\[USERNAME]\AppData\Local\Microsoft\Internet Explorer\DOMStore

A profile of the file activity while reproducing the issue can tell you if the problem is caused by missing file access permissions or maybe even an anti-virus program.

I can reproduce the error by adding the read-only attribute to "DOMStore\container.dat". You should check if all file/folder permissions and attributes are set correctly. On my machine, admins and my own account have full permission for the mentioned folder.

Luis Cantero
  • 1,278
  • 13
  • 11
  • Unfortunately my computer doesn't even have the DOMStore folder within the Internet Explorer folder. Are you running IE10 in Windows 8? It needs to be the Metro/Modern version, as it works fine with the Legacy version. – Clint Brown Jan 24 '13 at 13:53
  • 1
    Oh, you never mentioned using the immersive mode. I'm running IE10 on Win8 Enterprise. Please check this folder instead: C:\Users\\[USERNAME]\AppData\Local\Packages\windows_ie_ac_001\AC\Microsoft\Internet Explorer\DOMStore – Luis Cantero Jan 24 '13 at 15:30
  • The only folder I find in the Internet Explorer folder is iconcache. – Clint Brown Jan 24 '13 at 21:20
  • 1
    Make sure that you can [see hidden files and folders](http://blogs.msdn.com/b/zxue/archive/2012/03/08/win8-howto-19-show-hidden-files-folders-and-drives.aspx) and let me know if DOMStore is still missing. – Luis Cantero Jan 24 '13 at 21:41
  • Yes, I have made sure I could see hidden stuff. That's always one of the first things I change whenever installing Windows. Can't stand the default! – Clint Brown Jan 25 '13 at 03:25
  • 1. Are you using a domain, local or Microsoft (e.g. hotmail) account? 2. Is the PC trusted? (see PC Settings) 3. Regardless of what type of account you are using, please try the other types and let me know what happens. 4. Please create a folder called DOMStore in the two "\Internet Explorer" folders that I mentioned above and make sure that you, Administrators and System have full access to the folder. 5. When repeating the tests, you will need to restart IE10 for the changes to take affect. – Luis Cantero Jan 25 '13 at 10:46
  • Luis Cantero, could you help me ? Same problem. Script5: Access is denied (when the website uses localStorage). It's a W7 IE10. This is a screenshot of Process Monitor and other useful stuff. http://i.imgur.com/X3VUwM3.jpg User & System has access to the file (default normal settings) – corbacho Jun 30 '13 at 23:06
  • I can't see the DOMStore folder either (hidden files showing). But if you type it into the address bar you can navigate into the folder. – Rumpleteaser Jul 03 '13 at 00:09
  • Process Moitor shows too much data, even then I filter out SUCCESS. Gave full permissions to Everyone on that folder, still nothing. IE10 Update 10.0.0.7 on Windows 7. – ulu Aug 02 '13 at 15:28
  • 1
    The DOMStore folder has a System attribute (for me). You might need to clear the "Hide protected operating system files (Recommended) folder" to see it. – Euro Micelli Apr 29 '14 at 11:17
  • Exactly, @Euro Micelli: I just checked that on win8.1 x64 with IE11 and I can confirm that only if you both check "show hidden files" and uncheck "hide protected system files" you will see those files... – Luke Nov 18 '15 at 16:34
2

Go to Tools/Internet Options/Advanced and under 'Security' select 'Enable DOM Storage' checkbox. This should fix the problem

VladMX
  • 31
  • 2
0

I added the websites involved to the Trusted Sites section of IE and have not received the error again.

northben
  • 5,448
  • 4
  • 35
  • 47
0

This issue may also be caused by having missing or corrupted registry entries. If a reset does not resolve the issue, the LocalLow folder has the correct integrity level, and the DOMStore registry value is correct, run the below commands to re-register IE in the profile:

32 Bit OS:

C:\WINDOWS\system32\ie4uinit.exe -BaseSettings

64 Bit OS:

C:\WINDOWS\system32\ie4uinit.exe -BaseSettings
C:\Windows\SysWOW64\ie4uinit.exe -BaseSettings

See the IE MSDN blog for more details.

Phillip Remaker
  • 273
  • 1
  • 7
Mitch
  • 21,223
  • 6
  • 63
  • 86
  • C:\Windows\SysWOW64\ie4uinit.exe -BaseSettings is not found, and the MSDN blog link is broken. – Phillip Remaker Aug 08 '20 at 16:54
  • 1
    @PhillipRemaker, not sure. Since it still exists in the native bitness (system32), I might assume the separate call to SysWow64 is no longer required. – Mitch Aug 09 '20 at 15:51
  • I updated the link to include the archived version of the MSDN post. I guess the 32 bit flavor runs fine on modern 64 bit Windows. It didn't solve my issues, which was inexplicable permission corruption in "%LOCALAPPDATA%\Microsoft\Internet Explorer" - I added an answer on that. – Phillip Remaker Aug 10 '20 at 16:17
0

In addition to the already excellent answers here, I'd like to add another observation. In my case, the NTFS permissions on the Windows %LOCALAPPDATA% directory structure were somehow broken.

To diagnose this issue. I created a new Windows account (profile), which worked fine with the localStorage,so then I painstakingly traversed the respective %LOCALAPPDATA%\Microsoft\Internet Explorer trees looking for discrepancies.

I found this gem:

C:\Users\User\AppData\Local\Microsoft>icacls "Internet Explorer"
Internet Explorer Everyone:(F)

I have NO idea how the permissions were set wide open!

Worse, all of the subdirectories has all permissions off. No wonder the DOMStore was inaccessible!

The working permissions from the other account were:

 NT AUTHORITY\SYSTEM:(OI)(CI)(F)
 BUILTIN\Administrators:(OI)(CI)(F)
 my-pc\test:(OI)(CI)(F)

Which matched the permissions of the parent directory.

So, in a fit of laziness, I fixed the problem by having all directories "Internet Explorer" and under inherit the permissions. The RIGHT thing to do would be to manually apply each permission and not rely on the inherit function. But one thing to check is the NTFS permissions of %LOCALAPPDATA%\Microsoft\Internet Explorer if you experience this issue. If DOMStore has broken permissions, all attempts to access localStorage will be met with Access Denied.

Phillip Remaker
  • 273
  • 1
  • 7