The first step in troubleshooting network access problems is to verify that the client PC can determine the network address of the PC that hosts the network shares.
Open a Powershell prompt and use nslookup.exe to test DNS name resolution.
Note: if you have switched your PC to use an external DNS server like Google's 8.8.8.8, then local name resolution will not work. In that case you need to ensure that Network Discovery is properly configured.
Typically your router will function as both the DHCP and DNS server. You may see both IPv4 and IPv6 addresses.
Some machines may still have NetBIOS functioning. Use ping.exe to see if it resolves the address. Note that ICMP packets may be blocked by the firewall. You are mainly looking to see that the correct IP address was found.
If you are unable to resolve the IP address, you will need to check Network Discovery. You will need to verify this on BOTH the client PC and the PC that hosts the network shares.
See my answer in this post. This contains my CheckNetworkDiscovery.ps1 script.
https://v4.hkg1.meaqua.org/en-us/answers/questions/2151284/24h2-killed-network-discovery
Open Powershell_ISE with "Run as administrator" and paste the script into a tab and run it.
On this PC, it does not have the required firewall rules enabled.
If you need to fix Network Discovery, please see my FixNetworkDiscovery.ps1 script in the accepted answer in this post.
Copy/paste/run the script in another tab.
Then go back to the CheckNetworkDiscovery.ps1 tab and run it. Verify that it says "Your network profile is set to Private".
If name resolution still does not function, then try rebooting both machines.
Your machines should now show up in the explorer's Network section.
Next, use Test-Netconnection to verify that SMB port 445 is allowed through the firewall.
If that fails, then on the PC that hosts the shares, run "wf.msc" to configure the firewall. Select "Filter by profile" and choose private. Select "Filter by group" and choose "File and printer sharing". Verify that they are enabled.
Use "net view" to list the shares.
If you get a "system error 5", that means that the account that you are logged in with cannot authenticate to the other PC. On my network, I log on to my laptop and my bigblue PC with my Microsoft account. That allows me to list the shares.
I also have several test VM's (test10, test11) where I have defined a local account named admin, with a password of admin, on each pc. That allows those machines to access each other's shares.
I personally do not recommend enabling the guest account to access shares. I consider that to be a security risk. Use either a MS account or a local account with the same name and password on both machines. You can always use the Windows Credential Manager to define an entry if your desktop account is not defined on the pc that hosts the shares.
I also recommend that you do not use the C$ share. Share out your data folders and grant appropriate access to the share permissions and the folder permissions.
I'm going to stop here for now.