Did Windows 10 April Update break network discovery and Samba support?

Question

It seems Window's network discovery / name resolution doesn't work anymore on computers freshly reset with the new April update for Windows 10 (Build 1803). (Computers that were merely updated don't seem to be affected.)

My local network consists of a modern NAS drive using samba for sharing, plus a couple other Windows 10 computers (in addition to the one I'm typing on). All computers have the network configured as a private network.

Before the April 1803 update, going to File Explorer -> Network would show a list of windows computers, including the NAS. I could then browse the NAS, mount it as a network drive, etc.

This "network discovery" behavior still works on computers that were merely updated to 1803, however resetting the computer to a fresh 1803 install seems to break network discovery. On reset computers, going to File Explorer --> Network results in Nothing. Nada. No name resolution. No network discovery. Nothing shows up.

When I try to manually connect to \\AS5002T or \192.168.1.46 (my NAS) on the updated 1803 computers, it works (I can browse the NAS files). But on the reset 1803 computers, connecting doesn't work anymore at all. In the best case, I just get "Network Path not Found".

Googling "network discovery Windows 1803" shows I'm not the only one having problems. Some people have observed certain "Function Discovery" services not running, and on the reset computer I noticed that SMB 1.0 features are disabled by default.

Anyone know if this is a recognized issue? What fixes there may be? Perhaps people don't know about this issue because it only affects computers reset with 1803?

---

In total, the problems are for reset, fresh Windows 10 computers with update 1803.

• Network Discovery is not working, shows no computers on network
• Cannot connect to Samba share

Answer 1

Everything you need to know is here:

https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/

In summary:

SMB 1.0 is BAD. Don't use it. You probably don't need it anyway (we'll get to that).

Because it's so bad, Microsoft has begun removing it from Windows completely, starting with the Windows 10 1709 Fall Creators Update. Right now, if you just update an existing system that already had it, you get to keep it. But if you start fresh with a new copy of Windows, it won't be there. Soon, it won't even be available to install, and soon after that it will be actively removed by a normal Windows Update. At that point, it will likely just be a normal monthly patch, and not even a full feature upgrade.

In other words, there's no point bothering to re-install this back on your system. You're setting yourself up for a fight that's not gonna go your way. You might win today's battle, but the problem's gonna come back (probably sooner than you think) and you'll eventually lose that war.

Fortunately, very few things still require SMB 1.0, and most of those that do are the result of running outdated software on some other system, such that you can also update the other system and restore service.

One of the most noticeable places which still relies on SMB 1.0 by default is the network browsing feature in Windows Explorer (formerly Network Neighborhood). However, you can fix this, too, without using SMB 1.0:

• Find the Function Discovery Provider Host and Function Discovery Resource Publication services and set their startup types to Automatic (Delayed Start).
• The next time you start network browsing, follow the prompts to enable Network discovery.

Do this for all Windows computers on your network, and everything is fine again, using the much nicer WS-DISCOVERY protocol.

Answer 2

---

Recommended Actions

It seems that windows is abandoning SMB 1.0, and currently my NAS (which is only two years old) doesn't support whatever "Network Explorer" protocol they have moved on to. So for now, your supposed to leave SMB 1.0 disabled, manually enter the necessary information into Credential Manager, and manually connect to the network drive. Setting the two "Function Discovery" services to Auto Delayed didn't help me, but that is supposed to recover the Network Explorer.

To recover the behavior where you are prompted for username and password when connecting to certain NAS devices, I had to "enable insecure guest logons". Otherwise Windows will just give up after trying your username (not telling you what failed nor why).

---

Alternative Actions (to recover the "old behavior" of windows)

Enabling the optional feature SMB 1.0/CIFS Client and restarting the computer will fix network discovery.

You may still get "Error code 0x80070035 - The network path was not found" if the samba device you are connecting to does not have a user account name that matches your windows account name.

There are several ways to fix the above "missing username" issue (despite it appearing that its a different kind of issue). The first is by placing a valid entry in the Windows Credential Manager. In my case, the entry was for the domain AS5002T, the username admin, and my password.

A second method, which will recover the way windows worked in the past, is to instead "enable insecure guest logons". Insecure guest logons are used on many consumer NAS devices, as a way to let unauthenticated network users "preview" the shares on the NAS.

A third method would be to simply add your windows username to the samba server's list of usernames.

Answer 3

i think i have been having the same issue ubuntu server/windows 10

my solution was to install a WSDD daemon, the one linked below requires no configuration other than changing your service file

https://github.com/christgau/wsdd

Answer 4

If you have stumbled upon this question, there is a solution for Windows-Windows Samba connection: if you changed the UAC settings in secpol.msc (Security Policies), so you could be admin for whole computer - you may need to do that on both machines if you want them to see each other. Few hours spent to find this.