Shared computers do not appear under Network in File Explorer
What to do first
Shared computers do not appear under Network in File Explorer. The network profile may be Public, network discovery may be disabled, or Function Discovery services may be stopped. Record the current state before changing it, use only the supported Windows path described below, and verify the same operation again after any required restart.
This is a general troubleshooting guide, not an announcement of a current outage.
Affected products and symptoms
- Product
- Windows network discovery
- Versions and conditions
- Windows 11 (confirm the edition and hardware requirements for the feature)
- Error codes and identifiers
- SMB
Symptoms
- Shared computers do not appear under Network in File Explorer.
- The same condition can persist after a retry or restart.
Causes and conditions
The network profile may be Public, network discovery may be disabled, or Function Discovery services may be stopped.
Before you start
- Save open documents and allow time for a Windows restart if required.
- Run administrative actions only on a personally managed PC or with administrator approval.
- Save the diagnostic command output so the before and after states can be compared.
Precautions
- Do not bulk-delete registry entries, system folders, credentials, or storage metadata.
- Do not run unofficial scripts or unknown drivers with administrator rights.
Step-by-step instructions
Enter a known UNC path in File Explorer. If the share opens, SMB access works and the steps below concern discovery in the Network list. If it does not open, check the path, network and credentials first.
Confirm that this is a trusted LAN and check whether the active network profile is Private rather than Public.
Get-NetConnectionProfileOpen Settings > Network & internet > Advanced network settings > Advanced sharing settings and enable Network discovery for Private networks. Check Function Discovery Provider Host and Function Discovery Resource Publication if discovery still fails.
Get-Service FDResPub,FDPHostIf the connection is Public, confirm it is your trusted home or managed LAN before changing its profile to Private in Settings. Do not change public Wi-Fi to Private. After enabling discovery, reopen File Explorer and check the Network list and UNC access separately.
Replace SERVER_NAME with the actual value for your system before using this example.
Run Test-NetConnection <server> -Port 445 and repeat the original operation once under the same conditions. If it succeeds, verify again after a restart and record the setting that changed.
Check that no new critical event with the same timestamp and component appears in Event Viewer.
Test-NetConnection SERVER_NAME -Port 445
Check the result
- The feature starts, connects, or completes without the original error.
- The verification command reports the expected enabled, healthy, or connected state.
- The result remains correct after a Windows restart and no new matching critical event appears.
If the problem continues
- If the same code persists, provide the full message, Windows build, command output, and occurrence time to the PC administrator or Microsoft Support.
- If hardware requirements, organization policy, or server settings are responsible, ask the owner to make the change instead of bypassing it on the client.
Scope of this guide
Troubleshooting guide — Restore the feature so it starts, connects, or completes normally and passes the same verification after a Windows restart.
Frequently asked questions
Should I enable discovery on a Public network?
No. It increases device exposure. Enable it only after confirming that a trusted LAN uses the Private profile.
UNC access works although the device is absent. Is SMB broken?
No. Discovery and SMB connectivity are separate; use the correct UNC path if the share itself works.
Official sources and dates
Source publication or resolution date: Not specified. Sources checked: 2026-09-05. The check date is not the date the problem first occurred. Interface labels can vary between versions and display languages.
Related troubleshooting guides
- WSL 2 error 0x80370102 prevents a distribution from starting
- Restore the WSL optional component when error 0x8007019e appears
- WSL alone cannot resolve names while a VPN is connected
- Hyper-V is missing from Windows Features or cannot be enabled
- WSL 2 or Hyper-V cannot run inside a Hyper-V virtual machine
- Windows Sandbox is missing or cannot start