C:\ Not Accessible, Access Denied? Here's the Fix

Short answer: double-click This PC, click C:, and get "Location is not available — C:\ is not accessible. Access is denied." This almost never means your C: drive is failing. It means Windows is refusing that specific access attempt for a permissions, security-software, or Group Policy reason, and in the overwhelming majority of cases the drive itself, and your data on it, are completely fine. If you can still open Command Prompt and run dir C:\ successfully, that confirms it — the drive is readable, something is just blocking Explorer's particular way of asking for access.

That last check matters more than people give it credit for. A drive that's actually failing shows up differently: RAW file system, "the parameter is incorrect," or Disk Management showing it as unallocated. "Access is denied" on your system drive specifically is a security or permissions message, not a hardware one, and it deserves a different set of fixes than a failing disk does.

Confirm you can still read the drive before changing anything

Open Command Prompt (it doesn't need to be elevated for this first check) and run:

dir C:\

If that lists your folders normally, your NTFS permissions and file system are intact — Explorer's specific access path is what's blocked, most likely by a security setting, a Group Policy restriction, or User Account Control filtering rather than actual corruption. If dir also fails with access denied, move straight to the ownership and permissions repair below rather than troubleshooting Explorer settings, since something more fundamental is blocking access at the file-system level.

Why does this happen on the system drive specifically?

Access-denied errors on external and secondary drives are common and usually come down to a drive being used across two different Windows installs or user accounts with mismatched NTFS permissions. The C: drive throwing this error is less common and points toward a narrower set of causes: a Group Policy or local security policy restricting drive access, an antivirus or endpoint protection tool actively blocking Explorer's access attempt, damaged security descriptors on the drive's root folder (which can follow a failed in-place upgrade or an interrupted permission change), or in rarer cases, a UAC token issue where your admin account's elevated permissions aren't being applied to the request Explorer is making.

Symptom-to-fix reference

What you're seeing	Confirming check	Fix
Access denied in Explorer, but dir C:\ in Command Prompt works fine	CMD test above succeeds	Check Group Policy drive-restriction settings first
Access denied everywhere, including Command Prompt	CMD test above also fails	Reset NTFS permissions on C:\ with icacls (see below)
Started right after installing or updating security software	Temporarily disabling it (if policy allows) restores access	Check the security tool's drive/folder protection settings
Started after a failed or interrupted Windows Update	Windows Update history shows a failed or rolled-back install around that time	Reset permissions with icacls, then re-run Windows Update
Happens for one user account but not others on the same PC	A second admin account can access C:\ normally	UAC token/profile issue — test with a temporary admin account
Also seeing "the parameter is incorrect" or drive shows as RAW	Disk Management shows abnormal file system or partition state	Stop — this isn't a permissions issue, back up data before anything else

Rule out Group Policy first

This step gets skipped constantly, and it's the least invasive one on the list. Press Win+R, run gpedit.msc (skip this on Windows 11 Home, which doesn't include the Group Policy Editor — go straight to the permissions fix below instead), and navigate to User Configuration → Administrative Templates → Windows Components → File Explorer. Look specifically at Prevent access to drives from My Computer and Hide these specified drives in My Computer. If either is enabled and includes your C: drive, that's your cause, and it's a one-click fix: set it to Not Configured or Disabled, run gpupdate /force from an elevated Command Prompt, and sign out and back in.

This setting is sometimes applied deliberately on managed or shared PCs to restrict casual browsing of the system drive. If you're on a work or school machine and this is intentional IT policy, changing it yourself may violate whatever compliance reason it was set for in the first place — check with whoever manages the device before overriding it.

Check for a security-software block

Some antivirus and endpoint protection tools include a "controlled folder" or ransomware-protection feature that blocks unrecognized processes — sometimes including Explorer itself, after an update changes its file signature slightly — from accessing protected areas of the drive. If you're running Windows Security's own Controlled Folder Access, check it at Windows Security → Virus & threat protection → Manage ransomware protection → Controlled folder access, and review the list of allowed apps. If you're running third-party endpoint protection, check its quarantine or blocked-actions log for anything referencing explorer.exe or a drive-access attempt around the time this started. Don't disable your security software entirely to test this — check its specific logs and allow-list settings first.

Reset permissions with icacls — the safer alternative to full ownership takeover

If Command Prompt itself can't read C:\, or Group Policy and security software are both ruled out, the underlying NTFS permissions on the drive's root are likely damaged. From an elevated Command Prompt:

icacls C:\ /reset /T /C /Q

/reset restores permissions to their inherited defaults, /T applies it recursively, /C continues past files it can't touch instead of stopping, and /Q suppresses per-file success messages so you're not staring at a scrolling wall of text for the next twenty minutes. Reboot after this completes. Expect it to take a while on a drive with a lot of files — this is walking the entire tree.

This is deliberately different advice from the most common fix you'll find searching for this error, which is takeown /f C:\ /r /d y followed by granting your user full control. I'd avoid that specific combination on the system drive. Taking ownership of the entire C:\ tree hands your user account ownership of files that Windows expects TrustedInstaller and SYSTEM to own — core OS folders under Windows and Program Files rely on that ownership structure for update servicing and security boundaries to work correctly. I've seen it "fix" the access-denied message and then cause Windows Update or app installers to behave strangely weeks later, because ownership on system folders got rewritten along with it. Resetting permissions to their inherited defaults with icacls solves the same access problem without reassigning ownership of files that were never meant to be user-owned.

Test with a second administrator account

If the icacls reset doesn't help, or you want to confirm this is account-specific before making system-wide changes, create a temporary local admin account and test there:

net user TempAdmin Str0ngP@ssTemp! /add
net localgroup Administrators TempAdmin /add

Sign out and into TempAdmin, then try opening C: from This PC. If it works fine there, the problem is tied to your original user profile or its token rather than the drive itself, which points toward a corrupted profile rather than a system-wide permissions issue — narrower and less risky to fix than anything touching the whole drive.

What I would not do

• Don't run takeown /f C:\ /r /d y against the whole system drive as a first move. It's the most-repeated advice for this error online, and it's more invasive than the problem usually calls for — reserve full ownership takeover for individual folders you know you need to reclaim, not the entire OS drive.
• Don't format the drive. This is a permissions and policy message, not file-system damage, in the vast majority of cases matching this exact wording. Formatting is for RAW or unallocated drives, not this.
• Don't disable your antivirus or endpoint protection entirely to test. Check its logs and allow-lists first — a full disable on a managed or work device may violate policy, and it's rarely necessary just to identify whether it's the cause.
• Don't skip the Command Prompt confirmation check. If you jump straight to permissions surgery without confirming whether CMD can read the drive, you can't tell afterward whether your fix actually did anything or whether the problem was already narrower than you assumed.

If nothing above resolves it

At that point, run chkdsk C: /f from an elevated Command Prompt (this will likely require a restart, since Windows can't lock its own boot drive while it's in use) to rule out file-system-level errors that can occasionally present with access-denied wording rather than the more typical corruption messages. If chkdsk comes back clean and you've ruled out Group Policy, security software, and profile-specific causes, an in-place repair install using current Windows 11 installation media — choosing "Keep personal files and apps" — resolves whatever's left in the security descriptor structure without a full reinstall. Back up anything irreplaceable first regardless of how safe the repair path is supposed to be.

Before you close this out

• Confirmed with dir C:\ in Command Prompt whether the block is Explorer-specific or system-wide
• Checked Group Policy's drive-restriction settings (skip on Windows 11 Home)
• Reviewed security software logs for a blocked access attempt
• Used icacls /reset rather than full ownership takeover on the system drive
• Tested with a second admin account to rule out a profile-specific cause
• Ran chkdsk before considering a repair install