PowerShell: access is denied
Documentation: Microsoft Learn
Check the calling identity, elevation and resource permissions when a PowerShell operation returns access denied.
What it means
The operation was denied for the current identity or security context. Check the requested action, resource permissions, elevation and any endpoint protection restrictions. An access-denied message alone does not identify which layer blocked the request.
Likely causes
- The calling account holds no write permission on the NTFS path
- The action needs an elevated token and the session is running unelevated
- A share permission is narrower than the NTFS permission on the same folder
- The target file carries the ReadOnly attribute
- Controlled folder access or another endpoint protection rule intercepts the write
Check
Run these checks before changing anything.
What these checks establish
whoami identifies the current account. An ACL listing shows permission entries, but effective access can also depend on group memberships, deny entries, elevation and share permissions. Test-Path is not a write-permission test.
Fix
Determine the specific operation and identity that were denied. For a share, inspect both share and filesystem permissions. Check the parent directory when creating a new file. Use elevation only when the task requires and permits it; otherwise assign the appropriate scoped access through the normal permission workflow.
Verify: Repeat the required operation under the intended identity, then verify the result. Do not use an administrator’s successful test as proof that the service account is fixed.
