Azure Web App Deployment error via msdeploy - ERROR_INSUFFICIENT_A CCESS_TO_SITE_FOLDER

Question

I have been deploying to my Azure Web App for about 4 months now, using msdeploy, and everything has been smooth sailing to upload the website. Until recently, there has been n

Answer 1

It was happening for me too when I was deploying from Octopus to an Azure Web App by stopping the instance. But the w3wp scm process was still using the file. So I had to kill it by going to Process Explorer.

Before killing it search the process which is using the file by searching from File Handle

Answer 2

Happens to me when I was messing up with App Service files through FTP. I probably deleted something important. Refreshing and restarting the App Service helped.

Answer 3

The error is a bit deceiving. This likely has nothing to do with permission, but is instead caused by files being in use.

Does it always happen with Gehs.DbFactory.dll, or is it sometimes other files? Also, is Gehs.DbFactory.dll a regular managed assembly, or native/mixed assembly?

Normally, all assemblies get shadow copied, so they are not locked in the bin folder. If if it's native, it could end up getting loaded in place.

Note that if that's the case, it's not Azure specific, and you'd likely have the same issue deploying anywhere. e.g. try deleting this file from your bin folder while running locally.

One way or another, you need to make sure that no file gets locked in place if you want to publish newer version.

If you can't find a way to do this, here is a technique that should let you publish without any downtime:

• using Kudu Console, go to your d:\home\site\wwwroot\bin folder
• Renaming the offending DLL, e.g. to Gehs.DbFactory.dll.old (renaming normally works even if you can't delete it)
• Do your publishing

Answer 4

I got the error (Unable to perform the operation ("Delete Directory") for the specified directory ("2_0_50727") on a deployment that had been working fine and suddenly broke.

If you're not paying attention '2_0_50727' looks like just a random number.

It turns out it was the folder aspnet_client\system_web\2_0_50727 which didn't even contain any files.

Based on the timestamp of this folder - and the fact that it was in ALL my web applications with this timestamp - it must have been created by Add / Remove Features when I made some changes to my IIS installed features. So whatever permissions that runs at is what this folder was created as.

As soon as I deleted it I was able to deploy again.

Answer 5

Same thing was happening to me when I added a new folder under Content in my project and then tried to publish. I just restarted the app on Azure and then it worked fine.