Windows 10 computer can’t connect to network shares (error: 0x80070035)

abasson

January 10, 2019

To start off, this article might be as helpful (or least helpful) like the rest of the articles on the internet about this topic. I will be detailing my (very frustrating) experience which I had with this issue and how I did resolve it. I hope you will find this article (or maybe pieces of it) helpful enough. Before you continue, the attempts to fix the issue and follow these instructions, you do so at your own risk. You will need to understand the basics of SMB v1, 2 & 3 as the issue is mostly caused by different SMB versions between your PC’s. (I assume when you attempt this fix you are familiar with IT-support or are a support technician yourself – I will not provide you with in-depth basic IT support).

To set the scenario: 1x Windows 10 Home build 1803 64-bit PC (HP ProDesk 600 G2 Desktop) which need to access a Windows Server 2008 R2 file share.

The Windows 10 PC gives a 0x80070035 error “Windows cannot access \\network-share” when trying to access the server and/or server share by making use of the FQDN and/or IP address of server. Error 53 is present when making use of the following command in CMD: net view “server-name“. When executing a ping command, the Windows 10 PC get replies from the server when pinging it using the IP as well as the FQDN. So the PC and Server can “see” each other, but isn’t accessible.

As you can see, this is the out-of-box experience without any changes being made to the Windows 10 PC nor the Windows 2008 R2 server. I am not going to go through the most basic of all network troubleshooting steps (like “are you on the same network subnet” and “did you restart the PC, server and router” or “did you disable the firewall or antivirus” etc.), as this article will only get too long and it is basic stuff which you should have checked and done first. I have broken down the steps into segments which I have tried until I could find a solution.

Windows Services to be set to Automatically Start:

The following services need to be set to automatically start in Windows 10 (Start -> Run -> services.msc):

Function Discovery Provider Host (fdPHost)
Function Discovery Resource Publication (FDResPub)
SSDP Discovery (SSDPSRV)
TCP/IP NetBIOS Helper (lmhosts)

Group Policy preventing insecure access:

In Windows 10 Pro, you can run the following command to open the Local Group Policy Editor:

Start –> Run –> gpedit.msc

If you run Windows 10 Home edition, you will get an error when trying to access gpedit.msc. This is due to some enterprise limitations of Windows 10 Home edition. But all is not lost. The guys from ITECHTICS.com have written a small batch file which you can download and run to install the Local Group Policy Editor in Windows 10 Home. You can download it HERE. When download is complete, run the file as an administrator, reboot your PC and access gpedit.msc.

Navigate to:

Computer Configuration –> Administrative Templates –> Network –> Lanman Workstation
Double-click on “Enable insecure guest logons” on the right-hand panel.
Enable the Policy, click on OK and reboot your computer

Confirm the SMB versions on both computers:

To check the SMB versions active on each computer, open command prompt again (as an administrator) and type the following command:

sc.exe qc lanmanworkstation

The result should look something like this:

Make a note of all the computers which gives you this issue, and the SMB versions they are running.

Enable SMB 1.0 and Disable SMB 2.0:

Now, compare that to what is running on the PC/Server which shares the files which the other computers need to access. You might see that on the PC with the shared folders there might be MRxSmb10 & MRxSmb20 (and even MRxSmb30) listed. What I could figure out, is that Windows 10 doesn’t like the SMB v1 protocol anymore, thus they have discontinued with it after all the Ransomware outbreaks, BUT they have given users the option to enable it again (I will briefly explain that next). But strangely, I have seen that after I have enabled SMB v1 compatibility in Windows Features, it still shows in the abovementioned command results that only SMB v2 is active. You can try enabling SMB v1 by going to Programs & Features, and then select “Turn Windows features on or off”. Scroll down and install SMB 1.0/CIFS File Sharing Support (you will need to reboot your PC).

After you have restarted your PC, you can confirm if SMB v1 is active by running the sc.exe qc lanmanworkstation command again.

If it is not active, you will need to perform the following actions:

Open PowerShell as an administrator and run the following 2x commands:
sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc.exe config mrxsmb20 start= disabled
Restart the computer.

This will force SMB v1 to be enabled as well as forcing SMB v2 to be disabled. If you have SMB v3 active on your Windows 10 PC, you can repeat the last PowerShell command above and replace mrxsmb20 with mrxsmb30.

After you have restarted your PC, you can confirm if SMB v1 is active by running the sc.exe qc lanmanworkstation command again.

After you have restarted your computer, you should be able to view all the network PC’s on your Windows 10 PC. You should now be able to access the file shares which was previously not possible.

Last option if it is still not working:

The last thing you can try is to create Inbound and Outbound firewall rules on the Windows 10 PC and Server.

Create OUTBOUND rule: TCP Port 445 on Windows 10 PC
Create INBOUND rule: TCP Port 445 on Windows 2008 server PC (or PC hosting your file shares)

Restart both the PC and Server (or PC hosting your shares).

Conclusion:

As I have mentioned, this article might (or might not) help you with this issue, as I have found that there is not a definite way of getting this issue resolved the first time. It seems like Microsoft have gone quite secure with the SMB protocols, as they also don’t have resources for the public (at this stage) to sort this problem. There could also be numerous other things which could cause this issue like hardware firewalls and firewall rules, network card drivers and configurations, server share permissions etc. (you get the picture). I would personally not blame Microsoft as such for being the cause of this issue, as it is clear that this issue is a thing about new technology trying to work with old technology. At the end of the day, my recommendation would be that you keep your software up to date on both client and server side. If you are in a more enterprise-type of environment, I would also suggest that in some cases, your client operating systems should not always be newer than your server operating systems (as issues mentioned in this article could arise).

Again, this article is an explanation of what I personally done to resolve a specific issue in a specific scenario.

Please feel free to leave your comments and suggestions if you have any other advice or questions.