Permissions issue with virtual directory to UNC path

Question

I have a virtual directory in my site (test environment). It is a UNC share which is also used as a public FTP.

It is configured to connect as a domain admin account and "Test settings" says everything appears to be working. However when I try to connect to it I get:

500 - "Failed to start monitoring changes on \INTRANET\FTP\test\web.config because access was denied"

This is an ASP.NET YSOD. I am not sure why ASP.NET is getting involved at all as it's a static .jpg file I'm requesting.

I tried turning on failed request tracing and this is the specific error:

• ModuleName WindowsAuthentication
• Notification 2
• HttpStatus 500
• HttpReason Internal Server Error
• HttpSubStatus 0
• ErrorCode 0
• ConfigExceptionInfo
• Notification AUTHENTICATE_REQUEST
• ErrorCode The operation completed successfully. (0x0)

If I change the "Physical Path Logon Type" from ClearText to Network. I get the following IIS error:

HTTP Error 500.19 - Internal Server

Error The requested page cannot be accessed because the related configuration data for the page is invalid.

Detailed Error Information

• Module IIS Web Core
• Notification BeginRequest
• Handler Not yet determined
• Error Code 0x80070005
• Config Error Cannot read configuration file due to insufficient permissions
• Config File \\?\UNC\INTRANET\FTP\test\web.config

• Requested URL http://test.mydowmain.com:80/uploads/images/ca49acf6-6174-412e-8abd-59fab983e931.jpg

• Physical Path \\INTRANET\FTP\test\images\ca49acf6-6174-412e-8abd-59fab983e931.jpg

• Logon Method Not yet determined

• Logon User Not yet determined
• Failed Request Tracing Log Directory C:\inetpub\logs\FailedReqLogFiles

This does not generate a failed request log strangely enough—I have set the failed request tracing to trace errors with error codes 400-999.

Also worth noting is that if I open the Configuration feature from within IIS, I see an access denied error.

I have exactly the same set up on my local dev machine to the same UNC path and the same user it works. Just on the test server it does not.

What am I doing wrong?

Answer 1

The fact that it's an ASP.net app is probably exactly what the issue is here. Your application pool identity has to have rights (not necessarily the IIS identity; by default, the app pool identity is the local Network Service account.) You also probably need to run caspol.exe on your IIS machine.

http://msdn.microsoft.com/en-us/library/cb6t8dtz%28v=vs.80%29.aspx

http://learn.iis.net/page.aspx/50/aspnet-20-35-shared-hosting-configuration/

%windir%\Microsoft.NET\Framework\v2.0.50727\caspol -m -ag 1.  -url "file://\\remotefileserver\content$\*" FullTrust

Answer 2

I resolved our issue by creating matching accounts on both the web server and the unc server. I then modified the Application pool to run using that matching account not network service. This gave me the flexibility to sync the password on both servers without affecting other network service dependent functions.

Answer 3

I had the same problem on IIS 7.5 I found the solution to be:

1. Create a local user on the server with the share
2. Create the network Share, giving the user created in step 1 the desired permissions. Windows will set up the permissions for the user you have specified
3. Go to the virtual directory on IIS and open the "advanced settings"
4. Enter the URL in physical path for the network share as \\<servername>\<sharename>
5. click in Physical Path Credentials; add the credentials for the user created in step 1

Answer 4

If this shared source is not an application (e.q. an image folder), Try to configure the virtual directory to be ignored by the root application which includes the virtual directory (in my case I've completed this by changing the root app pool type as Classic instead of Integrated mode). But if There is an application in the shared point then you may follow the way @mfinni stated.

Answer 5

You might check to ensure the account that IIS is running under has proper/needed rights to the troublesome UNC.

Answer 6

Just had the same issue with a non-domain web server accessing some domain resources using a domain account. We were getting strange behavior ("test credentials" would fail even though we knew credentials were right, we could see folders and files in content view, but couldn't "browse" them). Solution was to create a local user on the machine with the same name as the domain user.

I'm thinking this is what would have happened if the web server were a member of the domain, and the local user was necessary to get at some local resources (config?) in order to map the virtual.

Hope that helps someone.