Is this most likely an NTFS ACL/ownership issue, or could w3wp.exe be holding an exclusive lock on the file while the application is writing to it?

Asked 2 days ago Updated 2 days ago 66 views

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?

1 Answer


1

In this case it turned out to be an NTFS ownership/ACL issue, not a w3wp.exe file lock.

The evidence for that:

  • Running icacls on the file before the fix showed the current owner/ACL did not include my account (or Administrators) with sufficient rights.
  • Running 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).
  • The error also matches the classic Windows behavior for ACL-denied access: "You do not have permission to open this file. See the owner of the file or an administrator to obtain permission." A sharing violation from an active lock typically surfaces a different message (e.g., "The process cannot access the file because it is being used by another process," or "This file is open in another program").

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:

  1. Run icacls <file> — if your account/Administrators isn't listed with at least Read, it's an ACL/ownership problem → fix with takeown + icacls /grant.
  2. If ACLs look fine but you still get an access error, check for an active lock using Resource Monitor (CPU tab → Associated Handles → search filename) or Sysinternals 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).

Write Your Answer