Opening a shared folder only to get a cryptic error message is one of the most frustrating networking problems in Windows. The error usually reads something like “Windows cannot access \\COMPUTER\SharedFolder” or “Check the spelling of the name. Otherwise, there might be a problem with your network.” I have spent hours troubleshooting this exact issue across home networks, small business setups, and enterprise domains, and the root cause is almost never what you expect on the first try.
If you are trying to figure out how to fix “Windows cannot access” errors on a shared folder, this guide walks you through every major cause and its fix. We cover permission conflicts, SMB protocol mismatches, firewall blocks, cached credential problems, DNS issues, and even the Windows 11 24H2 update that broke shares for thousands of users.
Shared folder access errors disrupt team collaboration, prevent file backups, and can bring productivity to a halt. They can also signal security misconfigurations that leave your network exposed. Fixing them correctly means understanding why each fix works, not just blindly following steps. That is exactly what this guide gives you.
Table of Contents
Quick Overview: What Error Are You Seeing?
Before diving into fixes, you need to identify which specific error variant you are dealing with. The error message on your screen tells you a lot about the underlying cause. Here is a reference table of the most common shared folder error codes and what each one typically means.
Error Code Reference Table:
- 0x80070035 — “The network path was not found.” Usually caused by DNS resolution failures, SMB protocol mismatches, or the target computer being unreachable on the network.
- 0x80070020 — “The process cannot access the file because it is being used by another process.” Indicates a file lock or service conflict, often related to offline files or antivirus scanning.
- 0x800704cf — “The specified network name is no longer available.” Typically points to network adapter driver issues, SMB disconnections, or workgroup mismatches.
- 0x80070005 — “Access is denied.” Points to NTFS or share permission problems. The credentials you used do not have the required access rights.
- Security policies block unauthenticated guest access — Windows 10 version 1709 and later block guest access to SMB shares by default. This is the most common error when connecting to older NAS devices or Samba servers.
If your error code is not listed above, do not worry. The fixes in this guide cover the full range of causes behind these errors. Work through them in order, and you will almost certainly resolve your issue.
How to Fix “Windows Cannot Access” Errors on a Shared Folder: Start Here
Start with this quick decision guide to route yourself to the right fix fast:
- If you get “Access is denied” or a permissions error — Go to Fix 1 (Share and NTFS Permissions).
- If Windows keeps prompting for a password you already entered — Go to Fix 2 (Clear Cached Credentials).
- If the computer does not appear in File Explorer at all — Go to Fix 3 (Enable Network Discovery).
- If you recently installed or updated antivirus software — Go to Fix 4 (Firewall Settings) and the Antivirus Conflicts section.
- If you see “security policies block unauthenticated guest access” — Go to Fix 5 (SMB Protocol Conflicts).
- If you get “network path was not found” (0x80070035) — Go to Fix 6 (DNS and Network Path).
- If nothing above applies or fixes seem random — Go to Fix 7 (Reset Network Stack) and Fix 8 (Workgroup and DNS).
Understanding Why Shared Folder Access Fails
Windows uses the Server Message Block (SMB) protocol to access shared folders over a network. When you type a UNC path like \\SERVER\Share into File Explorer, a chain of events kicks off. Windows first resolves the computer name or IP address, then negotiates the SMB protocol version, authenticates your credentials, checks firewall rules, and finally validates your share and NTFS permissions. Any single failure in that chain produces a “Windows cannot access” error.
That is why two different users on the same network can have completely different experiences. One user might have cached credentials that are stale, while another hits an SMB version mismatch. A third user might have a third-party firewall silently blocking TCP port 445. Understanding this chain helps you narrow down the problem instead of guessing.
Share Permissions vs NTFS Permissions
One of the most common sources of confusion is the difference between share permissions and NTFS permissions. Both control access to the same shared folder, but they operate at different levels and Windows enforces the most restrictive combination of the two.
Share permissions control access at the network share level. They determine who can connect to the share over the network. The three levels are Read, Change, and Full Control. Share permissions do not care about local file system rights.
NTFS permissions control access at the file system level. They determine what users can do with the actual files and folders on disk. NTFS permissions are much more granular, with options like Modify, Write, Read and Execute, List Folder Contents, and more.
When you access a shared folder over the network, Windows checks both sets of permissions and applies the most restrictive one. For example, if share permissions grant Full Control but NTFS permissions only grant Read, you effectively get Read-only access. Many “access denied” errors happen because one of these two permission layers was overlooked.
What Causes the “Windows Cannot Access” Error
The root causes fall into six broad categories:
- Permission conflicts — Share or NTFS permissions are misconfigured, or a deny rule is overriding an allow rule.
- SMB protocol mismatches — The client and server cannot agree on an SMB version, or SMBv1 is required but disabled.
- Network discovery and profile issues — The network profile is set to Public instead of Private, or network discovery is turned off.
- Firewall and antivirus blocks — Windows Defender or a third-party firewall is blocking SMB traffic on TCP port 445.
- Cached credential problems — Windows remembers an old or incorrect password in Credential Manager.
- DNS and name resolution failures — The computer name cannot be resolved to an IP address, often fixable by using the IP address directly.
Fix 1: Check and Fix Share and NTFS Permissions
Permission problems are the single most common cause of “Windows cannot access” errors on shared folders. I have seen cases where everything looks correct in the GUI but a hidden deny rule or broken inheritance is silently blocking access. Here is how to find and fix these issues step by step.
Step 1: Verify Share Permissions on the Host Computer
On the computer hosting the shared folder, right-click the shared folder and select Properties. Go to the Sharing tab and click Advanced Sharing. Make sure Share this folder is checked, then click Permissions.
Verify that the user or group trying to access the folder has at least Read permission. For collaboration folders, Change permission is typically needed. If you see Everyone with only Read and you want write access, add the specific user or group with Change permission.
Check for any explicit Deny entries. A Deny rule overrides all Allow rules, even for administrators. If a user or group is listed in the Deny column, remove that entry unless it is intentional.
Step 2: Verify NTFS Permissions
Still in the folder Properties window, switch to the Security tab. This shows the NTFS permissions. Click Advanced and make sure Enable inheritance is checked. Broken inheritance is a silent killer of shared folder access.
Look for the user or group that needs access. If they are not listed, click Add and grant them Modify or Read and execute permission. If they are listed but getting denied, check the Effective Access tab to see which permission is actually being applied.
One specific issue I have seen repeatedly: the “Everyone” group is granted share access but a specific user is denied in NTFS permissions. Windows applies the most restrictive permission, so the user gets locked out even though “Everyone” appears to have access. Always check both layers.
Step 3: Check Permissions with PowerShell
For a faster diagnostic, use PowerShell. Run the following command on the host computer to list share access permissions:
Get-SmbShareAccess -Name "YourShareName"
To check NTFS permissions on a folder:
(Get-Acl "C:\Path\To\Shared\Folder").Access | Format-Table IdentityReference, FileSystemRights, AccessControlType
If you see any entry with AccessControlType set to Deny, that is a likely culprit. Remove it with:
$acl = Get-Acl "C:\Path\To\Shared\Folder"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("USERNAME","FullControl","Deny")
$acl.RemoveAccessRule($rule)
Set-Acl "C:\Path\To\Shared\Folder" $acl
Fix 2: Clear Cached Credentials in Credential Manager
Windows stores network share credentials in Credential Manager. When you connect to a shared folder and enter a username and password, Windows remembers those credentials for future connections. The problem is that if the password changes on the host computer, or if you entered the wrong credentials once, Windows keeps using the stale cached entry.
This results in a frustrating loop where you know the password is correct but Windows keeps denying access or repeatedly prompting for credentials. I have seen this happen most often when a user changes their domain password and then cannot access any network shares.
Step 1: Open Credential Manager
Press Win + S, type Credential Manager, and open it. Switch to the Windows Credentials tab. Look under Windows Credentials and Generic Credentials for any entries related to the computer name or IP address of the share you cannot access.
Step 2: Remove Stale Entries
Click each relevant entry and select Remove. Do this for every entry associated with the problematic share. After removing all stale entries, try accessing the shared folder again. Windows will prompt you for fresh credentials.
Step 3: Alternative Command Line Method
You can also manage credentials from the command line using the cmdkey utility. To list all stored credentials:
cmdkey /list
To delete a specific credential:
cmdkey /delete:TARGET_NAME
To add a new credential:
cmdkey /add:SERVERNAME /user:USERNAME /pass:PASSWORD
After clearing and re-adding credentials, restart the Workstation service for good measure:
net stop workstation & net start workstation
Fix 3: Enable Network Discovery and File Sharing
If the host computer does not appear in File Explorer’s Network view, network discovery might be turned off. This is especially common after a fresh Windows install or after switching networks. Windows also assigns the Public network profile to unfamiliar networks, which disables most sharing features by default.
Step 1: Check Your Network Profile
Open Settings (Win + I) and go to Network and Internet. Click your active connection (Wi-Fi or Ethernet) and look at the Network profile type. If it is set to Public, change it to Private. The Public profile blocks network discovery and file sharing for security reasons.
On Windows 11, the path is Settings > Network and internet > Wi-Fi (or Ethernet) > [your network name] > Network profile type. Select Private network.
Step 2: Turn On Network Discovery
Open the Control Panel and navigate to Network and Sharing Center > Advanced sharing settings. Under your current profile (Private), toggle on:
- Network discovery — Turn on network discovery and enable automatic setup of network-connected devices.
- File and printer sharing — Turn on file and printer sharing.
Step 3: Configure Password Protected Sharing
In the same Advanced sharing settings window, look for All Networks at the bottom. Here you will find the Password protected sharing setting. If all computers on the network have password-protected accounts (which they should), keep this turned on.
If you are trying to access a share from a computer without a password, you need to either set a password on that computer or turn off password protected sharing. Turning it off is less secure but may be necessary for home network convenience.
Fix 4: Check Windows Defender Firewall Settings
The Windows Defender Firewall can block SMB traffic even when file sharing is enabled. The SMB protocol primarily uses TCP port 445 for direct hosted SMB, and older NetBIOS communication uses UDP ports 137 and 138 plus TCP port 139. If any of these ports are blocked by a firewall rule, you get a “Windows cannot access” error.
Step 1: Verify File and Printer Sharing Firewall Rule
Press Win + S, type Windows Defender Firewall, and open it. Click Allow an app or feature through Windows Defender Firewall on the left side. Scroll down and find File and Printer Sharing. Make sure it is checked for both Private and Public networks.
If the checkbox is greyed out, click Change settings first (requires administrator privileges), then check the boxes.
Step 2: Verify TCP Port 445 Is Open
From the computer trying to access the share, open PowerShell and run:
Test-NetConnection -ComputerName TARGET_IP -Port 445
If the result shows TcpTestSucceeded : True, port 445 is open and the firewall is not blocking SMB. If it shows False, a firewall is blocking the connection. Check both the Windows Defender Firewall and any third-party security software on the host computer.
Step 3: Create a Firewall Rule via PowerShell
If the File and Printer Sharing rule is missing or corrupted, recreate it with PowerShell. Run the following command as administrator on the host computer:
New-NetFirewallRule -DisplayName "File and Printer Sharing (SMB-In)" -Direction Inbound -Protocol TCP -LocalPort 445 -Action Allow -Profile Any
For NetBIOS ports, add:
New-NetFirewallRule -DisplayName "NetBIOS Name Service (UDP-In)" -Direction Inbound -Protocol UDP -LocalPort 137 -Action Allow -Profile Any
Fix 5: Resolve SMB Protocol Version Conflicts
SMB protocol mismatches are one of the trickiest causes of “Windows cannot access” errors. Windows 10 version 1709 introduced a security change that blocks unauthenticated guest access to SMB shares by default. Windows 11 24H2 tightened SMB security further, and many users found that previously working network shares suddenly stopped connecting after the update.
The SMB Version Landscape
Here is a quick comparison of the three major SMB protocol versions:
SMBv1 — The oldest version, introduced in the 1990s. It is insecure, vulnerable to attacks like EternalBlue, and disabled by default in Windows 10 version 1709 and later. However, many older NAS devices, printers, and Samba servers still require SMBv1 to function.
SMBv2 — Introduced with Windows Vista and Server 2008. Offers better performance and reliability than SMBv1. Most modern devices support SMBv2 at minimum.
SMBv3 — Introduced with Windows 8 and Server 2012. Adds end-to-end encryption and better security. Windows 10 and 11 use SMBv3 by default. SMB signing and SMB encryption are enabled by default in newer Windows versions for enhanced security.
Fixing “Security Policies Block Unauthenticated Guest Access”
This error appears when Windows blocks a guest (unauthenticated) connection to an SMB share. It is the most common error when connecting to older NAS devices, Samba servers, or computers that have password protected sharing turned off.
You have two options. The secure option is to enable password protection on the host device. The less secure option is to enable insecure guest logons on the client computer.
To enable insecure guest logons through the Registry Editor:
1. Press Win + R, type regedit, and press Enter.
2. Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
3. Find or create the DWORD value AllowInsecureGuestAuth.
4. Set its value to 1.
5. Restart the Lanman Workstation service or reboot.
To do the same via Group Policy Editor (Windows Pro and Enterprise):
1. Press Win + R, type gpedit.msc, and press Enter.
2. Navigate to: Computer Configuration > Administrative Templates > Network > Lanman Workstation.
3. Find Enable insecure guest logons and set it to Enabled.
4. Run gpupdate /force in an elevated command prompt.
Warning: Enabling insecure guest logons reduces network security. Only use this on trusted private networks and never on public networks or enterprise environments.
Fixing SMBv1 Requirements for Older NAS Devices
If you have an older NAS device or Samba server that only supports SMBv1, you need to enable the SMBv1 client on your Windows computer. This is a security risk, so only do this if you have no alternative.
To enable SMBv1 client via Windows Features:
1. Press Win + S, type Turn Windows features on or off, and open it.
2. Expand SMB 1.0/CIFS File Sharing Support.
3. Check SMB 1.0/CIFS Client.
4. Click OK and restart your computer.
Alternatively, via PowerShell:
Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Client
Warning: SMBv1 is vulnerable to ransomware attacks like WannaCry and EternalBlue. Enable it only if absolutely necessary and on isolated private networks. A better long-term solution is to update your NAS firmware or replace the device with one that supports SMBv2 or SMBv3.
Windows 11 24H2 Specific Changes
The Windows 11 24H2 update introduced stricter SMB security defaults that broke network share access for many users. Key changes include:
- SMB guest access is now hard-blocked and cannot be overridden with the
AllowInsecureGuestAuthregistry key in some configurations. - SMB signing is required by default, which can cause incompatibility with older Samba servers that do not support SMB signing.
- The update changed default firewall behavior for SMB traffic on some network profiles.
If you started seeing 0x80070035 errors after updating to Windows 11 24H2, the fixes in this section are the most likely solution. Check the SMB signing requirements on both the client and server, and ensure both sides support the same SMB version.
Fix 6: Resolve Error 0x80070035 (Network Path Not Found)
Error 0x80070035 means Windows cannot find the network path to the shared folder. This is fundamentally a name resolution or connectivity problem. The fix depends on whether you can reach the host computer at all.
Step 1: Try the IP Address Instead of the Computer Name
This is the single fastest diagnostic for 0x80070035 errors. If \\COMPUTERNAME\Share fails, try \\192.168.1.50\Share (using the actual IP address of the host computer). If the IP address works but the computer name does not, you have a DNS or NetBIOS name resolution problem.
To find the host computer’s IP address, open a command prompt on that computer and run ipconfig. Look for the IPv4 Address under your active network adapter.
Step 2: Add a Hosts File Entry
If the IP address works but the name does not, add a permanent entry in the hosts file to force name resolution. Open Notepad as administrator and open C:\Windows\System32\drivers\etc\hosts. Add a line at the bottom:
192.168.1.50 COMPUTERNAME
Save the file and try accessing the share by name again.
Step 3: Enable Function Discovery Services
Windows uses the Function Discovery services to find computers on the network. If these services are stopped or disabled, other computers will not appear in File Explorer. Open Services (Win + R, type services.msc) and make sure these services are running and set to Automatic startup:
- Function Discovery Provider Host
- Function Discovery Resource Publication
- SSDP Discovery
- UPnP Device Host
- DNS Client
- TCP/IP NetBIOS Helper
Start each service if it is stopped, and set the startup type to Automatic. Then try accessing the share again.
Fix 7: Reset the Network Stack
Sometimes the network stack itself becomes corrupted or misconfigured. This can happen after Windows updates, driver changes, or VPN software installations. Resetting the network stack is a catch-all fix that clears out problematic settings and forces Windows to renegotiate all network connections.
Open an elevated command prompt and run these commands one at a time, pressing Enter after each:
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns
netsh advfirewall reset
After running all commands, restart your computer. This reset clears cached DNS entries, resets TCP/IP settings to defaults, re-registeres network adapters, and restores Windows Defender Firewall to its default rules. You may need to reconfigure any custom firewall rules afterward.
I recommend this fix when nothing else works and the error seems random or intermittent. It has resolved stubborn 0x80070035 and 0x800704cf errors for me on multiple occasions.
Fix 8: Check Workgroup and DNS Settings
Computers on the same local network should be in the same workgroup to share files easily. A workgroup name mismatch is a surprisingly common cause of shared folder access problems, especially after renaming a computer or joining a domain.
Step 1: Verify Workgroup Name
Press Win + Pause/Break to open System Properties. Check the Workgroup or Domain field. All computers that need to share files should be in the same workgroup (usually WORKGROUP or MSHOME).
To change the workgroup, click Change settings next to the computer name, then click Change. Enter the correct workgroup name and restart the computer.
Step 2: Configure DNS and NetBIOS
If your network uses a custom DNS server, make sure it can resolve local computer names. In some setups, the DNS server only resolves internet addresses and not local hostnames. This causes name resolution to fail for network shares.
Open your network adapter properties and check the DNS server assignment. For home networks, using the router’s IP as the DNS server usually works. For business networks, ensure the DNS server can resolve internal hostnames.
Also, ensure NetBIOS over TCP/IP is enabled. Open the network adapter properties, double-click Internet Protocol Version 4 (TCP/IPv4), click Advanced, go to the WINS tab, and select Enable NetBIOS over TCP/IP.
Advanced: Group Policy and Registry Fixes
If the standard fixes have not resolved your issue, or if you are managing shared folder access in an enterprise environment, Group Policy and Registry Editor offer deeper configuration options.
Group Policy for Enterprise Environments
In domain environments, Group Policy Objects (GPOs) control many SMB and sharing settings. A restrictive GPO can block shared folder access for all domain-joined computers. Check the following GPO settings:
Open Group Policy Editor (gpedit.msc) and navigate to:
Computer Configuration > Administrative Templates > Network > Lanman Server
- Microsoft network server: Digitally sign communications (always) — If enabled, this requires SMB signing on all connections. Older clients that do not support signing will fail.
- Microsoft network server: Digitally sign communications (if client agrees) — This is the default and is generally safe.
Computer Configuration > Administrative Templates > Network > Lanman Workstation
- Enable insecure guest logons — Set to Enabled if you need guest access to legacy shares.
After making changes, run gpupdate /force to apply them immediately.
Registry Editor Fixes
Before editing the registry, create a backup. Open Registry Editor and select File > Export to save a copy of the current registry. Never skip this step.
Key registry locations for SMB and sharing configuration:
Lanman Workstation parameters:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
AllowInsecureGuestAuth(DWORD) — Set to 1 to allow guest access.RequireSecuritySignature(DWORD) — Set to 0 to disable mandatory SMB signing on the client side.
Lanman Server parameters:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
requiresecuritysignature(DWORD) — Set to 0 to disable mandatory SMB signing on the server side.enablesecuritysignature(DWORD) — Set to 1 to enable SMB signing when the client supports it.Smb1(DWORD) — Set to 1 to enable SMBv1 server (not recommended).
After making registry changes, restart the computer or restart the relevant services:
Restart-Service LanmanWorkstation -Force
Restart-Service LanmanServer -Force
SMB Signing and Encryption
SMB signing adds a cryptographic signature to each SMB packet to prevent man-in-the-middle attacks. SMB encryption (available in SMBv3) encrypts the entire data stream. Both are security best practices, but they can cause compatibility issues with older devices.
If you are having trouble connecting to a Samba server or NAS that does not support SMB signing, you may need to disable signing requirements on the Windows side. This reduces security, so only do it on trusted private networks.
Third-Party Antivirus and Firewall Conflicts
This is the one cause that almost no troubleshooting guide mentions, yet it is incredibly common in the real world. Third-party security software — especially Avast, AVG, Kaspersky, and Bitdefender — frequently includes its own firewall module that silently blocks SMB traffic on TCP port 445.
The Windows Defender Firewall rule we checked in Fix 4 is irrelevant if a third-party firewall is active. The third-party firewall overrides Windows Defender and applies its own rules. Even if File and Printer Sharing is allowed in Windows, the third-party firewall may block it.
How to Identify the Conflict
To test whether third-party antivirus is causing the problem, temporarily disable the security software’s firewall module. Most antivirus programs have a “pause protection” or “disable firewall” option in their settings. Disable it for 10 minutes and try accessing the shared folder.
If the share works with the firewall disabled, you have confirmed the conflict. Re-enable the firewall and configure an exception for SMB traffic.
How to Fix the Conflict
Open your antivirus or security software settings and look for firewall rules or exceptions. Add a rule to allow inbound and outbound traffic on:
- TCP port 445 (SMB direct hosted)
- TCP port 139 (SMB over NetBIOS)
- UDP port 137 (NetBIOS Name Service)
- UDP port 138 (NetBIOS Datagram Service)
If your antivirus has a specific file sharing or network trust setting, make sure your local network is marked as trusted. Many programs default to treating all networks as untrusted.
On Spiceworks and Reddit, I have seen this exact issue reported dozens of times. Users spend hours checking Windows settings only to discover that a recent antivirus update silently changed the firewall rules. If you recently updated or installed security software and shares stopped working, this should be one of your first checks.
Quick Troubleshooting Checklist
Use this checklist to methodically work through all possible causes. Try each step in order, testing access after each one.
- Ping the host computer — Open a command prompt and run
ping COMPUTERNAME. If the ping fails, you have a basic network connectivity issue. - Try the IP address — Replace the computer name with the IP address. If this works, it is a DNS problem.
- Check network profile — Ensure both computers are on a Private network profile.
- Clear Credential Manager — Remove any stale entries for the target computer.
- Verify share permissions — Ensure the user has at least Read access on the share.
- Verify NTFS permissions — Check the Security tab and look for deny rules.
- Check firewall rules — Ensure File and Printer Sharing is allowed through Windows Defender Firewall.
- Check third-party antivirus — Temporarily disable it to test for conflicts.
- Test SMB connectivity — Run
Test-NetConnection -ComputerName TARGET_IP -Port 445. - Enable network discovery services — Check that Function Discovery services are running.
- Check SMB guest access — If connecting to a NAS or Samba server, check the insecure guest logon setting.
- Verify workgroup name — Ensure all computers are in the same workgroup.
- Reset the network stack — Run netsh and ipconfig reset commands as a last resort
FAQ’s
How to fix you can’t access this shared folder?
How to fix Windows cannot access error?
How to fix error you don’t currently have permission to access this folder?
Why am I getting access denied on a shared folder?
How to fix 0x80070035 error after Windows 11 24H2 update?
Why can I access a share by IP but not by computer name?
Conclusion
Fixing “Windows cannot access” errors on a shared folder requires patience and a systematic approach. The key is to identify which specific error you are seeing, understand which part of the SMB access chain is failing, and apply the targeted fix. Start with the simplest solutions — try the IP address, clear cached credentials, check permissions — before moving to registry edits and network stack resets.
Remember that share permissions and NTFS permissions work together, and Windows applies the most restrictive one. Always check both layers. If you are connecting to an older NAS device, the SMB protocol version is likely your issue. If you recently updated to Windows 11 24H2, check the new SMB signing and guest access defaults.
If none of these fixes work, consider resetting your network configuration entirely or consulting your network administrator for domain-specific policies. With the steps in this guide, you now have a complete toolkit for resolving shared folder access errors on any Windows network.