Access to path is denied from powershell script

Version, brand new install on new server for deploy and tentacle

In an attempt to remove extra config transformations (, I am running this script:

get-childitem .\ -include *.debug.config, *.staging.config, *.release.config -recurse | foreach ($) {remove-item $.fullname -force}

It does not seem to work. So, I opened a powershell prompt on the server and executed the script.
I got “access to the path is denied”.
So, using explorer, I went to delete the file and it prompted me that I will ‘need administrator permissions to delete the file’. I am an administrator and click continue and it of course is deleted.

Looking at file permissions, SYSTEM as well as COMPUTER\Administrators have full control. COMPUTER\Users have read only.

First issue is why cant the “run a powershell script” task remove this file?
Second issue is permissions. Typically I grant read access to the app-pool virtual user. In addition if website needs write permission to folders (log folders, upload folders, etc), I grant those on a folder level to this same user. In addition the IIS_IUSRS group is granted read only. This particular deployment is a rest service so there are no files to access, but if it was a normal website, not sure the permissions are setup correctly as IUSR (default anonymous user) does not have read right to these folders. Something like this should be done:

Allow inheritance of read permissions in subfolders and files inside this directory
ICACLS <path_to_root> /INHERITANCE:R
Remove users from being able to access this directory (Only admins should have full access to the web root folder)
ICACLS <path_to_root> /remove Users
Allow read access to the Application Pool on the Web page folder (f:\wwwroot\Demo)
ICACLS <path_to_site> /grant “IIS AppPool<app_pool_name>”:(OI)(CI)R

(Of course I cannot execute the above from powershell in octopus as I get access is denied as stated above)

As a further note, if the user as selected the Identity to be ‘application pool identity’, most likely the Anonymous user should be configured to use the ‘application pool identity’. (something like set-webconfigurationproperty /system.webServer/security/authentication/anonymousAuthentication -name userName -value “” )


Thanks for all the detailed feedback. It sounds like there’s a lot we can do to make this process smoother.

I’m not sure either why the script step can’t remove the config files you mention- does it produce any output? Writing the full path of each file being deleted to the console might help resolve any issues here.

I’ve created an issue here to track better permission assignments:

In the meantime, if you include a PostDeploy.ps1 PowerShell script in your package (mark it as Content in the Visual Studio project) you’ll be able to run the commands you’ve listed at deployment time.

There are some docs on scripting at: - let me know if I can help with more details.


Putting the same script in a postdeploy.ps1 did successfully run and remove the files, like you said it would.

I guess the permissions you are running your scripts from a deployment step are not the same as the one from the package.