When you encounter "Access is denied" errors while trying to modify permissions on Windows Server 2008, despite having administrator privileges, you're facing a multi-layered security challenge. The situation becomes more complex when dealing with IIS-hosted content and version control systems like Mercurial.
From my troubleshooting experience, these are the most common offenders:
1. Inherited permissions from parent folders
2. File/folder ownership issues
3. Process locks (especially from IIS worker processes)
4. Read-only attributes that keep reappearing
5. System-protected files (common in version control folders)
Here's the complete workflow I've developed through numerous server admin sessions:
1. Take Ownership First
Run Command Prompt as Administrator and execute:
takeown /f "C:\your\directory\path" /r /d y
icacls "C:\your\directory\path" /grant administrators:F /t
2. Deal with IIS Locking
Create a PowerShell script to handle IIS processes:
$iisProcesses = Get-WmiObject Win32_Process | Where-Object {
$_.CommandLine -like "*w3wp*" -and $_.CommandLine -like "*yourSitePoolName*"
}
foreach ($process in $iisProcesses) {
Stop-Process -Id $process.ProcessId -Force
}
iisreset /stop
# Perform your permission changes here
iisreset /start
3. Handle Stubborn Read-Only Attributes
For files that keep reverting to read-only:
attrib -R "C:\path\to\directory\*" /S /D
# Combine with permission reset
icacls "C:\path\to\directory" /reset /T /C /L /Q
The .hg directory often contains files with special protection flags. Try this sequence:
# First, disable Mercurial's internal locking
hg --config ui.foo=bar status
# Then apply permissions
icacls ".hg" /grant "NT AUTHORITY\SYSTEM:(OI)(CI)(F)" /T
When standard methods fail, dig deeper with these techniques:
# Check effective permissions
accesschk.exe -accepteula -uvws "Everyone" "C:\path"
# View all handles to files
handle.exe -accepteula "C:\path"
Remember to always test changes in a staging environment before applying to production servers. Document each permission modification for future audits.
Even as local administrators, we've all encountered those frustrating moments when Windows Server 2008 stubbornly refuses permission changes with that generic "Access is denied" error. The situation becomes particularly tricky when dealing with web directories under IIS control or version control repositories like Mercurial (.hg folders). Let me walk through the complete diagnostic and resolution process.
Before attempting solutions, proper diagnosis is crucial:
# Check current permissions (PowerShell)
Get-Acl "C:\target\directory" | Format-List
# Find locking processes (Command Prompt)
handle.exe "C:\target\directory"
# Alternative using Process Explorer:
procexp.exe -nobanner
The web server often maintains stealthy handles on content directories. While iisreset helps, sometimes deeper cleanup is needed:
# Complete IIS service stop sequence
net stop was /y
net stop w3svc
# Verify no worker processes remain
tasklist /fi "imagename eq w3wp.exe"
For stubborn cases, we need to rebuild the permission structure:
# Take ownership first (Admin CMD)
takeown /f "C:\target" /r /d y
icacls "C:\target" /reset /t /c /l /q
Mercurial's .hg directories require special attention due to their internal locking mechanisms:
# Temporarily rename the VCS folder
ren "C:\target\.hg" "hg_temp"
# Apply permission changes
icacls "C:\target" /grant:r "Administrators:(OI)(CI)F" /t
# Restore the VCS folder
ren "C:\target\hg_temp" ".hg"
The read-only attribute toggle issue suggests deeper NTFS problems. This script helps:
# PowerShell attribute reset
Get-ChildItem "C:\target" -Recurse -Force |
Where-Object { $_.Attributes -match "ReadOnly" } |
ForEach-Object { $_.Attributes = $_.Attributes -band (-bnot [System.IO.FileAttributes]::ReadOnly) }
In rare cases, these registry values need adjustment:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"NtfsDisableLastAccessUpdate"=dword:00000001