Azure Service Principal with Contributor access to Azure Linux AppService has insufficent right to delete files

So we are deploying a new application to an existing Azure App Service (Linux) we were able to initially deploy fine but suspect our application doesn’t run because the previous prototype version of our application is still there.

So we changed the Process step for the Azure App Service deployment such that the following was configured

Remove Additional Files: Files in the destination that are not part of the deployment will be removed

Now when it comes to get rid of the unwanted files we get:

Unable to perform the operation (“Delete File”) for the specified directory (“xyz.BusinessService.dll”). This can occur if the server administrator has not authorized this operation for the user credentials you are using.
Error Learn more at:

Now the Azure Service Principal our deployments run under is a Contributor on the App Service however this does not seem to give it the necessary rights to get the job done. We are reluctant to make it the Owner of the App Service as it could then have the rights to do bad things like delete the App Service.

Any advice on what level / specific permissions the Service Principal requires to get the job done?



Hi @john2,

Thanks for getting in touch.

I always find this a little tricky to get right on Azure. Owner access is useful in some use cases, for instance in cases where you are spinning up and spinning down resource groups, Web Apps, Databases then you will definitely need more access than most are comfortable. I use Runbooks for my provisioning and destruction of Web Apps and I use Owner here so I can create these as and when I need to. You can see a sample of this on Octopus Samples using Guest Authentication. This is a sample where I provision and destroy the Infrastructure each day. This needs access to create Resource Groups, App Services, DB’s and then deploys the database and the code to the Web App.

An approach is to have multiple Azure Service Principals for different tasks. This does add a layer of complexity but having multiple ASP’s will mean you can select the correct account for the correct process.

One way to deal with this is to use a custom role in Azure that you can assign to your Service Principal. For this to be supported you would need to have Azure AD P1 or P2 and I’m not aware if this is something you could do. You can read more about this in the Azure Docs.

Another approach here is to use slots in Azure Web Apps and then switch the slot round as part of the deployment. You could deploy to a staging slot and then switch round the slots. This avoids adding additional permissions as you can deploy to an empty slot and then switch them round. The benefit with Slots is that you can create them using Azure PowerShell

#Remove the staging slot if it exists
Remove-AzureRMWebAppSlot -Name #{WebSite} -Slot Staging -ResourceGroupName #{ResourceGroup} -Force -ErrorAction Continue

#Create the staging slot
New-AzureRMWebAppSlot -Name #{WebSite} -Slot Staging -ResourceGroupName #{ResourceGroup}

So, as part of your deployment process, you create the Staging slot, then deploy to it and then switch it round at the end of the deployment. You can see how to do this using Using Deployment Slots with Azure Web Apps - Octopus Deploy.

Please let me know if you have any questions,



Thanks Derek,

Something I should add is that we do not have direct access over our App Services, ResourceGroups etc, a third party consultant manages then on our behalf, spinning them up and down on demand is not currently an option.

We do currently make high use of slots, we do deploy to a staging slot already then swap to production, however these slots already contain the problematic files. I will look to create a new slot and see if it contains the problematic files to begin with, if it does that won’t help. If they don’t then by doing some careful swaps may be able to get rid of problematic files.

If not it will be a case of determining exactly what permissions are required to delete the files with WebDeploy and see if we can apply those to the principal. Any further info Octopus could provide in this area would be appreciated.

Many thanks




Hi @john2,

Thanks for coming back to us.

When creating a slot it should start with an empty file structure which you can then populate with items from your Package. It may be worthwhile trying to create a slot that isn’t named Staging as this is a common naming pattern and I expect what might be happening is that the slot is never removed at the end of the deployment process and that’s why it contains files.

I’ve just tested this on one of my demo apps… I did the following:

  • Browsed to my App
  • Created a slot called Pre-Deployment
  • Browsed to Pre-Deployment Slot URL and confirmed the Microsoft default site loaded.
  • Tested Production Slot and confirmed the main site was working.
  • Switched slots and in the main URL, the default Azure Web App site loaded.

The slot switch worked as expected. It feels like the problem is that the slots are not empty and that’s why you’re seeing this issue.

Please let me know how you get on.




We have managed to get something working for this.

If we stop the slot we are deploying too then the deployment goes through, as Contributor.

This will do for us.

Thankyou for you assistance.



Hi @john2,

That’s great that you got it working.

Please let us know if we can help further.

Happy Deployments!