Hi,
I am currently observing some non-deterministic behavior with setting filesystem permissions through Octopus Deploy.
The setup in question involves a Windows Server 2012 R2 machine, with it’s inetpub folder moved to a drive separate to the system drive, D. In addition, this drive has been stripped of any permissions except for the default ones set for SYSTEM and Administrators. IIS websites run under their respective app pool SIDs.
As part of the deployment process for the (Umbraco-based) websites, there is a step following the the built-in Deploy NuGet package step, which grants appropriate permissions to the correct SID.
The crux appears to be that, even with the SID having Full control for the entire web root folder (with inheritance enbabled), and the permissions can observably be verified through both the Windows Explorer UI as well as programmatically via PowerShell, some deployments made to (to non-extant websites) causes the website not being able to run, due to insufficient permissions. Stopping and starting both the application pool as well as the website does not appear to alter the result, nor does rebooting the OS itself.
To summarise, it would appear that given the same process and the same input, there is a different end result in terms of permissions. Moreover, the permissions observed on the filesystem is not always consistent with the apparent runtime behaviour of either the application or IIS itself.
I have attempted a vast number of methods of setting the permissions, including community-contributed deployment steps from Octopus Deploy, custom PowerShell code, custom C# code and setting permissions via the PowerShell console.
Does this sound familiar to anyone, and if so, do you have any hints regarding what may be the cause?
Thank you,
Martin