造成错误的原因是用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.增加系统临时文件的权限
|
|
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
