Pesky file system permissions

If any of you have children, you’re probably well aware of their awesome ability to spread around every new variation of the common cold that appears. This week I’ve been mostly suffering under the latest of these “presents” from my son, and to be honest may not be doing my sharpest ever thinking…

Coincidentally it took me a bit of head-scratching to resolve a problem with an experimental instance of Sitecore 6.6 that I wanted to make use of the other day. Browsing to the public site appeared fine, but when I tried to load Content Editor I was greeted with an exception saying “Access to the path 'C:\inetpub\wwwroot\TEST\Data\viewstate\1\7\E' is denied.“:


I Googled this, and got a collection of things relating to “incorrect file system permissions” but nothing specific to the particular error I was seeing. Oddly a separate instance that had been set up using the same process and files appeared to be working fine.

Having compared file permissions and folder structures with the Google results I had, the answer turned out to be related to the fact that your IIS Application Pool process account needs to have write access to the instance’s “Data” folder. (This is described in the manual install instructions on SDN) But the error above only appeared at the point that Sitecore needed to write data. The only difference I spotted between the working and broken instance was that the broken one’s Viewstate folder had been cleaned out:

Missing Files

The instance of Sitecore that had a “viewstate” folder full of files didn’t give the error despite the missing permission. But when I removed those files, the error appeared when Sitecore tried to re-create this data.

So should you ever find yourself with a similar error message, here’s what to try:

Check what process account your instance of Sitecore’s App Pool is running under. Find the App Pool in IIS Manager and look at the Advanced Settings:

App Pool

Then check whether this account has “Modify” permissions to the Sitecore instance’s “Data” folder:

Data Permissions

If this permission is missing, add it back in:

Fixed Permissions

You should now find that your site works again…


2 thoughts on “Pesky file system permissions

  1. Going on from this, as I was messing in this area today…. yes you’ll get the viewstate errors, you’ll get unable to create counter errors and first and foremost you won’t even be generating any logs. So if your logs directory is empty, it will probably be one of two things: the dataFolder variable is pointing not where you think it is in web.config, or the permissions are not sufficient.

    The example pictured above is for Network Service and Sitecore 6.x. If you’ve been working with SC 6, the temptation with SC7 is to set the app pool to Network Service as it’s a known quantity. Nonetheless I decided to persevere and incrementally add permissions to get AppPoolIdentity to work.

    I added IIS_IUSRS with Modify permissions to the data directory and, to my surprise, I still did not get any logging. I tried it by specifically adding IIS Apppool\myapppoolname and this didn’t work either. This should be in the larger IIS_IUSRS group so no big surprise there (though I will say, I wouldn’t have been terribly surprised if it HAD worked).

    I then added Everyone to the logs directory and that broke the logjam. But I really don’t want to use Everyone, I just wanted to confirm this was a perms issue. In the end, I broke down and actually cracked the manual. Or the SC7 install guide PDF in this case. I found in 4.2.2 File System Permissions for ASP.NET Requests something that surprised me, even after having worked with SC for a while… IIS 7.5 uses AppPoolIdentity: check. Can do this with IIS_IUSRS: check.

    What I had not bargained on was: “This account requires Modify permissions to all files, folders, and subfolders under the /Website and /Data folders.” I don’t remember this from the past. I thought Modify was only required for certain specific directories such as logs, indexes, debug.

    Anyway, I spread the Modify joy across the entire site for IIS_IUSRS and it works. Dutifully recorded here in case it helps somebody else.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.