Access to the temp directory is denied. Identity 'NT AUTHORITYNETWORK SERVICE' under which XmlSerializer is running does not have sufficient permiss

造成错误的原因是用bat代码清理系统垃圾时造成的权限丢失而引起的

错误描述 

1、An error occurred creating the configuration section handler for RewriterConfig: Access to the temp directory is denied.  Identity 'NT AUTHORITYNETWORK 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 doesn�t have access to system temp directory, you will not be able to compile.  Use Path.GetTempPath() API to find out the temp directory location.

2、

 

Server Error in '/' Application.

---

Access to the temp directory is denied.  Identity 'NT AUTHORITYNETWORK 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.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.UnauthorizedAccessException: Access to the temp directory is denied.  Identity 'NT AUTHORITYNETWORK 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.

ASP.NET is not authorized to access the requested resource. Consider granting access rights to the resource to the ASP.NET request identity. ASP.NET has a base process identity (typically {MACHINE}ASPNET on IIS 5 or Network Service on IIS 6) that is used if the application is not impersonating. If the application is impersonating via <identity impersonate="true"/>, the identity will be the anonymous user (typically IUSR_MACHINENAME) or the authenticated request user.

To grant ASP.NET access to a file, right-click the file in Explorer, choose "Properties" and select the Security tab. Click "Add" to add the appropriate user or group. Highlight the ASP.NET account, and check the boxes for the desired access.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[UnauthorizedAccessException: Access to the temp directory is denied.  Identity 'NT AUTHORITYNETWORK 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.]
   Discuz.Common.SerializationHelper.Load(Type type, String filename) +129
   Discuz.Config.DefaultConfigFileManager.DeserializeInfo(String configfilepath, Type configtype) +7
   Discuz.Config.BaseConfigFileManager..cctor() +121

[TypeInitializationException: The type initializer for 'Discuz.Config.BaseConfigFileManager' threw an exception.]
   Discuz.Config.BaseConfigFileManager.LoadConfig() +0
   Discuz.Config.BaseConfigs..cctor() +54

[TypeInitializationException: The type initializer for 'Discuz.Config.BaseConfigs' threw an exception.]
   Discuz.Config.ScheduleConfigFileManager.get_ConfigFilePath() +41
   Discuz.Config.ScheduleConfigFileManager..cctor() +36

[TypeInitializationException: The type initializer for 'Discuz.Config.ScheduleConfigFileManager' threw an exception.]
   Discuz.Config.ScheduleConfigFileManager.LoadConfig() +0
   Discuz.Config.ScheduleConfigs.GetConfig() +5
   Discuz.Forum.HttpModule.Init(HttpApplication context) +73
   System.Web.HttpApplication.InitModulesCommon() +65
   System.Web.HttpApplication.InitModules() +43
   System.Web.HttpApplication.InitInternal(HttpContext context, HttpApplicationState state, MethodInfo[] handlers) +729
   System.Web.HttpApplicationFactory.GetNormalApplicationInstance(HttpContext context) +298
   System.Web.HttpApplicationFactory.GetApplicationInstance(HttpContext context) +107
   System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr) +289

解决方案：

1、 

设置目录 C:WindowsTemp 的对用访问权限为 “增加写入权限”。或是

设置目录 C:WindowsTemp 的对用访问权限为 “FULL CONTROL”。

2.增加系统临时文件的权限

6 down vote

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 TempTMP 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:WINDOWSsystem32configsystemprofileLocal SettingsTemp 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.

 3、增加临时文件 的权限

Currently, I use Path.GetTempPath() to figure out where to write my log files, but recently I came across a user's machine where the path returned was not what I expected.

Usually, the returned path is C:Documents and Settings[userid]Local SettingsTemp but in this case, it was C:Temp

This would not normally be a problem, but for some reason the user in question did not have access to write to C:Temp

I double checked the environment variables, and the USER environment variable was pointing as expected to C:Documents and Settings[userid]Local SettingsTemp, whilst the SYSTEM environment variable was pointing to C:WINNTTemp.

So... where is Path.GetTempPath() getting it's value from ? Group Policy? Registry?

参考资料：

http://stackoverflow.com/questions/542312/asp-net-access-to-the-temp-directory-is-denied

http://stackoverflow.com/questions/2365307/what-determines-the-return-value-of-path-gettemppath