All File And Printer Sharing Doesn't Work, Error 0x80070035 on Access, Any Network, Any PC

I am experiencing a problem across all of my Windows 10 devices (and, previously, Windows 7 devices) -- basically, any attempt to access a Windows network share over the network ends in Error 0x80070035, "Network Path Not Found".

There are three PCs in play here, two running Win 10 Home and one running Windows 10 Pro. The Win 10 Pro machine previously ran Win 7 Ultimate as well as Linux Mint and I encounter errors if I attempt to use them too. (Though, I remember Win7 working a long time ago)

Strangely, all the computers affected can see each other in Network Neighborhood!

Note that I have been able to transfer files via SMB when both sides of the connection are powered by Samba or a really old version of Windows. But if that side is running a recently patched version of Windows with what I think is SMBv3, then life is 0x80070035.

Most frustratingly, just yesterday a brand new laptop arrived and it too displays this issue. I've done extensive research on 0x80070035, and while there are a ton of proposed solutions it seems that nobody actually understands what this error actually means and there is no definite path for troubleshooting it.

I have (unsuccessfully) tried:

• Putting each PC on Static IP, both on a switched network and via crossover, and verified connectivity with ping and Steam notifications
• Tried to talk to each via \\IP.ADDRESS or \\HOSTNAME
• Checked the status of TCP/IP NetBIOS helper (always running, with 'Manual (triggered)' as its startup)
• Edited Network Access/Network Security settings in secpol.msc on the machine with Win 10 pro (I don't have these edits in front of me, though one was making sure NTLM would negotiate properly)
• Taken each machine in and out of homegroups
• overridden hostnames in c:\windows\system32\drivers\etc\hosts
• ensured all computers authenticate with login/password instead of that stupid new system that it uses
• made sure 'Enable NetBIOS over TCP/IP' is set
• other fixes attempted over the last year that I cannot recall (I'll edit them in later if I remember them)

While fixing the issue would be nice it would be even better to understand what exactly whats going on here. All I can recall is that Win7 stopped working around the time that SMBv2 vulnerability went around and I suspect, in the case of Win7, that that functionality was directly tied to that patch.

Beyond that, however, I am lost. It would be great if there was a checklist of things I could verify. Anyone?

edit: in examining a Wireshark dump of the conversation, I can see the two machines talking to each other -- first they negotiate SMB1, then SMB2, then someone sends a TCP ACK and then the other side follows up with a TCP RST (?) This makes me think it is the firewall but I have disengaged the firewall...

Background

I have three Local Netwrok PCs, 2 on Windows 10 Pro Ver 1803 and 1 on Windows 10 Home version 1803. There's a clean install on 1 Pro machine, and update from Win 7 on the other 2.
All machines run local accounts, one local user with no password and the built in administrator account (Net User Administrator /Active:yes), see more on that below. The good is that both accounts on the Home PC can access folders on both Pro PCs.
The Pro machine with a clean install also works ok.
The Updated Pro gave the 0x80070035 error on Local user account without password. Like you I've followed all net searches and most advice.
File explore maps the other PC's, but not their disks or folders. Likewise, Ping confirms the connection. Other than enabling the correct settings for Advanced Sharing, nothing else needed to be done on the 2 problem free PC's, except obviously ensuring folders had correct permissions and sharing.
Answer
I did a clean install on problem Pro machine - Same error.
I then enabled the built in administrator account (Net User Administrator /Active:yes), The good news is that the problem went away when logged on as Administrator only.
The error code persists with the local user account. This suggests a permission or policy configuration issue. The Services and settings on both Pro machines are identical.
My search for a fix continues.