Fix Windows Error 5: Find What’s Denying Access First

Windows error 5 (Access Denied) appears when a program or command lacks the necessary permissions to read, modify, or execute a file or folder. The fix is to identify exactly which account, security descriptor, or policy is blocking the action before changing any permissions, because blindly granting full control can create security holes. This article explains how to trace the source of the denial, then apply the minimum permissions needed.

What Error 5 Actually Means

Error 5 is the Windows translation of the C runtime error EACCES (permission denied). It is returned by the operating system when a process requests an operation that the security subsystem rejects. The rejection can happen at several layers:

NTFS permissions – the access control list (ACL) on the file or folder does not grant the current user the requested right (read, write, delete, etc.).
Share permissions – for network paths, the share-level permission may be more restrictive than the NTFS permission.
User Account Control (UAC) – the process is running with a standard token and the operation requires administrator elevation.
Ownership – the current user is not the owner and does not have the right to change permissions (WRITE_DAC).
Group Policy or registry restrictions – policies may block access to specific paths or settings.
Antivirus or security software – some security products intercept file operations and deny them.

Because the error message rarely says which layer failed, you must investigate before changing anything. Changing permissions without knowing the cause can leave the system vulnerable or break applications that rely on restricted access.

Why You Shouldn’t Just Grant Full Control

Many online guides tell you to take ownership and grant Everyone full control. That is a bad idea for several reasons:

It removes the security boundary that protects the file from malware and unauthorized users.
It can break Windows components if you change permissions on system folders (e.g., C:\Windows).
It may not even fix the problem if the denial comes from UAC or a policy, not the ACL.
It makes it impossible to audit who accessed the file later.

The correct approach is to find the specific permission that is missing and grant only that right to the specific account that needs it.

Step-by-Step: Trace the Denial Before Changing Permissions

Reproduce the error and note the exact path – run the command or program again and write down the full file or folder path. If it is a registry key, note the key path.
Check if the process is elevated – if you are running an admin command prompt, it still may not have full rights if UAC is set to always notify. Try right-clicking the program and selecting “Run as administrator.” If that fixes it, the issue is UAC, not NTFS permissions.
Inspect the ACL – right-click the file/folder → Properties → Security tab. Click “Advanced” to see the effective permissions for the current user. Look for the specific right that is denied (e.g., “Modify” is missing).
Check the owner – in the Advanced Security settings, the owner is shown at the top. If the current user is not the owner and the ACL grants nothing to them, you may need to change ownership first (but only if you have the right to do so).
Use the Effective Access tab – in the Advanced Security window, select “Effective Access,” click “Select a user,” enter the account that is getting the error, then click “View effective access.” This shows exactly which permissions are granted or denied for that account.
Check share permissions if it is a network path – for a UNC path like \\server\share, right-click the share on the server, go to Sharing → Advanced Sharing → Permissions, and compare with NTFS permissions. The effective permission is the intersection of both.
Look for deny entries – explicit “Deny” entries in the ACL take precedence over “Allow.” If there is a deny entry for the user or a group they belong to, that is the cause.
Review group membership – the user may be in a group that is denied access. Use whoami /groups in a command prompt to see all group memberships.
Test with a different account – create a temporary test user, grant them the same permissions, and see if the error persists. This isolates whether the problem is account-specific.

Common Scenarios and Their Specific Fixes

Different causes require different fixes. Here are the most common situations and what to do:

Access denied when copying to a system folder (e.g., Program Files) – This is usually UAC. Run the copy command from an elevated command prompt, or change the target folder’s permissions only if you are a developer and need to write there regularly.
Access denied when running a scheduled task – The task may be configured to run as a user that does not have “Log on as a batch job” rights. Open Task Scheduler, right-click the task → Properties → General, and check the “Run whether user is logged on or not” option, or change the user to one with the right.
Access denied when accessing a network share – Check both share and NTFS permissions. Often the share permission is “Read” only, while NTFS allows “Modify.” The effective permission is the most restrictive.
Access denied when deleting a file – The file may be marked read-only, or the user lacks “Delete” permission. In the Security tab, check if “Delete” is allowed. If the file is read-only, right-click → Properties → uncheck Read-only.
Access denied on a registry key – Use Regedit, right-click the key → Permissions, and grant the current user “Full Control” only if you are sure it is safe. Better, grant only the specific value you need to modify.
Access denied when running a .bat or .ps1 script – Execution policy may block PowerShell scripts. Run Get-ExecutionPolicy and if it is “Restricted,” use Set-ExecutionPolicy RemoteSigned (requires admin). For .bat files, make sure the file is not blocked (right-click → Properties → Unblock).

Tools to Identify the Blocking Rule

Windows has built-in tools that can help you pinpoint the exact denial:

Effective Access tab – as described above, this is the fastest way to see which permissions are missing for a specific user.
Process Monitor (ProcMon) – from Microsoft Sysinternals, this tool logs every file system operation and shows the “ACCESS DENIED” result with the exact path and the user. It is the gold standard for diagnosing error 5.
icacls – command-line tool to view and modify ACLs. Run icacls "C:\path" to see the current ACL. It also supports /grant and /remove.
whoami /all – shows all group memberships and privileges for the current user.
PowerShell Get-Acl – Get-Acl "C:\path" | Format-List gives a readable ACL output.

When You Do Need to Change Permissions

After you have identified the specific missing right, grant only that right to the specific account. For example, if a service account needs write access to a log folder, do this:

Right-click the folder → Properties → Security → Edit.
Click “Add” and type the account name.
Check the “Modify” box (which includes write and delete) or only “Write” if that is all that is needed.
Click OK and test.

If the user is not the owner and you need to change permissions, you must first take ownership. Right-click → Properties → Security → Advanced → Change owner. Then you can modify the ACL. Only do this on files you own or are responsible for.

Frequently Asked Questions

Why do I get error 5 even when I am an administrator?

Being an administrator does not mean you have full access to everything. UAC splits your token into a standard token and an elevated token. If you run a program without elevation, it uses the standard token, which lacks many rights. Also, some folders have ACLs that do not include Administrators, or they have explicit deny entries.

How do I find out which permission is missing?

Use the Effective Access tab in the file’s Advanced Security settings. Select the user account that is getting the error and click “View effective access.” It will show a list of permissions with “Granted” or “Denied.” The one that is denied is what you need to add.

Can I change permissions on system files without breaking Windows?

It is risky. System files (like those in C:\Windows) are protected by Windows Resource Protection (WRP). Even if you take ownership and change permissions, Windows may restore them automatically or the system may become unstable. Only do this if you are absolutely sure you need to modify a specific file, and back up the original permissions first.

What is the difference between share permissions and NTFS permissions?

Share permissions apply only when accessing the folder over the network. NTFS permissions apply both locally and over the network. The effective permission is the most restrictive of the two. So if the share allows “Full Control” but NTFS allows only “Read,” the user gets “Read.”

I get error 5 when running a command in cmd.exe even though I am admin. What now?

Right-click cmd.exe and select “Run as administrator.” If that still fails, check if the command is trying to write to a protected path. Use Process Monitor to see the exact operation that is denied.

Is it safe to grant “Everyone” full control to fix error 5?

No. It removes all security on that file or folder, allowing any user or malware to modify it. Always grant permissions to the specific account that needs them, and only the minimum rights required.

General steps for current mainstream versions; menus can differ by device and version. See the disclaimer or report an error.

More in this bed

The whole Tech How-To bed →