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

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 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.

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 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.]
   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:\Windows\Temp 的對用訪問權限為 “增加寫入權限”。或是

設置目錄 C:\Windows\Temp 的對用訪問權限為 “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 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.

 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 Settings\Temp 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 Settings\Temp, whilst the SYSTEM environment variable was pointing to C:\WINNT\Temp.

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