A note on setAcl provider behavior

Note: this is a cross-post from bilalaslam.com

Chances are if you are deploying an application using Web Deploy, you are using the setAcl provider. What is setAcl? It’s a provider that lets you set permissions on file system objects. Typically, this involves setting permissions on a sub-folder of your application, such as App_Data.

I recently had a customer contact me and I had to explain this particular behavior for setAcl. Let’s say you run this command:


msdeploy.exe -verb:sync -source:setacl -dest:setacl="Default Web Site",setacluser=ApplicationPoolIdentity,setaclaccess=Read

This command will give the ApplicationPoolIdentity Read access to the App_Data folder. Before it does that, however, it will clear existing permissions on the folder for the identity. This makes sense, since setAcl has to set the correct permissions and the only way to do that is to clear existing permissions for the identity. For example, if the ApplicationPoolIdentity had Read,Execute permissions before, now it will just have Read permissions.


  • It also seems that when we deploy from VS 2010 it clears ALL permissions on the folders and sets only the following.

    ApplicationPoolIdentity : Read
    DeployAccountIdentity : Full Control

    Is that a bug or a setting that we can disable for clearing all?

  • Correction: It seems the issue is that if the folder doesn't exist then it creates it with no ACL inheritance and then adds the couple of ACL entries. That causes a issue because no one has access to the folders, not even System or Admins. If there is a control panel it will error out trying to read the web.config file.

Comments have been disabled for this content.