Computers Missing from Windows Network Folder

The Network folder in File Explorer is a discovery list. It shows computers that have announced themselves through a discovery protocol and that the local machine has chosen to display. It is not a test of whether file sharing works. A computer can be fully reachable at \NAME or \IP-address and still never appear in the Network folder. When computers are not showing in network, the usual cause is that discovery is not functioning, not that sharing is broken. The distinction matters because the repair for a missing browse entry is different from the repair for a failed connection.

Discovery in current versions of Windows does not use the old Computer Browser service. That service depended on SMB1 and was removed from the default configuration years ago. Modern discovery uses WS-Discovery, a multicast protocol, and it requires the Function Discovery Resource Publication (FDResPub) service to be running on the machine that is to be discovered. The machine doing the looking also needs the network profile set to Private, because discovery is disabled on Public profiles by design. Firewall rules for Network Discovery must be enabled on both sides. If any of these conditions is missing, the computer will not appear, even though its shares are available.

How discovery is evaluated

When File Explorer opens the Network folder, it asks the discovery provider for a list of devices. The provider checks the local network profile. On a Public profile, discovery is off and the list will be empty or contain only the local machine. On a Private or Domain profile, the provider sends WS-Discovery probes and listens for responses. A remote machine responds only if its FDResPub service is running and its firewall allows the discovery traffic. The response includes the machine name and address, and that is what appears in the list. Nothing in this process checks whether a share exists or whether permissions allow access. A machine with no shares at all can still appear, and a machine with open shares can be absent.

This is why connecting by name or by IP address is the reliable test. If \NAME\share opens, sharing and name resolution are working. The absence from the Network folder is then a discovery issue only.

Check the network profile first

The network profile determines whether discovery is permitted. To view it, open Settings, then Network & Internet, then the properties of the active connection. The profile is shown as Public or Private. A machine set to Public will not display other computers and will not be displayed. Change it to Private only on networks that are trusted, because Private lowers the firewall for discovery and sharing.

The active firewall profile can also be read from a Command Prompt.

netsh advfirewall show currentprofile

The output is headed with the active profile, for example Private Profile Settings, followed by its firewall state. If the profile is Public, discovery rules are not applied.

Confirm the discovery service on the machine to be found

The Function Discovery Resource Publication service must be running on the computer that should appear in the list. On that computer, open Services from the Start menu, locate Function Discovery Resource Publication, and set its startup type to Automatic, then start it. The service can also be controlled from an elevated Command Prompt.

sc config FDResPub start= auto

sc start FDResPub

The first command sets the startup type; the second starts the service. If the service fails to start, the event log will record the reason. A stopped FDResPub means the machine does not announce itself, so it will not be listed regardless of its shares.

Enable the firewall rules for Network Discovery

Network Discovery consists of a group of firewall rules. They can be enabled per profile. On each computer, in an elevated Command Prompt, the following enables the group for the Private and Domain profiles. Do not enable it for Public.

netsh advfirewall firewall set rule group="Network Discovery" profile=private,domain new enable=Yes

The profile filter comes before new, so only the rules belonging to those profiles are changed. The command returns the number of rules updated. The same result is available in Settings under Advanced sharing settings, by turning on Network discovery for private networks. If it reports that no rules match, the group name is localized and must be given in the display language of the system. The rules can also be enabled in Windows Defender Firewall with Advanced Security under Inbound Rules.

What people get wrong about this

The common misdiagnosis is to treat the empty Network folder as a permissions failure and to start changing NTFS permissions or taking ownership of folders. That is a natural mistake because the symptom appears in a file-browsing context, and permissions are the usual cause of access errors elsewhere. But the Network folder is populated before any share or file permission is evaluated. Changing permissions cannot make a computer appear in a list it never announced itself to. Taking ownership of system folders in response can break services and is difficult to reverse; it addresses a problem that was not present.

A second misdiagnosis is to enable SMB1 and the Computer Browser service. That restores an obsolete protocol with known weaknesses and does not fix WS-Discovery. The correct layer to inspect is the discovery service and the firewall group.

Connect by name or IP and map a drive

When the browse list is unreliable, bypass it. Open File Explorer and type the UNC path in the address bar.

\\COMPUTERNAME\share

If the name does not resolve, use the address.

\\192.168.1.50\share

A successful connection confirms that sharing and permissions are correct. To make the connection persistent, map a drive from a normal, non-elevated Command Prompt; a drive mapped from an elevated prompt does not appear in Explorer for the same user. The following maps drive Z: to the share and reconnects at sign-in.

net use Z: \\COMPUTERNAME\share /persistent:yes

The output reports success or the specific error. System error 53 means the network path was not found, which is a name resolution or reachability failure; system error 5 means access was denied at the share. Neither error is a discovery problem.

Comparison of causes

Verify name resolution

If \NAME fails while \IP succeeds, the problem is name resolution, not discovery. The following query asks the configured DNS server for the name.

nslookup COMPUTERNAME

The output shows the resolved address or an error. On small networks without a DNS server, NetBIOS name resolution or LLMNR may be in use, and these can fail independently of discovery. Using the IP address avoids the issue for a mapped drive.

When to stop changing permissions

If the computer is reachable by name or IP, the sharing configuration is working. Further changes to NTFS or share permissions are not indicated. If a specific share is refused, the error code from net use identifies whether the refusal is authentication or authorization, and that is the point to inspect share permissions and NTFS permissions in that order. Taking ownership of a system folder is not part of this repair and should not be attempted.