Can’t Access Shared Folders or Map Network Drives from Windows 10 and 11 | Windows OS Hub

If you cannot open or map network shared folders on your NAS, Samba Linux server, computers with legacy Windows versions (Windows 7/XP/Server 2003) from Windows 10 or 11, most likely the problem is that legacy and insecure versions of the SMB protocol are disabled in the current Windows builds (SMB protocol is used in Windows to access shared network folders and files).

Microsoft is systematically disabling legacy and insecure versions of the SMB protocol in all recent versions of Windows. Starting with Windows 10 1709 and Windows Server 2019 (both in Datacenter and Standard editions), the unsafe SMBv1 protocol is disabled by default as well as anonymous (guest) access to network shared folders.

The specific steps to take depend on the error that appears in Windows when accessing a shared folder, and on the settings of the remote SMB server that hosts the network shares.

Can’t Access Shared Folder Because Security Policies Block Unauthenticated Guest Access

Starting with Windows 10 build 1709 Fall Creators Update (Enterprise and Education editions), users began to complain that when they tried to open a network shared folder on a neighboring computer, an error appeared:

Restoring Network Connections
An error occurs when you try to open a network folder:
An error occurred while reconnecting Y: to \\nas1\share
Microsoft Windows Network: You can’t access this shared folder because your organization’s security policies block unauthenticated guest access. These policies help protect your PC from unsafe or malicious devices on the network.

Moreover, on other computers with Windows 8.1, Windows 7, or Windows 10 with a build of up to 1709, the same shared network folders open normally. The point is that in modern versions of Windows 10 (build 1709+), the guest access to the shared folders using the SMBv2 protocol is disabled by default. Guest (anonymous) means access to a shared network folder without authentication. When accessing a network folder under a guest account over the SMBv1/v2 protocol, such methods of traffic protection as SMB signing and encryption are not used, which makes your session vulnerable to the MiTM (man-in-the-middle) attacks.

These changes are not applied on Windows 10 Home editions and the network access under the guest account is working fine.

If you try to open a shared network folder using the SMB v2 protocol under the guest account, the following error will appear in the Event Viewer of your computer (SMB client):

Log Name: Microsoft-Windows-SmbClient/Security  
Source: Microsoft-Windows-SMBClient
Event ID: 31017
Rejected an insecure guest logon.

This error says that your computer (client) blocks non-authenticated access under the Guest account.

In most cases, you can face this problem when accessing old NAS devices (usually guest access is enabled on them for ease of setup) or when opening shared folders on legacy Windows 7/2008 R2/Windows XP/2003 devices with anonymous (guest) access enabled (see the table of supported SMB protocol versions in different Windows editions).

Microsoft recommends changing the settings on a remote computer or NAS device that hosts the shared network folders. It is advisable to switch the network share to the SMBv3 mode. Or configure access with authentication if only the SMBv2 protocol is supported by the device. This is the most correct and safest way to fix the problem.

Disable guest access on the device where your shared folders are stored:

• NAS devices – disable guest access in the settings of your NAS device (depending on vendor and model);
• Samba server on Linux — if you are sharing a network folder with Samba on Linux, add the following string to the smb.conf configuration file under the section [global]: map to guest = never
  And restrict anonymous access in the shared folder configuration section: guest ok = no
• In Windows, you can enable sharing of network folders and printers with password protection via the Control Panel -> Network and Sharing Center -> Advanced sharing settings. For All Networks in the “Password Protected Sharing” section, change the value to the “Turn on password protected sharing”. In this case, anonymous (guest) access to the network shared folders will be disabled and you will have to create local users, grant them access permissions to the shared folders and printers and use these accounts to connect to the shared folders on a remote computer.

There is another way – you can change the settings on your Windows device to allow access to shared network folders under the guest account. This method should be used only as a temporary workaround (!!!), because access to folders without authentication significantly reduces your computer security.

To enable guest access from your computer, you need to use the Group Policy Editor (gpedit.msc). Go to the section: Computer Configuration -> Administrative templates -> Network -> Lanman Workstation. Find and enable the policy Enable insecure guest logons. This policy option determines whether the SMB client will allow an unsafe guest logon to the SMB server.

Update the Group Policy settings in Windows with the command:

gpupdate /force

In Windows 10 Home, which does not have a local GPO editor, you can make a similar change through the Registry Editor manually:

HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters “AllowInsecureGuestAuth”=dword:1

Or with these commands:

reg add HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters /v AllowInsecureGuestAuth /t reg_dword /d 00000001 /f
reg add HKLM\Software\Policies\Microsoft\Windows\LanmanWorkstation /v AllowInsecureGuestAuth /t reg_dword /d 00000001 /f

Can’t Connect to the File Share Because It’s Not Secure and Requires the Obsolete SMB1 Protocol

Another possible problem when accessing a network folder from Windows 10 is that only the SMBv1 protocol version is supported on the server-side. Since the SMBv1 client is disabled by default in Windows 10 1709+ when you try to open the shared folder or map a network drive, you may get an error:

You can’t connect to the file share because it’s not secure. This share requires the obsolete SMB1 protocol, which is unsafe and could expose your system to attack. Your system requires SMB2 or higher.

The error message clearly shows that the network shared folder only supports the SMBv1 client access protocol. In this case, you should try to reconfigure the remote SMB device to use at least SMBv2 (the correct and safe way).

If you use Samba server on Linux to share files, you can specify the minimum supported version of SMB protocol in the smb.conf file like this:

[global]
server min protocol = SMB2_10
client max protocol = SMB3
client min protocol = SMB2_10
encrypt passwords = true
restrict anonymous = 2

On Windows 7/Windows Server 2008 R2, you can disable the SMB 1 protocol and enable SMBv2 through the registry with the following PowerShell commands:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 -Type DWORD -Value 0 –Force
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB2 -Type DWORD -Value 1 –Force

On Windows 8.1/Windows Server 2012 R2, you can disable SMBv1, allow SMBv2 and SMBv3 with the following command (verify that a private or domain profile is used for your network connection):

Disable-WindowsOptionalFeature -Online -FeatureName "SMB1Protocol"
Set-SmbServerConfiguration –EnableSMB2Protocol $true

If your network device (NAS, Windows XP, Windows Server 2003) supports only the SMB1 protocol, you can enable a separate SMB1Protocol-Client feature on Windows 10/11 or Windows Server. But this is not recommended!!!

Log Name: Microsoft-Windows-SmbClient/Security
Source: Microsoft-Windows-SMBClient
Event ID: 32000
Description:  SMB1 negotiate response received from a remote device when SMB1 cannot be negotiated by the local computer.

If the remote device requires SMBv1 to connect, and this protocol is disabled on your Windows device, an error appears in the Event Viewer:

Run the elevated PowerShell prompt and verify that the SMB1Protocol-Client is disabled (State: Disabled):

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Client

Enable the SMBv1 client protocol (a reboot is required):

Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Client

You can also enable/disable additional features in Windows 10 and 11 from the optionalfeatures.exe. Expand SMB 1.0/CIFS File Sharing Support and enable the SMB 1.0/CIFS Client.

On Windows 10 1809 and newer, the SMBv1 client is automatically removed if it has not been used for more than 15 days (the SMB 1.0/CIFS Automatic Removal component is responsible for this).

In this example, I enabled only the SMBv1 client. Do not enable the SMB1Protocol-Server feature if your computer is not used by legacy clients as an SMB server to host shared folders.

After installing the SMBv1 client, you should be able to connect to a shared folder or printer without any problems. However, you should understand this workaround is not recommended, because it reduces the security of your computer.

Windows Cannot Access Shared Folder: You Don’t Have Permissions

When connecting to a shared network folder on a remote computer, an error may appear:

Network Error
Windows cannot access \\PC12\Share
You do not have permission to access \\PC12\Share. Contact your network administrator to request access.

When this error occurs, you need to:

1. Make sure that the user you are using to access the shared folder is granted access permissions on the remote share. Open the properties of the shared folder on the server and make sure your user has at least read permissions. Also,  you can check the SMB file share permissions on the remote host using PowerShell:
   Get-SmbShareAccess -Name "tools"
   Then check the NTFS folder permissions:
   get-acl C:\tools\ |fl  If necessary, edit the permissions in the folder and/or share properties;
2. Make sure you are using the correct username and password to access the network folder. If you’re not prompted for a username and password, try removing saved (cached) credentials for remote shares in Windows Credential Manager. Run the command rundll32.exe keymgr.dll, KRShowKeyMgr and delete cached credentials for the remote computer you are trying to access.
   The next time you connect to the shared folder, you will be prompted for a username and password. Specify the credentials to access the network shared folder on the remote computer. You can save it in Credential Manager or add it manually.

Other Fixes: Windows Cannot Access Shared Folders

This section provides additional ways to troubleshoot a problem opening network folders in Windows:

• Make sure that the remote computer allows incoming connections to shared network folders using the SMB protocol (TCP port 445). You can check the availability of port 445 on a remote computer using the Test-NetConnection command: Test-NetConnection -ComputerName HomePC212 -Port 445
  If the cmdlet returns TcpTestSucceeded : False, this means that access to the network folder on the remote computer is being blocked by the firewall. The connection may be blocked by an antivirus or firewall (third-party or built-in Windows Defender Firewall). If you are using Windows Defender, enable the File and Printer Sharing rule (Control Panel\System and Security\Windows Defender Firewall\Allowed apps\Allow apps to communicate through Windows Firewall) on the file share host for all three network profiles.
  Or create a firewall rule with PowerShell: New-NetFirewallRule -DisplayName "Allow_SBM-FileSharing_In" -Direction Inbound -Protocol TCP –LocalPort 445 -Action Allow
• If you cannot open mapped network drives (folders), try to remove saved cached credentials in Windows Credential Manager, delete mapped network drives (with the Net Use * /delete command) and reconnect them;
• Try to use the IP address of the remote computer instead of its name to access the folder. For example: Win+R -> \\192.168.12.20 -> Ok.
• Make sure your computers are joined to the same workgroup. The name of the workgroup on the computer can be found using PowerShell: Get-WmiObject Win32_ComputerSystem).domain
• Reset the TCP/IP stack settings and update the IP address on your computer:
  netsh int ip reset
netsh winsock reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew