Issue with Samba 4.2.4-15.1 net rap server domain -S <your_master_browser> command fails

Since updating to Samba 4.2.4-15.1 the net rap server domain -S <your_master_browser> command fails to return a list of machines in the workgroup (or domain) which causes SMB4K not to work correctly. Reverting back to the Samba 4.2.4-12.1 version restores this command to a working state. I cant find anything in bugzilla so I guess I need to raise a ticket in bugzilla. Unless someone here knows different!


I have now installed Tumbleweed as a dual boot system and this command also fails in Tumbleweed with Samba 4.4.2-1.1

I have reported this in bugzilla as #976953 against Tumbleweed but have mentioned the same in Leap as well.


Wondering if you’ve updated your system <very> recently

zypper up

Another recent Forum post described their NetBIOS port was closed for some unknown reason, but was resolved by a very recent update.

Another way to troubleshoot would be to temporarily drop your SUSE FW before running your “net rap” command.

Also, according to the SAMBA documentation maybe you should be running the following command instead?

 net rap session -S MERLIN -Uroot%not24get


Yes my Leap system was fully updated and the command I used was the one recommended by the SMB4K author. On this brand new Tumbleweed system the command you mention fails with ‘Unable to find a suitable server for domain DISORGANISATION’ and yes that is the correct Workgroup name. I am still able to use Samba and SMB4K will mount my shares if I use the mount menu and save as a bookmark, it is just the network neighbourhood which does not work correctly. Also the SMB4K author has told me today he sees this issue as well on his recently updated Kubuntu system as well and he believes this to be a Samba issue as there are other reports elsewhere on this error.


“Unable to find a suitable server for domain…” suggests a name resolution issue?

  • Try dropping the FW temporarily as I described to check whether the used port is blocked (don’t know if you have NetBIOS or Hostname resolution configured)

How did you manually mount your SAMBA share, using a NetBIOS or Hostname, or did you use an IP address? If you used a name, then the following try is unnecessary but if you used an IP address then the following may be an important try.

  • Try configuring a Hosts file or create a LMHosts file with the required information (which would include both the machine name and the domain). This provides an alternative to network directory services which can be unreliable in a Workgroup which is the User logging in to the local machine (more certain when Network Security is implemented, ie logging in to a network User account using something like LDAP or AD).

You’ve already established that SAMBA itself seems to be working by mounting the share manually, so your problem has been narrowed down to a directory services type issue.

The above may narrow down your problem to a specific networking problem, not necessarily but possibly related to SAMBA.


Thinking about your situation further,
I’m more and more convinced your problem is likely a Workgroup Browsing issue on its own, and most likely a Master Browser issue.

So, first
I reviewed most current Windows Workgroup browsing and found that <if> your Master Browser is a Windows machine, there is a plethora of various network discovery methods and protocols used today.

But, if you’re connecting to a true SAMBA server, likely on an openSUSE (or other Linux) Host, there are still only two methods… NetBIOS name resolution and Hostname resolution. I won’t go into a deep re-description of these two methods, it can be read in various original documentation including SAMBA’s own

The above 2 links are probably still a good review for NetBIOS and Hostname resolutions, and the second link includes some troubleshooting suggestions.

But, in a Workgroup (when you’re not running a true Network Security where the User logs into a Network account instead of a local account on the machine in front of them) possibly the most effective thing you can do if you haven’t already done so is to

Disable the ability to become the Browse Master on every machine but your SAMBA server.

Steps how to do this on both Linux and Windows machines are described in the SAMBA links above.
Remember after making this change the machine then has to either purge manually or just reboot to clear the local cache.

This forces every machine in your network to never be confused looking for the Browse Master with its directory services, they will always use your SAMBA server. Without this critical setting, for at least short periods of time, it’s possible for any other machine in your network to become the Browse Master which of course kills your able to browse your network (No machine maintains the list except for your SAMBA server).


I realise all this but the bottom line here is that a net command does NOT work as it should and therefore this is a Samba bug which needs fixing, all of the other stuff is quite frankly irrelevant. Once the net command works as it should then my problem will go away. I have a work round for the issue so I am quite happy to wait for Samba to fix the issue, especially since the author of SMB4K who seems to know quite a lot about this problem also feels this is a bug in Samba which needs fixing…


If what I suspect is the cause of your problem, it’s not a SAMBA problem so won’t be fixed by SAMBA.

This is a fundamental problem with Workgroup networking, the Browse Master role may migrate from one machine to another and without the setting I highly recommend will cause network browsing downtime. The Master Browser migration problem will happen most often after the following kinds of changes in your network because they relate to the things that are used to elect a Browse Master

  • A new machine in your network with later/latest hardware
  • One or more machines are upgraded with new hardware (Will appear as a newer machine)
  • System software upgrades, in particular kernel upgrades. Other software device driver upgrades might also affect.

So, from the above list since Linux Best Practices includes at least patching and more likely updating on a regular basis, you can have unexpected Browse Master migrations which you have to prevent.


Well allow me to explain.

Firstly none of my machines on the network have changed and all but one are Linux, the odd one is a Windows 7 laptop which runs 24x7 and none of the others do. The machines themselves have not changed and all the Linux boxes are up to date.

The problem first appeared when I updated from 4.2.4-12.1 on Leap to 4.2.4-15.1 and going back to the previous level it all works again so something changed in Samba to cause this. I then tried a new Tumbleweed install fully updated as a dual boot on one PC and it still exhibits the self same issue, the command mentioned fails to return any valid data. My initial thought was SMB4K which is why I asked the author for his help, he suggested the symptoms I see was because this net command does not return a list of machines in the network and sure enough that is true. Tumbleweed by the way uses Samba 4.4.2-1.1. The author then followed up with a comment that after updating his machine (Kubuntu I believe) he sees the same issue and he found several other reports of the problem elsewhere. So all the evidence points to a bug in Samba and I also believe that this is likely to be the after effect of a security update as it seems to affect more than one release.

So unless someone can prove otherwise I do expect Samba to at the very least take these reports seriously and take a close look.


I have now found that this is a Samba bug which can be viewed at there is a work around which I have tested and works for SMB4K but breaks the Dolphin access to Samba shares, see comment 11 in the bug report. Also at comment 14 it mentions patches which are being tested and should roll out soon. Apparently this bug was introduced with a security update to Samba hence it affecting more than one release.


According to this thread, there is a problem negotiating the most advanced protocol available.
Either the more advanced protocol itself is broken or the handshaking might have a bug (Note: Many Servers are configured with max protocol NT1 while clients are configured with SMB3). It seems that the suggested workaround you’re pointing to sets both client and server to the same, eliminating version negotiation, but NT1 is not very current.

Am thinking that if the workaround you’re using has a problem with Dolphin directly accessing the share, you might try mounting the share separately, then pointing Dolphin to the local mount point. Should avoid Dolphin insisting on a “better” protocol version. Would be a workaround building on the workaround until the true nature of the problem is determined.

And from the description in the thread, I don’t think the patches are anything more than a temporary fix, the actual problem isn’t fixed because they haven’t figured out exactly what is the problem.


Yes OK I am merely pointing out that this IS a Samba bug and eventually will be resolved as they have been able to recreate the issue. There are a couple of workarounds, either dont apply the smb.conf changes and set up bookmarks in SMB4K which do allow mounting and allow Dolphin to work, or apply the smb.conf changes and use SMB4k as normal and dont access shares directly with Dolphin - the users choice.

Bottom line is it IS a Samba bug and hopefully will br resolved soon. It was definitely caused by a security update which obviously was not tested properly.