IIS ApplicationPoolIdentity does not have write permission to 'Temporary ASP.NET Files'
Asked Answered
P

12

54

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.

Parmer answered 31/3, 2014 at 7:42 Comment(4)
I'm having exactly the same issue. Were you able to find a solution for this?Feudality
No, unfortunately I have not found anything to resolve this issue. I'm starting to think that there is in fact no solution. I find it difficult to believe though that Microsoft would add the 'ApplicationPoolIdentity' feature without considering the impact on .NET applications.Parmer
Should I add an explicit answer than says don't use 'ApplicationPoolIndentity' with .NET apps?Parmer
It appears your instincts are correct. Network Service is not preferred "because services running as Network Service can tamper with other services that run under the same identity" per the following link: (iis.net/learn/manage/configuring-security/…).Claymore
D
108

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:

  1. Open a Command window as an administrator (Start / Programs / Accessories, then right-click over Command Prompt, then choose "Run as administrator").
  2. 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.

Decumbent answered 20/4, 2015 at 15:43 Comment(7)
Used the solution to create missing temporary folders for the version 2.0 under 2008R2/2012. Faced no problems with the "NETWORK SERVICE" account (though it is not truly local account).Letterpress
Thanks for the update @Vertigo! The documentation was hard for me to follow (it's not really my specialty area) so your comment improves my answer immensely; I truly appreciate it.Decumbent
Be sure to surround the domain\user part with quotes if it contains a space, e.g. ... -ga "IIS AppPool\DefaultAppPool"Auric
If this doesn't work, try C:\Windows\Microsoft.NET\Framework\v4.0.30319\Aspnet_regiis.exe -ga domain\user instead. (non 64 bit version)Auric
Thanks @codebrain; excellent suggestion! I found that someone else had already provided an answer, so I linked to their answer instead.Decumbent
Use the principal name IIS_IUSRS if it's an IIS app pool that can't write to the temp directory.Bugbee
use IIS_IUSRS as the domain name userPaleoecology
D
12

I faced same problem. I checked the path c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\ looking for Temporary ASP.NET Files, but there was not any folder by this name. so I created a new folder manually and named it Temporary ASP.NET Files and problem fixed.

So ensure the mentioned path exists.

Dawnedawson answered 26/1, 2017 at 11:40 Comment(4)
If the problem still exists right click on the folder => properties => security => edit => add => IIS_USERSSuperfecundation
This did the trick for me. Once I created the folder the problem was solved.Backbend
In my case the folder was there but just had to give permission to the user using the server.Katusha
I just had to give write permission to IIS_USERSWhether
S
10

I resolved the error by adding the user the application pool uses to IIS_IUSRS group.

Sorbian answered 15/1, 2018 at 13:43 Comment(0)
P
9

Along with the up voted solutions, Please check your disk space and make sure there is enough disk space available.

I just ran in to this issue on one of our production server and it was related to the low disk space.

Palaeontography answered 25/4, 2016 at 5:41 Comment(2)
Wow this was the exact same case that happened to our Production server. Fortunately I was able to find your answer within a few minutes 😅 The logs was eating up the disk spaceGoa
It would be easy to brush this off and not check but after being convinced nothing had changed in terms of the app pool user and security, sure enough my dev machine had 10% left on the drive.Pull
I
2

We're 2021 now, but ran into this issue as well on a Windows Server 2019.

The error CS0016 was misleading in my case: Giving permissions for ApplicationPool-Identities or similar users on the Temporary ASP.NET Files didn't work and wasn't the actual issue.

After installing a fresh server, Users does not have permission to modify the temp folder in the C:\Windows directory. When .NET needs to write temporary files to the temp folder, an exception occurs because of no permission to write.

Assigning modify permissions for Users to the temp folder under the C:\Windows directory worked for me.

Iny answered 2/3, 2021 at 23:29 Comment(1)
Thank you. Works on my Windows 10.Intitule
A
1

Being in the C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319 try running the aspnet_regiis.exe command.

Typically the permissions should be set up. If Windows Add/Remove Programs happen, or if new .NET versions get installed, these things get reset a bit. Running the aspnet_regiis.exe should help there.

Also, ensure you're running Visual Studio as an Administrator.

Arterialize answered 31/3, 2014 at 8:11 Comment(2)
If I attempt to run 'aspnet_regiis.exe -I' for the v4.0.30319 framework under Windows 8 I get an error message saying that its not supported. See this article: c-sharpcorner.com/UploadFile/7e39ca/….Parmer
I have setup Visual Studio to always run as 'Administrator' though in this scenario I don't see why that would make any difference (as I'm running under IIS).Parmer
M
1

This happened to one of my websites, and the tech support team at my web host resolved it by changing the TEMP directory for ASP.NET using the tempDirectory attribute on the compilation node of my web.config file like this:

<system.web>
  <compilation debug="true" targetFramework="4.6.1" tempDirectory="c:\temp" />
  ...
</system.web>

Please note: The directory must be accessible to the service account, so setting permissions may be part of the solution, but no other answer has referenced this poorly documented tempDirectory web.config attribute.

Margueritamarguerite answered 3/9, 2023 at 7:28 Comment(0)
M
0

I just ran into this and what I did was to create a new account, lets say its "Webby".

In ISS, go into Advance Settings of your page and change "Physical Path Credentials" to the Webby account. The Path field above that has the webpage directory; open this folder in Explorer and add Webby with Modify permissions. Under "Failed Request Tracing" there's a logs directory; add modify to that too and set "Enabled" to true (you can turn it off later, but make sure it'll work). At this point you can try your site and you should definitely get the error message, because of the user you are using.

The current identity (YOUR\Webby) does not have write access to 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files'.

Now, to fix your problem, you will need to go to the 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files' directory and add Webby to that as well, again Modify works.

The solution of using a special account just for websites is a good idea. It is a real account (not virtual like ApplicationPool) and Windows doesn't get confused (...as easily).

Hope this helps.

Menzies answered 7/6, 2016 at 21:24 Comment(0)
A
0

In IIS7, I right clicked on the virtual directory, removed the application and added it again. That fixed it for me.

Absorbance answered 1/8, 2018 at 14:1 Comment(0)
F
0

i resolved it by freeing disk space

Frizzle answered 20/8, 2018 at 7:5 Comment(0)
M
0

I have had this problem, and I can resolved it. You only have to give permissions to the folder: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files, for your current user. It's easily.

Good luck!!

Morelos answered 15/3, 2020 at 5:57 Comment(0)
B
0

In my case, the IIS_IUSRS group didn't have "write" permissions for the "Temporary ASP.NET Files" folder. Had to right-click in the "Temporary ASP.NET Files", select Security, and add write permissions to the "IIS_IUSRS" group

Boyt answered 19/3 at 21:35 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.