1
Could the file access issue be caused by NTFS permissions/ownership, or by the IIS worker process (w3wp.exe) locking the file during writes?
Could the file access issue be caused by NTFS permissions/ownership, or by the IIS worker process (w3wp.exe) locking the file during writes?
In this case it turned out to be an NTFS ownership/ACL issue, not a
w3wp.exe file lock.
The evidence for that:
icacls on the file before the fix showed the current owner/ACL did not include my account (or Administrators) with sufficient rights.takeown /f <file> followed by icacls <file> /grant "Administrators":F immediately resolved the error — a live lock held by
w3wp.exe would not be fixed by an ownership/ACL change, since the file would still be open and inaccessible for writing/reading by any process until the lock was released (e.g., by the worker process closing the handle or the app pool being recycled).In CMD:
# Take ownership of the file
# This makes the current administrator the owner of the file.
takeown /f <file>
# Grant the local Administrators group full control over the file
# F = Full access (read, write, modify, delete, etc.)
icacls <file> /grant "Administrators":F
How to tell the difference in general, for anyone hitting this later:
icacls <file> — if your account/Administrators isn't listed with at least Read, it's an ACL/ownership problem → fix with
takeown + icacls /grant.handle.exe <filename>. If w3wp.exe shows up holding the handle, it's a live lock from the IIS worker process, not a permissions problem, and the fix is different (wait for it to release, or recycle the app pool if appropriate).