These days I relatively often need to work with Windows 10 at home (home-office, corona virus, ...). Normally, I isolate my own Win 10 instance in a VMware virtual machine. But on a few temporary occasions I want to the Win 10 system to access a Samba exchange directory on a KVM virtualized Linux instance. (I do not like Windows to directly interfere with my hosts!)
Of course we want to use the SMB protocol in a modern version, i.e. version 3.x (SMB3) over TCP/IP for this purpose (port 445). In addition we need some mechanism to detect SMB servers. In the old days NetBIOS was used for the latter. On the Linux side we had the nmbd-daemon for it - and we could set up a special Samba server as a WINS server.
Microsoft - via updates and new builds of Windows 10 - has during the last year followed a consistent policy of deactivating the use of SMBV1.0 systematically. This, however, led to problems - not only between Windows PCs, but also between Win 10 instances and Samba 4 servers. This article addresses one of these problems: the missing list of available Samba servers in the Windows Explorer.
There are many contributions on the Internet describing this problem and some even say that you only can solve it by restoring SMBV1 capabilities in Win 10 again. In this article I want to recommend two different solutions:
- Ignore the problem of Samba server detection and use your Samba shares on Win 10 with the SMB3 protocol as network drives.
- If you absolutely want to see and list your Samba servers in the Windows Explorer of a Win 10 client, use the "Web-Service-Discovery" service via a WSD-daemon provided by a Python script of Steffen Christgau.
I should say that I got on the right track of solving the named problem by an article of a guy called "Stilez". His article is the first one listed under the section "Links" below. I recommend strongly to read it; it is Stilez who deserves all credit in pointing out both the problem and the solution. I just applied his insight to my own situation with virtualized Samba servers based on Opensuse Leap 15.1.
SMB V1.0 should be avoided - but NetBIOS needs it to exchange information about SMB servers
SMB, especially version SMB1.0, is well known for security problems. Even MS has understood this - especially after the Wannacry disaster. See e.g. the links in the section "Links" => "Warnings of SMBV1" at the end of this article. MS has deactivated SMBV1 in the background via some updates of Win 8 and Win 10.
One of the resulting problem is that we do not see Samba servers in the Windows Explorer any longer. In the section "Network" of the Explorer you normally should see a list of servers which are members of a Workgroup and offer shares.
Two years ago it was clear that we would use NetBIOS's discovery protocol and a WINS server to get this information. Unfortunately, the NetBIOS service detection ability depends on SMB1 features. The stupid thing is that we for a long while now had and have a relatively secure SMB2/3, but NetBIOS discovery only worked with SMBV1 enabled on the Windows client. Deactivating SMBV1 means deactivating NetBIOS at the same time - and if you watch your Firewall logs for incoming packets from the Win 10 clients you will notice that exactly such a thing happened on Win 10 clients.
This actually means that you can have a full featured Samba/NetBIOS setup on the Linux side, have opened the right ports on the firewalls for your Samba/WINS server and client systems, but still you will not get any display of available Samba servers on a Win 10's Explorer. 🙁
Having understood this leads to the key question for our problem:
By what did MS replace the detection features of NetBIOS in combination with SMB-services?
Settings on the MS Win side - which alone will not help
When you google a bit regarding the problem of a missing list of network servers in the Windows Explorer you find many hints regarding settings by which you activate network "discovery" functionalities via two Windows services. See
You can follow these recommendations. If you want to see your own PC and other Windows systems in the Explorer's list oif network resources you must have activated them (see below). However, in my Win 10 client the recommended settings were already activated - with the exception of SMBV1, which I do not wish to reactivate again. The "discovery" settings may directly help with other Windows systems, but they do not enable a listing of Samba 4 servers without additional measures.
Then we find another category of hints, which in my opinion are contra-productive regarding security. See https://devanswers.co/network-error-problem-windows-cannot-access-hostname-samba/
Why activate an insecure setting? Especially, as such a setting does not help with our special problem? 🙁
A last set of hints concerns the settings on the Samba server. I find it especially nice when the recommendations come from Microsoft. See: http://woshub.com/cannot-access-smb-network-shares-windows-10-1709/
[global] server min protocol = SMB2_10 client max protocol = SMB3 client min protocol = SMB2_10 encrypt passwords = true restrict anonymous = 2
Well, these are kind hints. Thx MS - we Linux users were too stupid up to now to understand that we should not use SMBV1 .... But, actually, these hints are insufficient regarding the Explorer problem ...
What you could do - but should NOT do
Once you have understood that NetBIOS and SMBV1 still have an intimate relation (at least on the Windows systems) you may get the idea that there might exist an option to reactivate SMBV1 again on the Win 10 system. This is indeed possible. See here:
If you follow the advice of the authors and in addition re-open the standard ports for NetBIOS (UDP) 137, 138, (TCP) 139 on your firewalls between the Win 10 machine and your Samba servers you will - almost at once - get up the list of your accessible Samba servers in the Network section of the Win 10 Explorer. (Maybe you have to restart the smb and nmb services on your Linux machines).
But: You should not do this! SMBV1 should definitely become history!
Fortunately, we will find out that a re-activation of SMBV1 on a Win 10 system is NOT required to mount Samba shares on Win 10 and that it is not even necessary to get a list of Samba servers in the Explorer.
What you should do: Win 10 service settings
There are two service settings which are required to see other servers and also your own Win10 PC itself in the list of network hosts in the Windows explorer:
Start services.msc (Windows key + R => Enter "services.msc" in the dialog / or start it via the Control Panel => System and Security => Services)
- Look for "Function Discovery Provider Host" => Set : Startup Type => Automatic
- Look for "Function Discovery Resource Publication" => Set : Startup Type => Automatic (Delayed Start) !!
I noticed that on my VMware Win 10 guests the second setting appeared to be crucial to get the Win 10 PC itself listed among the network servers.
What you should do: Use the SMBV3 protocol!
As you as a Linux user meanwhile have probably replaced all your virtualized Win 7 guests, you should use the following settings in the [global] section of the configuration file "/etc/samba/smb.conf" of your Samba servers:
"protocol = SMB3".
That is what Win 10 supports; you need SMB2_10 with some builds of Win 8 (???), only. Remember also that port 445 must be open on a firewall between the Win 10 client and your Samba server.
For Linux requirements to use SMB3 see
https://wiki.samba.org: SMB3 kernel status
For "SMB Direct" (RDMA) you normally need a kernel version > 4.16. On Opensuse Leap 15.1 most of the required kernel features have been backported. In Win 10 SMB Direct is normally activated; you find it in the "Window-Features" settings (https://www.windowscentral.com/how-manage-optional-features-windows-10)
Not seeing Samba servers in the Explorer does not mean that mounting Samba shares as network drive does not work
Not seeing the Samba servers in the Win 10 Explorer - because the NetBIOS detection is defunct - does not mean that you cannot work with a Samba share on a Win 10 system. You can just "mount" it on Windows as a "network drive":
Open a Windows Explorer, choose "This PC" on the left side, then click "Map network drive" in the upper area of the window and follow the instructions:
You choose a free drive letter and provide the Samba server name and its share in the usual MS form as "\\SERVERNAME\SHARE".
Afterwards, you must activate the option "Connect using different credentials" in the dialog on the Win 10 side, if your Win 10 user for security reasons has a different UID and Password on the Samba server than on Win 10. Needless to say that this is a setting I strongly recommend - and of course we do not allow any direct anonymous or guest access to our Samba server without credentials delivered from a Windows machine (at least not without any central authentication systems).
So, you eventually must provide a valid Samba user name on your Samba server and the password - and there you happily go and use your resources on the Samba share from your Win 10 client.
I assumed of course that you have allowed access from the Win 10 host and the user by respective settings of "hosts allow" and "valid users" for the share in your Samba configuration.
Note: You need not mark the option for reconnecting the share in the Windows dialog for network drives if you only use the Samba exchange shares temporarily.
On an Opensuse system this works perfectly with the protocol settings for SMB3 on the server. So, you can use your shares even without seeing the samba server in the Explorer: You just have to know what your shares are named and on which Samba servers they are located. No problem for a Linux admin.
In my opinion this approach is the most secure one among all "peer to peer"-approaches which have to work without a central network wide authentication service. It only requires to open port 445 for the time of a Samba session to a specific Samba server. Otherwise you do not provide any information for free to the Win 10 system and its "users". (Well, an open question is what MS really does with the provided Samba credentials. But that is another story ....)
What you should do: Use WSDD service on your Samba server
If you allow for some information sharing between your virtualized Win 10 and other KVM based virtual Samba machines in your LAN - and are not afraid of Microsoft or Antivirus companies on the Windows system to collect respective information - then there is a working option to get a stable list of the available Samba servers in the Windows Explorer - without the use of SMBV1.0.
Windows 10 implements web service detection via multiple mechanisms; among them: Multicast messages over ports 3702 (UDP), TCP 5357 and 1900 (UDP). For a detection of Samba services you "only" need ports 3072 (UDP) and 5357 (TCP). The general service detection port 1900 can remain closed in the firewalls between your Win 10 instances and your Linux world for our specific purpose. See
https://en.wikipedia.org/wiki/Simple Service Discovery Protocol
The mechanism using ports 3702 and 5351 is called "Web Service Discovery" and was introduced by MS to cover the detection of printers and other devices in networks. In combination with SMB2 and SMB3 it is used today to detect SMB-services, too.
OK, do we have something like a counter-part available on a Linux system? Obviously, such a service is not (yet?) included in Samba 4 - at least not in the 4.9 version on my Opensuse system. WSD is not (yet?) a part of Samba - maybe for good reasons. See link.
One can understand the reservations and hesitation to include it as WSD also serves other purposes than just the detection of SMB services.
Fortunately, a guy named Steffen Christgau, has written an (interesting) Python 3 script, which offers you the basic WSD functionality. See https://github.com/christgau/wsdd.
You can use the script in form of a daemon process on a Linux system - hence we speak of WSDD.
Using YaST I quickly found out that a WSDD RPM package is actually included in my "Opensuse Leap 15.1 Update" repository. People with other Linux distros may download the present WSDD version from GitHub.
On Opensuse it comes with an associated systemd service-file which you find in the directory "/usr/lib/systemd/system".
[Unit] Description=Web Services Dynamic Discovery host daemon After=network-online.target Wants=network-online.target [Service] Type=simple AmbientCapabilities=CAP_SYS_CHROOT PermissionsStartOnly=true Environment= WSDD_ARGS=-p ExecStartPre=/usr/lib/wsdd/wsdd-init.sh EnvironmentFile=-/run/sysconfig/wsdd ExecStart=/usr/sbin/wsdd --shortlog -c /run/wsdd $WSDD_ARGS ExecStartPost=/usr/bin/rm /run/sysconfig/wsdd User=wsdd Group=wsdd [Install] WantedBy=multi-user.target
Reading the documentation you find out that the daemon runs chrooted - which is a reasonable security measure.
And, nicely, Opensuse provides an elementary configuration file in "/etc/sysconfig/wsdd".
I used the parameter
there to announce the right Workgroup for my (virtualized) Samba server.
So, I had everything ready to start WSDD by "rcwsdd start" (or by "systemctl start wsdd.service") on my Samba server.
On a local firewall at the server I opened
- port 445 (TCP) for SMB(3) In/Out for the server and from/to the Win-10-Client,
- port 3702 (UDP) for incoming packets to the server and outgoing packets from the server to the Multicast address 184.108.40.206,
- port 5357 (TCP) In/Out for the server and from/to the Win 10 client.
And I closed all NetBIOS ports (UDP 137, 138 / TCP 139) and stopped the "nmbd"-service on the Samba server! (UDP 137, 138 / TCP 139)
But, within a second or so, my Samba 4 server appeared in the Windows 10 Explorer!
As the 3702 port is used with the UDP protocol it should be viewed upon as basically and potentially dangerous. See: https://blogs.akamai.com/sitr/2019/09/new-ddos-vector-observed-in-the-wild-wsd-attacks-hitting-35gbps.html
The port 1900 which appeared in the firewall logs does not seem to be important. I blocked it.
So far, so good. However, when I refreshed the list in the Win 10 Explorer my SAMBA server disappeared again. 🙁
What you should do: Take special care about the network interface which WSDD should be attached to
It took me a while to find out that the origin of the last problem had to do with the fact that my virtualized server and my Win 10 client have (multiple) network interfaces on virtualized bridges (without loops in the network). It seems, however, that multiple broadcasts arrive at the server via the KVM bridge and are answered - and thus multiple return messages appear at the Win 10 client during a refresh - which Win 10 does not like (see the discussion in the following link.
When I restricted the answer of the server to exactly one bridged interface via the "/etc/sysconfig/wsdd"-configuration file with the parameter "WSDD_INTERFACES" everything went fine. Refreshes now lead to an immediate update including the Samba server.
So, be a little careful, when you have some complicated bridge structures associated with your virtualized VMware or KVM guests. The WSDD service should be limited to exactly one interface of the server.
Note: As we do not need NetBIOS any longer - block ports 137, 138 (UDP) and 139 (TCP) in your firewalls now! Made me feel better instantaneously.
The "end" of SMBV1 on Win 10 is a reasonable step. However, it undermines the visibility of Samba servers in the Windows Explorers. The reason is that NetBIOS requires SMB1.0 features on Windows. NetBIOS is/was therefore consistently deactivated on Win 10, too. The service detection on the network is replaced by the WSD service which was originally introduced for printer detection (and possibly other devices). Activating it on the Win 10 system may help with the detection of other Windows (8 and 10) systems on the network, but not with Samba 4 servers. Samba servers presently only serve NetBIOS requests of Win clients to allow for server and share detection. Therefore they will not be displayed in the Windows Explorer of a regular Win 10 client.
This does, however, not restrict the usage of Samba shares on the Win 10 client via the SMB3 protocol. They can be used as "network drives" just as before. Not distributing name and device information on a network has its advantages regarding security.
If you absolutely must see your Samba servers in the Win 10 Explorer install and configure the WSDD package of Steffen Christgau. You can use it as a systemd service. You should restrict the interfaces WSDD gets attached to - especially if you have your servers on virtualization bridges (Linux bridges or VMware bridges).
- Disable SMBV1 in Windows 10 if an update has not yet done it for you!
- Set the protocol in the Samba servers to SMBV3!
- Try to work with "networks drives" on your Win 10 guests, only!
- Install, configure and use WSDD, if you really need to see your Samba servers in the Windows Explorer.
- Open the port 445 (TCP, IN/OUT between the Win 10 client and the server), 3072 (UDP, OUT from the server and the Win 10 client to 220.127.116.11, IN to the server from the Win 10 client / IN to the Win 10 client from the server; rules details depending on the firewall location), port 5357 (TCP; In/OUT between the Samba server and the Win 10 client) on your firewalls between the Samba server and the Win 10 system.
- Close the NetBIOS ports in your firewalls!
- You should also take care of stopping multicast messages leaving perimeter firewalls; normally packets to multicast addresses should not be routed, but blocking them explicitly for certain interfaces is no harm, either.
Of course you must repeat the WSDD and firewall setup for all your Samba servers. But as a Linux admin you have your tools for distributing common configuration files or copying virtualization setups.
The real story
!!!! / !!!
Warnings of SMBV1
Problems with Win 10 and shares
https://social.technet.microsoft.com/ Forums/ en-US: cannot-connect-to-cifs-smb-samba-network-shares-amp-shared-folders-in-windows-10-after-update?forum=win10itpronetworking
RDMA and SMB Direct
https://searchstorage.techtarget.com/ definition/ Remote-Direct-Memory-Access
Other settings in the SMB/Samba environment of minor relevance
https://www.reddit.com/ r/ techsupport/ comments/ 3yevip/ windows 10 cant see samba shares/