0XC00000CA: Network Access Denied Fix That Works

You're trying to open a shared folder on a Windows server from your PC, or maybe you're mapping a network drive. Suddenly you get the 0XC00000CA error — STATUS_NETWORK_ACCESS_DENIED. That blue shield icon pops up, or you see the error in the Event Viewer under System > Security with Event ID 4625 or 5140.

Had a client last month whose bookkeeper couldn't access the accounting share on a Windows Server 2019 box. She'd been working fine for months, then one day — gone. The error? Exactly this one.

Here's what's happening under the hood: Windows uses SMB (Server Message Block) protocol to share files and printers. The error 0XC00000CA means the request was received by the server but rejected — either the user credentials don't match, the share permissions are too restrictive, the firewall is blocking the port (445 for SMB), or the network profile is set to Public instead of Private. It's a permission or connectivity issue, not a hardware failure.

Root Cause

Three things cause this 90% of the time:

• Incorrect credentials — the username or password you're using doesn't have rights on the share.
• SMB protocol mismatch — older Windows versions (like XP or Server 2003) use SMB1, but modern Windows 10/11 and Server 2016+ often disable it.
• Windows Firewall blocking — the inbound rule for file and printer sharing is off.

Less common: the guest access policy is disabled, or the network is set to Public (which blocks file sharing by default).

The Fix — Step by Step

Step 1: Verify Credentials and Permissions

This is the first thing to check, and it's where most people waste time. Don't guess — confirm:

1. On the server or machine hosting the share, open Computer Management (right-click This PC > Manage).
2. Go to System Tools > Shared Folders > Shares.
3. Right-click your share, choose Properties, then click Share Permissions.
4. Make sure the user or group (like Domain Users or Everyone) has at least Read permission.
5. Now check the Security tab (NTFS permissions). That's separate from share permissions. If the user doesn't have NTFS access, you get this error even if share permissions are wide open. Add the user or group with Read & Execute or Modify as needed.

Real scenario: That bookkeeper client? The IT guy had changed the NTFS permissions on the parent folder, removing her group. Share permissions were fine. One checkbox fix.

Step 2: Check SMB Protocol Version

If you're connecting from a newer Windows 10 build (1709 or later) to an older device that only supports SMB1, you'll hit this error. SMB1 is disabled by default for security reasons.

On the server (the one hosting the share), open PowerShell as admin and run:

Get-SmbServerConfiguration | Select EnableSMB1Protocol

If it returns False, and the client machine is old (like Windows 7 or XP), you have two options:

• Enable SMB1 on the server (not recommended — security risk).
• Upgrade the client to a newer OS that supports SMB2 or SMB3.

To enable SMB1 temporarily (for testing only):

Set-SmbServerConfiguration -EnableSMB1Protocol $true

Then restart the server or the Server service. But seriously, don't leave it on. I had a client who got infected with WannaCry because they left SMB1 enabled for a legacy printer. Bad idea.

Step 3: Firewall Rules

Windows Firewall can block SMB traffic. Open Windows Defender Firewall with Advanced Security on the server. Look for the inbound rules named File and Printer Sharing (SMB-In). Ensure it's enabled for the appropriate profile (Domain, Private). If you're on a workgroup, it should be enabled for Private.

If the rule is there but disabled, enable it. If missing, create a new rule:

1. Click Inbound Rules > New Rule.
2. Select Port > TCP > Specific local ports: 445.
3. Allow the connection.
4. Apply to Domain and Private profiles.
5. Name it SMB Allow.

On the client side, also ensure that outbound rule for SMB is not blocked (usually allowed by default).

Step 4: Network Profile — Must Be Private

If your network is set to Public, Windows blocks file sharing. On the client machine:

1. Go to Settings > Network & Internet.
2. Click your Wi-Fi or Ethernet connection.
3. Set the network profile to Private.

On the server, do the same. This is a common one — especially on Wi-Fi networks where Windows auto-detects as Public.

Step 5: Check Guest Access Policy (Windows 10/11 Pro)

Microsoft tightened guest access in newer builds. Open Local Group Policy Editor (gpedit.msc) on the server:

• Navigate to Computer Configuration > Administrative Templates > Network > Lanman Workstation.
• Set Enable insecure guest logons to Enabled.

This allows older devices or non-domain machines to connect. Only do this if you trust the network.

If It Still Fails

Check the Security tab on the share's root folder and confirm the user has both share and NTFS permissions. If you're using mapped drives, try accessing via UNC path directly (\\server\share) — if that works but a mapped drive doesn't, the drive mapping is stale. Delete and remap.

Also, verify that the Server service is running on the host. Run services.msc, look for Server — should be Running and set to Automatic. If it's stopped, start it manually and set to Automatic.

Last resort: check the Event Viewer on the server for Security logs around the time of the failure. Look for Event ID 4625 (logon failure) or 5140 (share access attempt). The details will tell you the exact account that failed — often a clue you can't get from the error message alone.

I've seen this error a dozen times. Nine times out of ten, it's a permissions oversight or a firewall rule that got toggled by a Windows update. Start with permissions, then firewall, then SMB. You'll be back online in under 10 minutes.