ASP.NET Access to the temp directory is denied

Question

I'm experiencing this problem today on many different servers.

System.UnauthorizedAccessException: Access to the temp directory is denied.

The servers were not touched recently. The only thing that comes in my mind is a windows update breaking something.. Any idea?

This happens when trying to access a webservice from an asp.net page

System.UnauthorizedAccessException: Access to the temp directory is denied.  Identity 'NT AUTHORITY\NETWORK SERVICE' under which XmlSerializer is running does not have sufficient permission to access the temp directory.  CodeDom will use the user account the process is using to do the compilation, so if the user doesnt have access to system temp directory, you will not be able to compile.  Use Path.GetTempPath() API to find out the temp directory location.
       at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence)
       at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies)
       at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, String location, Evidence evidence)
       at System.Xml.Serialization.XmlSerializer.FromMappings(XmlMapping[] mappings, Evidence evidence)
       at System.Web.Services.Protocols.XmlReturn.GetInitializers(LogicalMethodInfo[] methodInfos)
       at System.Web.Services.Protocols.HttpServerType..ctor(Type type)
       at System.Web.Services.Protocols.HttpServerProtocol.Initialize()
       at System.Web.Services.Protocols.ServerProtocol.SetContext(Type type, HttpContext context, HttpRequest request, HttpResponse response)
       at System.Web.Services.Protocols.ServerProtocolFactory.Create(Type type, HttpContext context, HttpRequest request, HttpResponse response, Boolean& abortProcessing)

score 12 · Accepted Answer · answered Feb 12 '09 at 17:08

12

Have you checked the permissions on the temp folder? In these cases, the easiest and quickest solution is usually to re-run the aspnet_regiis -i command to re-install the asp.net framework which also resets the permissions on the required folders. Failing that, try using Process Monitor to check what's going on and modify the permissions accordingly.

answered Feb 12 '09 at 17:08

Mun

14,098
11
59
83

4

I had the same issue and using process monitor solved the problem for me. You only need to watch for file system activity and then look for w3wp.exe. The error message was something like permission denied and it gave the exact folder that w3wp was trying to write to. I gave the Network Service username read, write and list folder contents permissions. – Helephant May 12 '09 at 09:41
Beware using `aspnet_regiis -i` on a server where you have asp.net 2.0 apps running as it upgrades them to asp.net 4.0. Better to use `aspnet_regiis -ir` – Rory Jan 06 '16 at 12:09

score 10 · Answer 2 · edited May 23 '17 at 11:53

I had the same issue and none of the above solved our issue -- we restored service temporally by changing the setting that each app pool site was running under - you can do this by going into app pools--> idenity tab and and changing user from Network Service to local user- while we figured out what the problem was(this is not recommended- so if you choose to do this make sure you understand the repercussions)

We then found a link about the Temp\TMP mappings and how to fix them -Which was not our issue

On another site (and as described in other answers) we used Path.GetTempPath() to see what the CLR was actually looking for it turned out to be

C:\WINDOWS\system32\config\systemprofile\Local Settings\Temp folder

We then used Process Monitor to verify this was in fact correct, when we changed the permission on this folder it worked correctly. We are still unsure as to why the CLR choose to stop using the default temp directory but we did find a link as to how it makes that decision. How GetTempPath is picked.

Update: We Finally figured out HOW our Temp folder PATH was changed when Someone decided to repeat the error! The Issue was the CLR Profiler someone decided to run on live which changes all permissions of the temp directory so If you didn't already know this already I would not recommend running it on a Prod server.

These suggestions helped us troubleshoot a similar problem with a Windows service running as *Network Service* wherein NHibernate mapping file compilation failed because of the temp dir issue. Thanks! — Kit, Nov 17 '10 at 15:36

score 1 · Answer 3 · answered Feb 12 '09 at 17:09

Whatever the reason for the sudden change, you can probably solve the problem using the steps described in the exception.

Call Path.GetTempPath to find out what it thinks the temporary directory is, it may not be what you think it is.

Go to that directory and give the user 'NETWORK SERVICE' the permissions it needs, probably Read/Write.

barrypicker · Answer 4 · 2013-03-11T20:05:22.847

Windows Server 2003 - IIS 6.0 - Same issue. c:\windows\temp = current temp directory - using procmon as suggested by cgreeno allowed me to see access denied. I granted the user 'Everyone' full rights to the c:\windows\temp folder, but still getting access denied. Granted full rights access to all users in the mix (Local System, Network Service, app pool identity user, etc.) but no help. Tried ASPNET_REGIIS -ir but no help.

I created a new local system user 'tempuser' and assigned to local 'Administrators' group. I navigated to Windows Services and stopped 'World Wide Web Publishing', 'IIS Admin', and 'HTTP SSL'. I assigned 'tempuser' to all three services. I tried to start each of the services, but they failed to start for a variety of reasons. I then put all 3 services back to user 'Local System' and suddenly my access denied error went away. Don't know why. Was having other file system errors with my App Pool user, but those now are working correctly too. It appears something with the assignment of the Local System account with windows services was awry.

* UPDATE *

Problem came back. Very weird...

I sure hope you removed the 'Everyone' permissions after your testing. — Andrew Barber, Mar 11 '13 at 17:47
We replicated our production server into a private network for diagnostics... This copy will be destroyed in the near future. — barrypicker, Mar 11 '13 at 20:06

score 0 · Answer 5 · answered Oct 26 '15 at 07:35

0

In my case antivirus(COMDO) was responsible for this... After antivirus updated it just started to block access to temp folder for my local services(not all, just few) ... it was kinda tricky to figure it out..

answered Oct 26 '15 at 07:35

Janis Rudovskis

193
3
9

Wow, in my case it was the antivirus too, as you said. It seems the antivirus blocks access to the _windows/temp_ directory. Even if you open security of that directory, the error keeps coming. When I closed the antivirus, the error went away and I could generate the ssrs report. – Manuel Rivera Jan 13 '16 at 21:50

score 0 · Answer 6 · answered Mar 11 '16 at 08:48

0

Goto into roslyn folder (into bin foloder of your project) and add the read/write permissions at the user which runs the application pool

answered Mar 11 '16 at 08:48

Diego

11
3

score 0 · Answer 7 · answered Feb 12 '09 at 17:17

Indeed its a web site running in IIS? and accessing a web service.

It's either running as ASPNET, anonymous, or impersonating the user connected or finally the web service itself is connecting as a 'user'.

Whichever user it is may not have access to the temp directory. Odd how nothing has changed :). However Windows Service packs can change security settings.

ASP.NET Access to the temp directory is denied

7 Answers7

Linked