IIS ApplicationPoolIdentity does not have write permission to 'Temporary ASP.NET Files'
I am attempting to launch a website from an 'AppPool' called 'SomeAppPool' which uses the 'ApplicationPoolIdentity' and when I do I receive the following error when I launch the website:
The current identity (IIS_APPPOOL\SomeAppPool) does not have write access to 'c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files'
I'm launching the website with 'Use Local IIS Web Server' within Visual Studio 2012 (with no debugger attached) under Windows 8.
The first thing I noticed is that the 'Temporary ASP.NET Files' folder does not even exist so there is nothing to set security permissions on.
The second issue is, even if there was a folder, what permissions would I set? I'm assuming that I should not have to set permissions for each user created through 'ApplicationPoolIdentity'. Right?
The current solutions i've seen simply suggest to set the user to 'Network Service' but this seems to break the isolation of the website for which 'ApplicationPoolIdentity' was introduced.
Answer
This ASP.NET forum answer, unacknowledged in its thread, was the solution for me. It's also low-impact: it doesn't try to re-register IIS or give the user dangerous privileges. To summarize the answer:
- Open a Command window as an administrator (Start / Programs / Accessories, then right-click over Command Prompt, then choose "Run as administrator").
Enter the following command:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Aspnet_regiis.exe -ga domain\user
Substitute your domain and user for domain\user in the example above. That's all it took.
The Microsoft documentation for Aspnet_regiis.exe is here. Note that the documentation for the -ga switch refers to a bug in versions 3.5 and earlier, where it wouldn't work with local accounts. If I'm reading it correctly, domain accounts are supported for all versions and local accounts are supported starting with Framework 4.0.
Update 6 June 2017: For Windows 8 and above, consider the dism command instead. It's covered in this SO answer. Thanks to @codebrain for suggesting this.
Update 7 July 2015: @Vertigo kindly commented that this answer also worked for the NETWORK SERVICE account in .NET 2.0 under 2008R2/2012, so my disclaimer above about local accounts pre-4.0 may be wrong.
If anyone else finds that this works for a local account under .NET 3.5 or earlier, please feel free to edit my answer or to note it in the comments; it would be a great help to others who may experience this same problem.