Can't access shared computer after update

This is so random and frustrating.

Today I can access one computer (officeserver) but not another (tech). My colleague can access tech but not officeserver (opposite to me). Last night I could access both of them.

I have changed names of all of them, verified they are in the same workgroup, and done everything I can think of.

It seems to change from one minute to the next. This happened with the Spring Update, and after a week or so it finally resolved. But WHY is this happening, and how can I fix it? It shouldn't be so random like this.

Try disabling IPv6 on all PC's - Enable or Disable IPv6 in Windows | Windows 10 Tutorials

Note: MS recommends prefer IPv4 over IPv6 VS disabling IPv6 - https://support.microsoft.com/en-us/...advanced-users

My problem is resolved!

What did it was the solution above to:
1. Assign each PC a specific IP address in the router that is handling DHCP. For my Netgear router, it is in LAN settings, Address Reservation
2. Edit hosts file in c:\Windows\System32\drivers\etc of all computers. I added a line with the ip address and name of each computer. (Example: 10.0.0.17 OFFICESERVER)

That was it, and it is fixed!

If anyone does this, be sure to realize that if you change the name of a computer, or change routers, things need to be updated.

Thanks everyone for your help.

Even though it all works for me, the question remains: why do I have to go through all this? What is wrong with Windows 10 that it can't access the shared files consistently unless I force the ip address through the router and the hosts file?

LuscombeDriver said:

Even though it all works for me, the question remains: why do I have to go through all this? What is wrong with Windows 10 that it can't access the shared files consistently unless I force the ip address through the router and the hosts file?

Good question and I've wondered the same thing since all this started. I think it is related to Network Browsing via Netbios which the removal of smbv1 kills. Fortunately the only issue I had was when SMBv1 was removed and I could no longer browse the network. I was able to quickly correct that when I found the items (below) and I haven't had any trouble since. But I do keep this list handy just in case an update "fixes" an issue:

Be sure the following services are set to Automatic (Delayed Start):

- Computer Browser (Browser)
- Function Discovery Provider Host (FDPHost)
- Function Discovery Resource Publication (FDResPub)
- Network Connections (NetMan)
- UPnP Device Host (UPnPHost)
- Peer Name Resolution Protocol (PNRPSvc)
- Peer Networking Grouping (P2PSvc)
- Peer Networking Identity Manager (P2PIMSvc)

Also wanted to add: I only had one device that was running smbv1 and I removed that as well (didn't need it) so I had no issues related to Browsing over Netbios. One thing that might be helpful is to see if there are any devices that are still resolving by Netbios on the network, and may have kept things from working (kinda a moot point since you have effectively resolved the issue with your hosts file). To see if there is anything using Netbios go to "network" in file explorer. There will be a row on top that shows various things about the network devices that show up there. The one column you will want to look at is "Discovery Method". If it is not there right click on that row and add it - I don't think it is shown by default. All my Windows device show as resolving by WSD or SSDP. Here is a screen shot of mine:

I've had very similar problems and after wasting days trying to find a solution (tried all of those suggested here) have given up. I've re-imaged back to 1709, which had no network issues at all, and deferred 1803 for 365 days. Life has returned to normal.

Interesting - As I was looking at these services in the list I posted above I realized that "Computer Browser" should not be there - if SMBv1 is disabled, the service is NOT there at all. Additionally except for the two "Function Discovery" services, all the other services are set to "manual" startup - at some point I assume an update reset the services to manual... So bottom line is that the list I posted above, with the exception of Network Function Discovery services is in fact incorrect! My apologies!