SOLVED SMB shares not showing in network browsing

[BurntMyBacon]

I'm having a somewhat similar problem to the Original Poster. I can access my FreeNAS server by both hostname and IP from all available Windows 7 machines. I can access the FreeNAS server by IP only on all available Windows 10 machines (fully updated as of 1/18/2018). Like the Original Poster, my share does not show up in "Network" on the Windows 10 machines. Unlike the Original Poster, I am not concerned with fixing this aspect of the behavior. I simply want to be able to address the FreeNAS machine by hostname when adding shares or mapping drives as IPs can change.

... if you add a share as a network location [i.e. not a mapped drive], it will allow you to access the share without typing in the IP. This takes all of <15s to do...

The problem is I can only create a network share using the IP address.

• shares should be added by hostname, not IP, as an IP can change, whereas hostnames require system level access by root or sudo to change.
  • Even if utilizing static IPs, there's going to be a time when one may need to reflash firmware of the router, or may need to reset a router to default settings, in which case a hostname added share would likely still be accessible, but an IP share would likely not be.
  • Setting shares by hostname also means the share can be accessed over SSH or VPN without re-adding the share with a new IP

Per your advice, this would seem to be the less advisable way to go about it.

I have enabled SMB Direct, deselected SMB v1.0, and set smb configuration options per your previous post:

@RiBeneke Is the PC running the Fall Creator's Update (v1709)? If so, ensure SMB Direct is enabled and disable SMB v1.0 by selecting the Automatic Removal box under it's section (or deselect it altogether). SMB 1.0 is not secure and allows a specific exploit to be performed on PCs with SMB v1.0 enabled.

• Provided one is running v1709, there should be no issue accessing FreeNAS Samba shares (I had issues with v1701, but have not since doing a clean install of v1709)

Also, ensure the following is set in /usr/local/etc/smb4.conf

• server min protocol = SMB2_10
• server max protocol = SMB3_11
• netbios name = <FreeNAS Hostname>
• workgroup = <PC/Router Workgroup>
  • Control Panel\System and Security\System --> Change Settings --> Change --> Member of Workgroup
  • For the router, the Workgroup name will the name set under Domain

Do you have any further troubleshooting tips for getting hostname access to the FreeNAS server on Windows 10. Again, this functions just fine on Windows 7.

Build FreeNAS-11.1-RELEASE
Platform Intel(R) Xeon(R) CPU E3-1225 v5 @ 3.30GHz
Motherboard SuperMicro X11SSM-F
Memory 16168MB

 

[BurntMyBacon]

That doesn't make sense... If you had a share added in Windows, it would either open the share or provide an error stating it couldn't communicate with the server... it would not allow you to enter an IP.

• You have to create a share in FreeNAS, then add that share in Windows.

In other words, you have not added a share in Windows. Do that, and the FreeNAS server will show up under Network

Just so you are aware, while adding a network share (not mapped drive) using the IP allows for quick access, it does not make the FreeNAS server show up under Network on any of the available Windows 10 systems. Again, I don't necessarily need this functionality, but perhaps this information will help with troubleshooting.

 

[zoomzoom]

Are FreeNAS and Windows apart of the same workgroup?

• Windows: Control Panel\All Control Panel Items\System - Computer name, domain, and workgroup settings
  • If not, select change settings - Change... - Workgroup
  
  
• FreeNAS:
  • WebUI > System > Information > Hostname - Edit
    • Default is freenas.local: freenas is the hostname, local is the workgroup name (also known as the local domain name).
  • WebUI > Services > SMB - Edit - Worgroup

 

[BurntMyBacon]

Are FreeNAS and Windows apart of the same workgroup?

• Windows: Control Panel\All Control Panel Items\System - Computer name, domain, and workgroup settings
  • If not, select change settings - Change... - Workgroup
  
  
• FreeNAS:
  • WebUI > System > Information > Hostname - Edit
    • Default is freenas.local: freenas is the hostname, local is the workgroup name (also known as the local domain name).
  • WebUI > Services > SMB - Edit - Worgroup

Yes. I made to sure place them in the same workgroup per your previous advise.

 

[zoomzoom]

Something is misconfigured then, as local devices on a LAN are always accessible by IP or local DNS hostname in Windows. If you can access one, by default, you must be able to access the other, as each are interchangeable

• For example, google.com loads Google's site, as does it's IP (216.58.216.238)

When you're accessing your FreeNAS hostname, are you entering it in the following format (assuming hosntame is freenas.local): \\freenas

• If so, something in your network is misconfigured, and I would start with your router and verifying it's local domain (.local above) is also set to the same as the PC and FreeNAS box.
  • Your router is the the local DNS server, so whatever local domain is set on the router is the same local domain and workgroup that must be specified on all LAN devices.

 

[BurntMyBacon]

Something is misconfigured then, as local devices on a LAN are always accessible by IP or local DNS hostname in Windows. If you can access one, by default, you must be able to access the other, as each are interchangeable

• For example, google.com loads Google's site, as does it's IP (216.58.216.238)

When you're accessing your FreeNAS hostname, are you entering it in the following format (assuming hosntame is freenas.local): \\freenas

• If so, something in your network is misconfigured, and I would start with your router and verifying it's local domain (.local above) is also set to the same as the PC and FreeNAS box.
  • Your router is the the local DNS server, so whatever local domain is set on the router is the same local domain and workgroup that must be specified on all LAN devices.

I am addressing the system as you assume. I will look into the router domain when I get a chance. Is this a new requirement for Windows 10? I've now verified that both Windows 7 Clients and Ubuntu clients don't even need to be in the same workgroup to successfully access the FreeNAS server via hostname. I'm was initially inclined to believe this is a Windows 10 configuration issue since all the available Windows 10 machines share a common configuration. However, given your suggestion with the router, I'm wondering if something changed in the way this is handled under Windows 10? If it did, then does that break compatibility with older versions of Windows Server?

In any case, I'll get back to you when I get a chance to verify the router configuration.

 

[zoomzoom]

I don't know if that's what your issue is or not, but the router is the local DNS server.

• I'd also verify the following inbound/outbounnd ports are not being blocked
  • TCP: 139, 445
  • UDP 137, 138, 139
• You may also want to check Event Viewer and verify your advanced sharing settings:
  • Control Panel\All Control Panel Items\Network and Sharing Center\Advanced sharing settings

Even, if that's not the issue, it's generally easier for most to utilize host names, over IPs, to access LAN devices (for example, WebUIs), and in conjunction with all LAN devices sharing the same local domain, one would then configure their hosts file in a similar fashion as below:

• %WinDir%\System32\drivers\etc\hosts
  Code:

  #
  
  	 ##::[[---  Windows Host Config  ---]]::##
  
  ####################################################
  			##----- Host Lists -----##
  ####################################################
  
  	# MVPS Hosts #
  #---------------------------------------------------
  
    # Updated: 2017.11.30
  
    # http://winhelp2002.mvps.org/hosts.htm
  
  
  	# Malware Domain List Hosts #
  #---------------------------------------------------
  
    # Updated: 2017.10.26 13:51:30 +0000
  
    # http://www.malwaredomainlist.com/hostslist/hosts.txt
  
  
  ####################################################
  		 ##----- Windows OS Entries -----##
  ####################################################
  
  	# Loopback #
  #---------------------------------------------------
  127.0.0.1		  localhost
  ::1				localhost
  
  
  ####################################################
  				##----- LAN -----##
  ####################################################
  
  	# Sophos UTM #
  #---------------------------------------------------
  192.168.254.10	 FreeNAS1	FreeNAS1.UTM
  
  
  	# WRT1900ACS #
  #---------------------------------------------------
  
    # LAN:
  192.168.255.1	  UTM		 UTM.WRT
  192.168.255.2	  AWL		 AWL.WRT
  192.168.255.3	  AWW		 AWW.WRT
  
  
  192.168.255.21	 C27500	  C27500.WRT
  192.168.255.22	 C27501	  C27501.WRT
  192.168.255.23	 FreeNAS0	FreeNAS0.WRT
  192.168.255.25	 2758F	   2758F.WRT
  192.168.255.60	 LEDE		LEDE.WRT
  192.168.255.61	 ESXi1	   ESXi1.WRT
  192.168.255.62	 ESXi0	   ESXi0.WRT
  

  • The format above is IP <whitespace> Hostname <whitespace> Hostname.LocalDomain
    • For example, to access my FreeNAS WebUI, all I would type in the address bar is: freenas0.wrt or freenas1.utm

The only major issue I'm aware of in Windows 10 in regards to SMB is (within certain environments) upon disabling SMBv1, and enabling SMB3, the OS is no longer able to access Samba shares.

• You may want to try running the Windows 10 network troubleshooter, to see if it identifies any issues: Settings - Search bar > type "Network Troubleshoot"

 

[BurntMyBacon]

Something is misconfigured then, as local devices on a LAN are always accessible by IP or local DNS hostname in Windows. If you can access one, by default, you must be able to access the other, as each are interchangeable

• For example, google.com loads Google's site, as does it's IP (216.58.216.238)

When you're accessing your FreeNAS hostname, are you entering it in the following format (assuming hosntame is freenas.local): \\freenas

• If so, something in your network is misconfigured, and I would start with your router and verifying it's local domain (.local above) is also set to the same as the PC and FreeNAS box.
  • Your router is the the local DNS server, so whatever local domain is set on the router is the same local domain and workgroup that must be specified on all LAN devices.

The router was indeed using a different domain (.local). However, correction of this did not affect the Windows 10 Clients' ability to address the FreeNAS server by hostname. I switched the local domain on the router, FreeNAS, and a few Windows 10 clients to .tmp to reduce the likelihood of typos and to check out another theory. The Windows 10 clients remain uncooperative. The Windows 7 and Ubuntu clients, despite not having their local domains changed, remain functional. Interestingly, the Windows 10 clients that had their workgroup (local domain) changed were still perfectly capable of seeing the Windows 10 clients that did not under network (and vice versa).

 

[BurntMyBacon]

I don't know if that's what your issue is or not, but the router is the local DNS server.

• I'd also verify the following inbound/outbounnd ports are not being blocked
  • TCP: 139, 445
  • UDP 137, 138, 139
• You may also want to check Event Viewer and verify your advanced sharing settings:
  • Control Panel\All Control Panel Items\Network and Sharing Center\Advanced sharing settings

Even, if that's not the issue, it's generally easier for most to utilize host names, over IPs, to access LAN devices (for example, WebUIs), and in conjunction with all LAN devices sharing the same local domain, one would then configure their hosts file in a similar fashion as below:

• %WinDir%\System32\drivers\etc\hosts
  Code:

  #
  
  	 ##::[[---  Windows Host Config  ---]]::##
  
  ####################################################
  			##----- Host Lists -----##
  ####################################################
  
  	# MVPS Hosts #
  #---------------------------------------------------
  
    # Updated: 2017.11.30
  
    # http://winhelp2002.mvps.org/hosts.htm
  
  
  	# Malware Domain List Hosts #
  #---------------------------------------------------
  
    # Updated: 2017.10.26 13:51:30 +0000
  
    # http://www.malwaredomainlist.com/hostslist/hosts.txt
  
  
  ####################################################
  		 ##----- Windows OS Entries -----##
  ####################################################
  
  	# Loopback #
  #---------------------------------------------------
  127.0.0.1		  localhost
  ::1				localhost
  
  
  ####################################################
  				##----- LAN -----##
  ####################################################
  
  	# Sophos UTM #
  #---------------------------------------------------
  192.168.254.10	 FreeNAS1	FreeNAS1.UTM
  
  
  	# WRT1900ACS #
  #---------------------------------------------------
  
    # LAN:
  192.168.255.1	  UTM		 UTM.WRT
  192.168.255.2	  AWL		 AWL.WRT
  192.168.255.3	  AWW		 AWW.WRT
  
  
  192.168.255.21	 C27500	  C27500.WRT
  192.168.255.22	 C27501	  C27501.WRT
  192.168.255.23	 FreeNAS0	FreeNAS0.WRT
  192.168.255.25	 2758F	   2758F.WRT
  192.168.255.60	 LEDE		LEDE.WRT
  192.168.255.61	 ESXi1	   ESXi1.WRT
  192.168.255.62	 ESXi0	   ESXi0.WRT
  

  • The format above is IP <whitespace> Hostname <whitespace> Hostname.LocalDomain
    • For example, to access my FreeNAS WebUI, all I would type in the address bar is: freenas0.wrt or freenas1.utm

The only major issue I'm aware of in Windows 10 in regards to SMB is (within certain environments) upon disabling SMBv1, and enabling SMB3, the OS is no longer able to access Samba shares.

• You may want to try running the Windows 10 network troubleshooter, to see if it identifies any issues: Settings - Search bar > type "Network Troubleshoot"

None of the necessary ports you mentioned are being blocked. It looks like the advanced settings are correct as well.

I agree it is easier for clients to use hostnames rather than IP. I'll go ahead and use the %WinDir%\System32\drivers\etc\hosts edit in the short term. However, I'm going to continue to look for a more ideal solution as this solution has two shortcomings.
1) It requires individual editing for each Windows 10 machine as there is not domain controller to push changes in this environment. This is not insurmountable for the current project as there aren't currently very many clients, but I will not be available to make the changes for new computers as they are introduced to the network. Also, this solution may not be viable for larger workgroups.
2) If the FreeNAS system ever changes IP addresses, each of the hosts files will need to be edited with the new address. It would be better if the configuration details remained at the FreeNAS server or router.

I am going to see if I can't get the router to push a hostname entry to the Windows 10 clients (and everyone else) so I don't have to manually configure each client. I still believe that, given this step is unnecessary for other clients, there must be some Windows 10 and/or FreeNAS (SAMBA) configuration that could resolve this issue.

 

[zoomzoom]

am going to see if I can't get the router to push a hostname entry to the Windows 10 clients (and everyone else) so I don't have to manually configure each client. I still believe that, given this step is unnecessary for other clients, there must be some Windows 10 and/or FreeNAS (SAMBA) configuration that could resolve this issue.

I assumed you had configured FreeNAS with a static IP in your router... I should have asked, as that's likely why you're having issues.

• Without a static IP (of which is where you set the client hostname and client MAC) configured in your router, the router has no idea on how to route traffic to the local DNS hostname.
  • You'll need to set a static IP, similar to:
    Code:

    ip		  192.168.255.23
    mac		 AA:BB:CC:DD:EE:FF
    name		FreeNAS

You may need to reboot the router after applying the change. If a static IP is set in the router, FreeNAS' WebUI > Network should configured for DHCP.

• If you're still having issues, do the following to ensure all changes have been applied:
  • Shutdown the FreeNAS server, then reboot your router. Once the router is fully booted back up, boot the FreeNAS server.

 

[BurntMyBacon]

I assumed you had configured FreeNAS with a static IP in your router... I should have asked, as that's likely why you're having issues.

I have been setting a static address on the FreeNAS server in the range of my reserve pool. Didn't know this could be an issue as it never seemed to be a problem with any OS except Windows 10 and specifically to a Samba server. Samba works with other clients and other services work with Windows 10.

• Without a static IP (of which is where you set the client hostname and client MAC) configured in your router, the router has no idea on how to route traffic to the local DNS hostname.
  • You'll need to set a static IP, similar to:
    Code:

    ip		  192.168.255.23
    mac		 AA:BB:CC:DD:EE:FF
    name		FreeNAS

You may need to reboot the router after applying the change. If a static IP is set in the router, FreeNAS' WebUI > Network should configured for DHCP.

• If you're still having issues, do the following to ensure all changes have been applied:
  • Shutdown the FreeNAS server, then reboot your router. Once the router is fully booted back up, boot the FreeNAS server.

It will probably be Monday before I can take a look at this again, but I will go ahead and give it a shot.

 

[zoomzoom]

Didn't know this could be an issue as it never seemed to be a problem with any OS except Windows 10 and specifically to a Samba server.

I'm not sure why you're having issues, as I've never been able to replicate the issue you, and others, have had in this thread. Also, I don't believe my last post was accurate, as I conflated two separate issues and just realized it as I was reading your reply. Provided the router, samba server, and samba client are all on the same local domain, there shouldn't be an issue accessing the server with only the hostname of the server in Windows Explorer.

• Windows 8+ changed how network devices are laid out in GUI form to the user (I forget what the specific Control Panel screen is in Windows 7, but it allows you to see a GUI layout of the LAN you're connected to).
• When it comes to Samba and Windows 10, there are some issues that are environment specific that I have been unable to find a fix for, let alone how to troubleshoot, however your issue doesn't seem to be Samba related, but network related.

It doesn't make sense to me why navigation occurs perfectly fine via IP, but not via hostname, as they're mutially exclusive provided the router, Samba server, and Samba client are all utilizing the same local domain & workgroup (the latter is specific to Windows).

• It may prove more beneficial for you to configure an Event Viewer filter to see what's going when Windows is trying to access the hostname via Windows Explorer and what errors it's throwing.
• Can you ping the FreeNAS hostname.local from your PC and vice versa on the FreeNAS server (where local is the local domain set by your router)?
  • Windows: ping freenas.local
  • FreeNAS: ping win10.local
  • If either fails, try pinging the IP of each, and if that succeeds, the issue is with the network settings of the router, FreeNAS server, and/or PC.
    • If you're positive all network settings are correct, to rule out settings not being cleared from memory when a network change has been made, completely power off the router, FreNAS server, and PC (if it's a laptop, pull the battery, as well as the power cord), disconnecting the power cables for 5min (hold down the power button of each for 30s, and if the router has a physical toggle switch, flip between On and Off 20x to discharge the capacitors).
    • Power up the devices in the following sequence, allowing each to fully boot before powering on the next device: Router, FreeNAS server, then PC.

 

[BurntMyBacon]

I assumed you had configured FreeNAS with a static IP in your router... I should have asked, as that's likely why you're having issues.

• Without a static IP (of which is where you set the client hostname and client MAC) configured in your router, the router has no idea on how to route traffic to the local DNS hostname.
  • You'll need to set a static IP, similar to:
    Code:

    ip		  192.168.255.23
    mac		 AA:BB:CC:DD:EE:FF
    name		FreeNAS

You may need to reboot the router after applying the change. If a static IP is set in the router, FreeNAS' WebUI > Network should configured for DHCP.

• If you're still having issues, do the following to ensure all changes have been applied:
  • Shutdown the FreeNAS server, then reboot your router. Once the router is fully booted back up, boot the FreeNAS server.

I made a little time to work on it this morning. It appears that setting a Static IP Address on the FreeNAS system and setting a fixed lease IP on the router does, in practice, get different results. I have two FreeNAS systems running for testing purposes. One has a Static IP (set locally), and the other has a fixed lease IP (static address assigned by the router). Even though both have entries in the router's hosts file, only the fixed lease system can be reached via hostname on a Win10 client. Neither are reachable via hostname from a Win10 client without the router hosts file entry. Both are reachable via hostname on Win7 and Ubuntu clients without a hosts file entry and even with non-static DHCP addresses. Both are reachable via IP Address on Win7, Win10, and Ubuntu clients.

This mitigation is workable for now. The only concernable shortcoming is for clients with consumer grade routers that don't expose editing the routers hosts file.

Thanks for your help up to this point. I'm going to keep my eye on this situation for further development and do some more experimentation, but I will use this mitigation for the time being.

 

[BurntMyBacon]

I made a little time to work on it this morning. It appears that setting a Static IP Address on the FreeNAS system and setting a fixed lease IP on the router does, in practice, get different results. I have two FreeNAS systems running for testing purposes. One has a Static IP (set locally), and the other has a fixed lease IP (static address assigned by the router). Even though both have entries in the router's hosts file, only the fixed lease system can be reached via hostname on a Win10 client. Neither are reachable via hostname from a Win10 client without the router hosts file entry. Both are reachable via hostname on Win7 and Ubuntu clients without a hosts file entry and even with non-static DHCP addresses. Both are reachable via IP Address on Win7, Win10, and Ubuntu clients.

This mitigation is workable for now. The only concernable shortcoming is for clients with consumer grade routers that don't expose editing the routers hosts file.

Thanks for your help up to this point. I'm going to keep my eye on this situation for further development and do some more experimentation, but I will use this mitigation for the time being.

Looks like the fix was temporary. It actually stopped working a few days after my previous post, but I didn't have time to mess with it. I can't figure out why it stopped working (or for that matter what particular step made it work in the first place). My current situation is once again that I can reach the share via IP Address from Win7, Win10, Ubuntu, Fedora (new), and FreeBSD (new) systems. The share is reachable via hostname from Win7, Ubuntu, Fedora (new), and FreeBSD (new) systems, but not Win10 systems.

 

[TechGirl]

This whole thread really helped me! Thank you so much...
As soon as I turned on SMB, added the user as a guest account, then started adding paths in FreeNAS for one Windows user, NAS1 showed up and was accessible instantly.

 

[Basil Hendroff]

Time to weigh in on this discussion...

Browsing in the network neighbourhood depends on SMB1. This has been switched off in Windows 10 (build 1709). If you're not too fussed about network browsing and are happy to map drives then, if you can map a share via IP, but not name, there is an issue somewhere with name resolution.

In simple workgroup scenarios, when working with SMB shares (Microsoft, Samba), think NetBIOS name resolution, not hostname resolution, which requires a DNS server or the hosts file. If you're not using LMhosts file or WINS, then NetBIOS name resolution occurs using lossy, non-routable broadcast messages on the LAN segment. The broadcast service is broken under Windows 10, so don't expect NetBIOS name to IP mapping to work out of the box.

Want to debug your SMB name resolution issues? Check out this article.

Personally, I'd rather browse than map, so I've chosen to re-enable SMB1 (risky!). Check out this guide if you're interested in doing the same. Even if you decide not to, the article should provide you with some insight into why browsing and NetBIOS name resolution are broken.

 

[RCarlet]

@Ericloewe said it best. In Windows, it's best to:

• You only need to add a single network share in order to access other shares via Network without typing in an IP/hostname.
  • If you still cannot, reboot the PC
    • If that doesn't solve it, remove the share's login credentials from Control Panel\User Accounts\Credential Manager, then re-access the network share. A login prompt will pop up, enter the username & password, tick to remember the credentials, then OK.

I've struggled over the years with Windows and Samba shares that intermittently stop working. Gone through the whole drill of deleting shares, adding shares, mapping network drives etc. ad nauseam. This is the first time I've come across this solution and to date it has worked like a charm. Can't say thank you enough for this and it will definitely go into my network shares trouble shooting check list.

 

[zoomzoom]

Browsing in the network neighbourhood depends on SMB1.

Where are you getting this information from? SMB2 & SMB3 both support this...

• SMB1 should not be utilized and should be completely removed/disabled via "Turn Windows Features On or Off" in the Control Panel due to the critical security flaws in SMB1
  • SMB1 is exploitable, but more importantly, has been exploited with serious real world consequences for consumers and businesses alike.
• There is no reason to utilize SMB1, as all devices support at least SMB2

I've covered how to fix this numerous times... see the following posts: #15, #18, #23, #27, #30

1. Local domain must be set in the router and echoed across all LAN devices (See 23)
   • In Windows, this would be the WorkGroup name
2. Static IP and hostname must be set in the router for the FreeNAS box (See 30)
3. Windows host file must have an entry in it for the FreeNAS box (See 27)
   • In the format of IP FreeNAS-Hostname FreeNAS-Hostname.LocalDomain

Personally, I'd rather browse than map, so I've chosen to re-enable SMB1 (risky!)

Windows 10 will show all devices under Network, except for Samba servers, so provided one has done the previous things mentioned, all one needs to to do is enter the host name of the Samba server in the address bar in the format of \\HostName

 

[Basil Hendroff]

Where are you getting this information from?

Let me see....Microsoft!...as recently as 30 April 2018. https://support.microsoft.com/en-au/help/4034314/smbv1-is-not-installed-by-default-in-windows

Btw, you'll get no disagreement from me. Just like we browse the internet searching for useful stuff, I just feel mapping drives is a poor substitute for computer browsing, but that's just my opinion. The average, non-computer savvy, home or small business computer user appears to be caught between a rock and a hard place in this regard. Their choices are: safe, but 'someone tell me what I should map to'; or, risky, but 'I can find the stuff I want on my own thank you!'

 

[zoomzoom]

Let me see....Microsoft!...as recently as 30 April 2018. https://support.microsoft.com/en-au/help/4034314/smbv1-is-not-installed-by-default-in-windows

I think you may be conflating how Microsoft uses the Server Message Block and how it relates to Samba servers.

• "The Computer Browser service relies on the SMBv1 protocol to populate the Windows Explorer Network node (also known as "Network Neighborhood"). This legacy protocol is long deprecated, doesn't route, and has limited security."
  
  • With SMBv1 removed, Network (not to be confused with Network Neighborhood, even though whomever wrote that KB article conflated the two terms, which was removed from Win 8+) will not show other computers as an icon under Network, unless those devices have been configured with Bonjour, DLNA, or another zeroconf network configuration, which is why TVs, home theater receivers, printers, game systems, etc. still show up.
    • This does not prevent one from browsing a device not listed, as all that's required to browse the network shares of another device, configure a network share, or map a share as a drive is the hostname or IP of the device.
      • I'm not understanding the issue here, as all that's occurring is cosmetic, i.e. there's no icon for a connected PC/Server, however the PC/Server is still accessible via it's hostname or IP
      • Additionally, it's less efficient to browse a share by navigating to Network first, as it's more efficient [faster] to simply issue the following: [ WinKey]+[ R], then \\hostname or \\IP

...Just like we browse the internet searching for useful stuff, I just feel mapping drives is a poor substitute for computer browsing, but that's just my opinion. The average, non-computer savvy, home or small business computer user appears to be caught between a rock and a hard place in this regard. Their choices are: safe, but 'someone tell me what I should map to'; or, risky, but 'I can find the stuff I want on my own thank you!'

Again, I'm not understanding this, as:

• Network is not required to browse shares, create network shares, or map shares to drives.
• SMBv1 is not secure, is exploitable, and has been exploited against thousands of devices.
  • There is no legitimate reason for using SMBv1, unless one is running Windows 7, as Windows 7 was the last Windows version to offer the Network Neighborhood.