Tip: Missing NETWORKSERVICE privileges on system temp directory

Tip: Missing NETWORKSERVICE privileges on system temp directory

  

Hello

 

I would like to describe you in this post a somewhat common error that usually is misleading due to incomplete information from the ASP.NET exception that's raised. The problem is a lack of permissions on the file system during the deployment of an espace, or even during the first access to an OutSystems Application (espace).

 

Symptoms

 

The typical symptom you've got, either during the deployment of an espace, or when accessing your application for the first time, is an Access Denied error while writting an assembly into the Temporary ASP.NET Files folder, generating an exception stack like:

 

(0): error CS0016: Could not write to output file 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\servicecenter\9f2cf0ef\1a19bba9\App_global.asax.s_dj_7ua.dll'- 'Access is denied. '
   at System.Web.Compilation.AssemblyBuilder.Compile()
   at System.Web.Compilation.BuildProvidersCompiler.PerformBuild()
   at System.Web.Compilation.ApplicationBuildProvider.GetGlobalAsaxBuildResult(Boolean isPrecompiledApp)
   at System.Web.Compilation.BuildManager.CompileGlobalAsax()
   at System.Web.Compilation.BuildManager.EnsureTopLevelFilesCompiled()
   at System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters)

(0): error CS0016: Could not write to output file 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\servicecenter\9f2cf0ef\1a19bba9\App_global.asax.s_dj_7ua.dll'- 'Access is denied. '
   at System.Web.HttpRuntime.FirstRequestInit(HttpContext context)
   at System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context)
   at System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr)

 

Cause

 

Although the error message states that the lack of permissions is occurring on the Temporary ASP.NET Files directory, under the .NET Framework folder, the real problem is in fact lack of permissions for the NETWORKSERVICE on the system temporary folder (by default c:\windows\temp).

 

This happens because during the first access to the application, either during the final step of the deployment which calls for the application's _ping.aspx file, or the first access by an application user, the ASP.NET application needs to be translated from the Microsoft Intermediate Language (MSIL) code (which are the assemblies generated by the OutSystems Agile Platform), into machine and CPU-specific code (executable code), which will lay under the Temporary ASP.NET Files folder.

 

What the exception doesn't let you know, is that the .NET Framework compiler that generates the Temporary ASP.NET Files uses the system temporary folder to create temporary files that assists the first request compilation process (MSIL translation into CPU-Specific code).

 

It's possible that by following some Security recommendations for Hardening Security on Windows 2003 Servers, you'll deny write/change privileges over the system temporary folder, causing a lack of permissions exception for that user when accessing the file system. Unfortunately, the exception that's raised by the .NET Framework seems to be rethrown or masked by a secondary exception on the Temporary ASP.NET Files folder.

 

Resolution

 

The obivous resolution is to guarantee that the NETWORKSERVICE, or the account that's running IIS, has read, write, create, modify and delete privileges on system temporary folder (e.g., c:\windows\temp).

 

The best way to identify the exact folder, user and process involved in the Access Denied exception, is to use the former sysinternals FileMon tool, and catch the ACCESS DENIED result. You'll find out that the exception is occurring in the system temporary folder, instead of the Temporary ASP.NET Files folder. This tool, and where to get it, is also referred on the How to: Identify which file is getting locked or is not accessible forum topic referenced below.

 

Hope this information helps you to avoid hours of troubleshooting due to a misleading .NET Framework exception.

 

Some additional references below:

 

Cheers

 

Miguel João