Q: Network shares do appear beneath computer icon in Network view In the following network (viewed from RPAFEA), Karen-PC is Windows 7 Home Premium (mini-tower) and V3500 is Windows 7 Pro (laptop). Both are 64-bit. RPAFEA is Windows 10 Home.
Computer  Network from RPAFEA:

When the icon for Karen-PC is clicked, its network shares are displayed (browsed to successfully) as shown here:

However, when the V3500 icon is clicked, this error is displayed:

This, even though V3500 shares can be accessed using the network path, for example "\\V3500\FEATool":

[BTW, this is the same behavior when accessing V3500 shares from Karen-PC. A network path is required. They cannot be "browsed to" in the Network.]
I have tried many things recommended (obviously not the correct things:-) to solve this including checking the proper services are running, disabling firewalls, and comparing network settings. But please feel free to have me try anything (I'll even restart my router and all computers!)...
The following seemed like a similar issue, but I saw no answer:
Windows 7 Pro Peer-To-Peer Networking
[The following added 20210524]
I have discovered a difference in the Karen-PC and V3500 PC shares.
The disk volumes appear as "default" shares on Karen-PC (see highlighted items in the view below):
Karen-PC Share Listing (includes C: and I:)
The V3500 shares listing below shows no default shares, specifically, disk volumes C and D:
V3500 Share Listing (no defaults)
Somewhere I read that disk volumes were shared by default, which seems to agree with the Karen-PC result: successful sharing. I suppose the "default" shares for the two disk volumes on V3500 were somehow removed.
I tried to add the D:\ as a share (share name D$) on V3500, but what I did, did not seem to work (and did not survive a restart).
[Added 20210524]
I found this: https://docs.microsoft.com/en-US/troubleshoot/windows-server/networking/problems-administrative-shares-missing
It discusses the problem of the missing admin shares and as a remedy suggests a registry edit (if appropriate).  Evidently, these admin shares (including disk volumes such as C:) are by default active/installed/enabled.  However a couple of registry entries, if present AND set to (0), will prevent this.  The remedy is to edit the registry and, if present AND set to (0), set them to (1).
My situation tracks with this. V3500 registry does in fact contain these entries AND set to (0).  Karen-PC does not have the registry entries present (which results in default behavior).
After scanning with Bitdefender and Trend Micro, I made the suggested changes in the above docs.microsoft.com article: Set AutoShareServer and AutoShareWks to 1.
Now the admin shares for disk volumes exist  (C$, D$, etc) and show up on V3500:
C$           C:\                             Default share

However, from the other computers (Karen-PC, RPAFEA) V3500 is visible in the network, but it still cannot be browsed. Opening it produces the error shown above:
"You do not have permission to access \\V3500."
But V3500 can still be accessed using the path "\\v3500\users\randal\desktop". And the other Windows 7 machine on the network can be browsed by opening its computer icon.
Perhaps I can follow the error message diagnostic chain to the cause.
Can someone tell me where these errors would appear and how to locate them?
What configuration settings in the two w7 computers can I check? One (Karen-PC) is accessible the other (V3500) is not.

A: There were two issues preventing the V3500 shares from being browsed by another computer on the network.
The first was that the a registry subkey had been added:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters, with DWORD values AutoShareServer and AutoShareWks set to 0.  This prevented the admin shares from being shared automatically on each system startup. The solution was to set these to 1.  See https://docs.microsoft.com/en-US/troubleshoot/windows-server/networking/problems-administrative-shares-missing for details.  I suspect that changing AutoShareWks alone would have solved my case.  The article also suggests that removing the subkeys entirely (back to the default condition) would also solve it.  I did not try that option.
After correcting that, I could view the shares from another computer using a fully qualified path such as: \\v3500\Users\Randal\Desktop\TestSHare. This command, for example, would list the files in the shared directory "TestSHare".
But still: \\v3500 got a permission error and would not list (elaborate) all the shares on v3500.
A second problem was solved on the Microsoft Q&A forum (see https://docs.microsoft.com/en-us/answers/questions/413182/cannot-browse-windows-7-admin-disk-volume-shares-f.html )
A Local Group Policy "Network access: Do not allow anonymous enumeration of SAM accounts and shares" had been given the value of "Enabled". You can read about this here: https://www.ultimatewindowssecurity.com/wiki/page.aspx?spid=NANoAnonShares#:~:text=accounts%20and%20shares-,Network%20access%3A%20Do%20not%20allow%20anonymous%20enumeration%20of%20SAM%20accounts,the%20enumeration%20of%20user%20accounts.&text=Anonymous%20enumeration%20of%20user%20accounts,try%20to%20guess%20the%20passwords
V3500 value of the Policy was "Enabled".
After changing this to the default value of "Disabled", the problem disappeared.
Thanks to all who gave is some thought. Needless to say I am glad to be shed of this one!
