29

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 no errors with deployment. I now receive a "ERROR_INSUFFICIENT_ACCESS_TO_SITE_FOLDER" error when publishing the website application.

The only way for me to successfully update the website is stop the Web App on Azure, then execute a Publish for the Web Application via Visual Studio. But this can be an issue if users are currently using the system. I don't really want any downtime while updating the website.

The full error is as follows:

msdeploy error ERROR_INSUFFICIENT_ACCESS_TO_SITE_FOLDER: Web deployment task failed. (Unable to perform the operation ("Create File") for the specified directory ("D:\home\site\ wwwroot\bin\Domain.DbFactory.dll"). This can occur if the server administrator has not authorized this operation for the user credentials you are using. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_INSUFFICIENT_ACCESS_TO_SITE_FOLDER.)

How would I go about authorising these permissions?

I have also reset my publishing profile on Azure, and downloaded a fresh profile to attempt it again. But no luck with that.

GEOCHET
  • 21,119
  • 15
  • 74
  • 98
Steven van der Merwe
  • 608
  • 2
  • 7
  • 10

8 Answers8

32

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
David Ebbo
  • 42,443
  • 8
  • 103
  • 117
  • Hi, it would happen with any of the published files to that web app. Whether it be a "Create" permission denied, or in the case of removing remote files on publish it would be a "Delete" permission denied. However, your advice has helped me manage the web app with the Kudu Console and get it going again by renaming the files. Thanks very much. – Steven van der Merwe Jan 06 '16 at 08:24
  • 5
    You can also Stop the website in the Azure Portal before publishing it, and restart it after. Of course the website will be unavailable but that can be an option during development. – Costo Mar 16 '16 at 15:29
  • I just had this issue. Despite complaining about the file on the remote Azure server, simply restarting VS fixed the problem. – Rory McCrossan Nov 22 '17 at 15:22
  • @Costo I stop website but same issue. Finally removed file from Kudu debug Console – Pawan Kotak Mar 23 '20 at 17:03
  • None of the solutions here helped me. The solution was instead to deploy to a new slot and then swap it into the production slot. – mbesso Jan 11 '22 at 15:21
30

For me the fix was to set the Remove additional files at destination setting to true.

I am on .NET 6 and just recently migrated from .NET Core 3.1 to .NET 6

enter image description here

Brendan Sluke
  • 857
  • 10
  • 11
  • Yes this worked for me too. – coderguy Dec 16 '21 at 14:50
  • Exact same scenario here. This worked!.. but why? Is it required for subsequent publishing? I had static content that needed to be copied out of the folder before publishing as it deleted this folder upon publishing. Then copied the data back in. – GisMofx Mar 02 '22 at 01:49
  • 1
    Yes this worked. Makes sense because I deployed a completely different project and files to the same app service. – Andrew Dec 03 '22 at 16:31
3

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.

Dan
  • 3,583
  • 1
  • 23
  • 18
2

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.

Simon_Weaver
  • 140,023
  • 84
  • 646
  • 689
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

sudipto das
  • 29
  • 4
0

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.

Alamakanambra
  • 5,845
  • 3
  • 36
  • 43
0

Mine was complaining about not being able to delete D:\home\site\wwwroot\newrelic\Extensions\JetBrains.Annotations.dll.

I couldn't delete it from Powershell in Kudu even after stopping the web app.

I had to update the the deployment pipeline with -enableRule:DoNotDeleteRule: enter image description here

David Klempfner
  • 8,700
  • 20
  • 73
  • 153
0

This happened to me when the IIS World Wide Web Publishing Service service had quit running on my server; I had to turn it back on manually.

codeMonkey
  • 4,134
  • 2
  • 31
  • 50