Compiler Error Message: CS0016: Could not write to output file 'c:WINDOWSMicrosoft.NETFrameworkv1.1.4322Temporary ASP.NET FilesMyAppfadda49ebbdb0b87eqdatzch.dll' -- 'Access is denied.'
What I like about the above error message is the part which says 'Access is denied.' These are some of the easiest issues to fix!! Right?? Well in most cases 'Yes'. All you have to usually do is give the Process Account or Impersonating thread identity required NTFS access to the resource. The reason I like working here in PSS is because you get to work on issues which will blow your mind (EVERYDAY). Most customers would have already Googled for a solution and tried an extensive list of things trying to fix the issue. If they haven't already done that, then they are calling because the WebSite is down and the business impact $$$$$$$$ is "HUGE".
In this case the customer was of the former type. He had tried everything to fix the issue but to no avail. To give you a little background on the issue, the Web Server was a Windows 2003 SP1 server(IIS 6.0) running an ASP.NET WebService. The App used to work fine until it threw the above error. According to the customer, the only way to recover from the problem was to repeatedely reboot the machine and the error would go away. I had never heard of anything like this before. Neither have the 3 Engineers who worked on this issue before engaging me to have a go at the problem heard of anything like this. The typical way to troubleshoot this problem would be to verify that all the permissions and policies were in place as per the knowledge base article Process and request identity in ASP.NET: https://support.microsoft.com/kb/317012 .
The AppPool identity was the default "Network Service" account. After verifying kb317012 a dozen times we were still getting the error. The bizzare part was that "Network Service" account had Full Control on "c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files" folder but running Filemon would still show Access Denied for the "Network Service" account on "c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files" folder. The Engineers had tried various way to troubleshoot the problem. They tried changing the AppPool Identity to a domain account but this resulted in the same error and Filemon now showed Access Denied for the domain account. This is about when I came in and I requested the customer to allow us to view his desktop via a Live Meeting.
Working here for over 2 yrs has taught me never to trust anyone, especially customers. In this case I didn't trust my fellow Engineers as well so I went through all the same troubleshooting steps they had done (I dont like making assumptions without hard facts). This dosen't go down too well with customers as nobody wants to try the same steps repeatedely, if you already know its not going to help. While I was checking the NTFS permissions for the Network Service account on "C:\Windows\Temp" something caught my EYE and I made sure I took a PRINTSCREEN so that I can share this information with you :)
RESOLUTION
===========
If you notice clearly, the "C:\Windows\Temp" location is not a folder but a Mounted Drive. If you then click the Security Tab for "C:\Windows\Temp" you can see the Network Service account present with FULL CONTROL. Instinct tells me that this may be related to the issue so the next logical step would be to isolate the problem and see if changing the "C:\Windows\Temp" helps.
I changed the values of the TMP and TEMP System Environment variables to point to "C:\TEMP" instead of "C:\Windows\Temp" and this resolved the issue.
IIRC they had the "C:\Windows\Temp" location set up as a mounted drive to store huge number of files there which were getting writin by some other application. Somehow ASP.NET didnt like it.
Now you might still wonder, why do we get the error if all the permissions seem to be in place?? As much as I would have liked, I couldn't invesitigate further since we already had an acceptable solution as it is not worth the time and effort to find out why mounted volumes are causing the issue.
Comments
Anonymous
June 07, 2007
Hi there! Thank you very much for your help! This has helped me solve a problem that was very annoying and confusing. Thanks, once again! All the best, IrinelAnonymous
July 10, 2007
THANK YOU THANK YOU THANK YOU!!! I had to meet a deadline and my website could not start because ASP could not create ONE file in the Temporary ASP.Net directory even though the permissions were correct. I never would have known to look at the WindowsTemp folder if not for this blog. It turns out that I had two SIDs in the ACL that could not be resolved and I deleted them. I also set full control for Network Service because I believe that is the account that writes to the temp folder. I can't actually double check that right now, so don't quote me on that.... Anyway, thank you so much. This was a lifesaver.Anonymous
July 16, 2007
I think this is a very good article. I have this problem and look all over the web for resolution. My error message was "There is not enough disk space". Do you think it is the same cause??? thanksAnonymous
July 19, 2007
This works on my server...while all other solutions on the web failed... I used to partition HDD and customise shell folders' locations...and .NET web-apps / IIS seemed not comfort within my server settings. Thank you very much!Anonymous
September 12, 2007
We are using .Net Framwork 2.0 and I received a simelar error message. This same solution worked for us. Thanks!!!Anonymous
October 02, 2007
The comment has been removedAnonymous
November 05, 2007
We had the same problem. The environment was set up to use E:Temp for the temp folder, but the folder had never been created on E. Created the folder and it worked.Anonymous
November 06, 2007
I've tried this and it still doesn't work. Please help me fix this. Our website has been working fine. I went to make a change on the website when this error started occurring. I've checked the permissions and had our IT NT guy look and he verified all permissions. PLEASE HELP ME! jignesh.shah@pni.comAnonymous
November 07, 2007
Hey Jignesh, Can you copy paste the entire stack trace? Thanks, VigneshAnonymous
February 03, 2008
Thank you so much..... This has helped me to solve the problem.Anonymous
March 05, 2008
Thank you so much..... This has helped me to solve the problem.Anonymous
April 09, 2008
I am having the same problem with a Sharpoint 2.0 install. I have tried changing the temp and tmp variables and checked permissions but no help. Any other suggestions as to what else I can try?Anonymous
April 09, 2008
Please ignore my first post. The power of REBOOT is amazing. I got it to finally work with your solution. Many, many thanks.Anonymous
June 16, 2008
The comment has been removedAnonymous
June 25, 2008
Hi Linsen, You would get this error even after you run the aspnet_regiis -i command. All this command does is a) Reconfigures IIS mappings to handle extensions like .aspx, .asmx etc. b) Creates ASPNET account if missing. c) Ensures ASPNET account has minimum privileges for certain common folders.Anonymous
August 18, 2008
This solved a similiar issue with trying to reference a web service in VS 2005 on a Vista machine. Just gave the NETWORK SERVICE rights to c:windowstemp folder and viola, it was resolved. Much appreciated for pointing me in the right direction!Anonymous
September 02, 2008
Here's a real fix: Look at all the drives and mount points for TEMP and make sure Network Service has full access to ALL of them. I had to grant Network Service rights to BOTH C:TEMP and T: for it to work (I'd already moved C:WINDOWSTEMP to C:TEMP) since the drive was mounted both places. To figure this out, I ran SysInternal's procmon filtered for csc.exe and looked for the permission error. It tried to write to C:TEMP (which it has permission to) but then tried to write to T: (which it didn't). Looks like CreateFile is translating the mount points over to drive mappings somewhere, so you need to grant identical permission to each mount point/drive.Anonymous
September 24, 2008
The comment has been removedAnonymous
October 05, 2008
Hello guys, im having the same problem with Asp.net 2 , all the above solution did not work , anu help please. mu application created in VS2008 my OS is windows server 2003 and im using IIS6 and .net 2 . please any help will appreciate.Anonymous
October 11, 2008
Hello Guys, I have the same issue in ASP.Net 2.0. As per the Vignesh's statement I checked the "Temp" directory securities in c:windows . Its is not showing as "Mounted Volume". Its showing as "File Folder" I gave full rights to that Folder for "ASP.Net" and "Nettwork service" account. I am using "Administrator" account for windows login. Still the problem persists. Eventhough I tried to change the Environment varible to locate in "C:Temp" instead of C:WINDOWSTEMP", but its not solving this issue. Can you please share the solution if u have anything. Please.......... Thanks in advance.... Saravanan.SAnonymous
October 31, 2008
The comment has been removedAnonymous
January 06, 2009
Thank you! It helped a great deal.Anonymous
January 18, 2009
Had this issue on Windows Vista for a .NET 2.0 application. Jeff's solution to grant Network Services permissions to WindowsTemp resolved my issue as well. Thanks!Anonymous
March 01, 2009
Hi, I'm using McAfee VirusScan Enterprise with highly secured settings and found that it was McAfee which was preventing VS to create new file in Windows directory. Thanks for sharing this anyway :)Anonymous
March 23, 2009
The comment has been removedAnonymous
March 24, 2009
Hi How you have changed the values of the TMP and TEMP System Environment variables to point to "C:TEMP" instead of "C:WindowsTemp" ThanksAnonymous
March 24, 2009
I created Network services at windowstemp folder, while creating there is an option called location, I am confused which location I must choose? later I gave full control. still I am getting the same errorAnonymous
March 24, 2009
Great fix. Was about to give up and take reinstallation route before coming across this entry. Stupid verbiage of the error message was misleading me in all directions. Though in my case temp was not a mounted drive or no permission issues foresee, I just went ahead and changed the dir and it did the magicAnonymous
October 22, 2009
Thanks a lot for the info... It worked for me.Anonymous
February 20, 2010
Thanks, worked for me. In my case, the server was missing the TMP and TEMP system variables. As soon a I directed them to C:WindowsTemp, that did the trick. There were user variables for TMP and TEMP pointing to the default locations.Anonymous
April 11, 2010
Peradventure you have tried granting full access to NETWORK SERVICE on C:temp as many having suggested and no luck. You may need to also grant NETWORK SERVICE account Full Access to C:Windowstemp Hope this helps!Anonymous
November 09, 2010
I gave the NETWORK SERVICE account full control to the location of TEMP and TMP environment variables and this fixed it for me.Anonymous
April 01, 2011
Hi Id like to know if it is possible to writedata to file. I am using version 2.0 and when I compile code it complains that it does not know filestresm and debugger.Anonymous
December 02, 2012
thank you very much i solve my problemAnonymous
May 23, 2013
The comment has been removedAnonymous
November 21, 2013
Thank You! Worked a treat! Found a previous tech had created an additional temp folder without appropriate permissions.Anonymous
May 22, 2014
That's very sloppy design for the CSC... If it tries to write to C:WindowsTemp it SHOULDN'T ever say it can't write to C:WindowsMicrosoft.NETFramework...Temporary ASP.NET Files... ! Anyway, is this configurable anywhere? Since i want CSC to write only to C:TempVS while other programs write in their own designated Temp folders.Anonymous
May 13, 2015
This is a great help!! Saved my day.. Thanks a lot !!Anonymous
July 01, 2015
Do this in a dos promt as administrator c:windowssystem32icacls c:windowstemp /grant "IIS_IUSRS":(OI)(CI)M