Possible causes for Directory.CreateDirectory throwing UnauthorizedAccessException on shared host

Question

I'm currently working on an ASP.NET 3.5 / IIS7 app for which I'm using WinHost as a temporary hosting environment. I'm having some dramas with what I believe are permissions issues and the ticketing process has just reached "you're on your own" stage.

Here's what I'm trying to do:

var dir = Server.MapPath("~/MyFolder/NewPath");
Directory.CreateDirectory(dir);

And here's the response I'm getting:

Access to the path 'E:\web\MyAccount\MyFolder\NewPath' is denied.

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 path 'E:\web\MyAccount\MyFolder\NewPath' is denied.

The stack trace shows the CreateDirectory line failing. The app runs fine locally and the identity the app pool is running under has write access to the "MyFolder" path. In both environments, the trust level is set to "Full".

The guidance from WinHost is:

By default the asp.net user has full permissions to your site.

Looking further into it, WindowsIndentity.GetCurrent().Name returns "W02\aspnet_17884" which appears to be an account specific identity. My feeling is that this account does not have access to write to the file system of the app but when I prompted WinHost on this I received:

The problem you are running into is related to your application configuration.

and

What I'd recommend doing is registering and then posting your question in the DiscountASP.NET Community Forum

Which is obviously why the question is now on Stack Overflow :)

Can anyone suggestion any app level configuration changes? Is this more likely a permissions issue on the hosting site? Thanks.

Update: I've also put the question up on the WinHost forum.

Answer 1

And the answer is... web deploy broke it. Actually, the answer is strictly that the permissions simply weren't there (as expected), but the cause appears to be that web deploy somehow removed the write permissions. I can see this from the perspective of web deploy having the ability to publish ACLs, but why WinHost allows this to manipulate the permissions of the directory containing the website is beyond me.

Further info on my question (and WinHost's response), is on their forum under the thread No write access to file system.