I haven’t found that to be necessary, and it makes no difference with respect to Dolphin’s samba discovery, which is what was being discussed here. It’s nice to have but not essential of course. Originally NT1 (SMB1) was intrinsic to the (network neighbourhood style) discovery process. Since being deprecated, Windows network discovery uses several other approaches (the DNS Client, Function Discovery Resource Publication, SSDP Discovery, and UPnP Device Host services) to discover hosts. To me, Dolphin now needs to employ approaches consistent with these changes.
If I run something like this, I see shares on the network reported…
Hmmm … I’ve just setup a Leap 42.3 Test user as a “fresh, newly configured, empty” (KDE) user – Dolphin version 17.04.2 comes up with my local SMB Workgroup within a few seconds and, it’s finding the SMB (NAS) Shares there within a few seconds and, the Access Controls are functioning as expected …
What changed with Leap 15? AFAIK, nobody, myself included, noticed anything during the Beta testing … – I’ll check the Leap 15 I have lying around here in a VM …
The same problem I noticed since February 2018 - with Tumbleweed and Fedora KDE.
I am not an expert but I did not think that is a samba’s problem because Gnome Files (3.26 and 3.28) discover my local Workgroup.
It is due to samba changes which have impacted on libsmbclient and it’s ability to discover workgroups/shares when ‘client min protocol = SMB2’. Gnome Files (Nautilus) apparently gets around this by explicitly using the NT1 protocol for discovery purposes only. Read the following for a comprehensive discussion about this…
@farcusnz:
Did you take a look at the openSUSE Leap 15.0 Firewall settings?
[HR][/HR]I’m writing this on a freshly installed “default” Leap 15 system running in an Oracle VirtualBox VM, with the network interface set to “Network Bridge”.
I changed only two system settings via YaST: the SMB Workgroup and BIOS System Name used by Samba.
Dolphin complained that it couldn’t find any SMB Shares, with an explanation with respect to the Firewall.
YaST ==>> Firewall – a Firewall module was installed – started it – totally new – on closer inspection it’s a Red Hat module …
Default Zone: “Public”
For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.
Changed the Zone being used by the Network Interface (‘eth0’) to “Trusted”
All network connections are accepted.
Et Voilà!! Dolphin is able to find my local Windows Workgroup …
I played around a bit with a couple of other Firewall profiles: “Home” and “Work” – Dolphin refused to browse SMB shares when these profiles were used but, there’s an ominous setting on the Profiles: “Target” – clearing the check mark on the “Home” and “Work” profiles seemed to have some effect on Dolphin’s SMB search behaviour but, I broke the (Red Hat) YaST module somewhere along the line – cleaned up the mess in /etc/firewalld/ and went back to simply using the Profile “Trusted”.
I’m not currently using any active firewalls for my two Linux machines, and NetBIOS discovery is not working (consistent with other recent forum threads and bug reports). That doesn’t stop me browsing succeffully with an explicit ‘smb://<netbios_name>’ though.
An interesting Ubuntu thread on the same topic, and discussing some ideas…
Samba on the Linux desktop never gets a break.
Ubuntu 18.04 contains version 4.7.4 of the samba client libraries which brings with it a lot of improvements but it changes one parameter that will cause this forum nothing but grief. It changes the upper default smb dialect that the samba client uses to SMBv3.11 from the earlier default of NT1 ( Samba speak for SMBv1 ).
AFAIK, the Buffalo devices usually have an NFS Server built in – I do not know if they support NFS4 or “only” NFS3.
no, unfortunately Buffalo Linkstations do not support NFS (at least the two models I am using). There did used to be a third party firmware which added nfs support for my older linkstation but the developer stopped updating this a year or two ago.
Did you take a look at the openSUSE Leap 15.0 Firewall settings?
Yes, even with the firewall disabled I was still seeing the same problem.
As I mentioned earlier, I have been seeing the same problem in raspberry pi (OSMC which I believe is built on debian stretch).
I noticed a post in the OSMC forums which stated . . .
Browsing the workgroup is a feature of smb v1 which is being removed due to it being a 30 year old protocol riddled with security issues. We see the same thing on windows networks when smb v1 is removed. To my knowledge you need to use another advertisement protocol like Bonjour, but in practise it’s not necessary once you’ve got used to the change in behaviour.
Could this be the same reason we are seeing the issue in Leap 15?
New Installer and Partitioner, Moving to Firewalld
Leap 15 further improves one of openSUSE’s most powerful tools YaST. For example, the partitioner’s Libstorage-ng subsystem has been reworked, making it more powerful and reliable and taking ease-of-use to a new level. The same applies for the move from SuSEfirewall2 to the widely used firewall management tool Firewalld which provides better integration with dynamic network setups.
…
This release of Leap has a new firewall solution. Changes were made to move from SuSEfirewall2 to the firewall management tool FirewallD, which is very interactive and powerful.
Yes, as I’ve explained more than once in this thread.
Nautilus (now Gnome Files) has an advantage with this - Combined with Avahi SMB service publishing, it is capable of showing such remote shares (refer to the Ubuntu thread I linked to). Dolphin isn’t currently aware of this mechanism unfortunately.
I’m well aware of that already (I even switched to using/testing it in Leap 42.3). It is NOT what is causing this issue here as I’ve already explained. I don’t even have an active firewall on my openSUSE machines.
Then, please explain why, with a default, freshly installed, Leap 15 system with an active Firewalld set to the Profile “Trusted”, everything SMB works just fine.
Maybe, a comparison between a default freshly installed Leap 15 system and farcusnz’s Leap 15 setup has to be made …
And another thought, it may be that, to really disable “Firewalld”, it needs to be deinstalled …
Please note that it is only host (NetBIOS) discovery that is not working, and those reasons are actually understood. I too can browse a share without issue.
And another thought, it may be that, to really disable “Firewalld”, it needs to be deinstalled …
Given that, ‘iptables’ and ‘ip6tables’ are part of the Linux Kernel (they can only be removed by rebuilding the Kernel and omitting them … ), I’m not convinced that, simply disabling the systemd service for Firewalld will disable the Firewall as such …
Please check the output of ‘iptables --list --verbose’ and ‘ip6tables --list --verbose’.
Looking through the documentation of Firewalld, I’m not convinced that the thing can be “disabled” as such – in fact, I’m beginning to suspect that, if the systemd service is disabled, and therefore the Firewalld daemon as well, the Kernel’s iptables will be left in a “safe” mode – i.e. “everything blocked” …
In other words, you’ve killed the daemon (firewalld) which controls the Linux Kernel’s built-in Firewall (iptables) and left the Kernel’s Firewall in an indeterminate state …
You have a misunderstanding about how this works. When firewalld is stopped, there are no active firewall rules. It would a completely flaky situation if it didn’t. Check for yourself about how this works.
# iptables --list --verbose
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
This is the last post I will make about firewalls in this thread. The samba client issue is known (read the bug reports). It’s as a direct result of security changes to the minimum samba protocol in use. It can be overridden but has security implications if done globally via smb.conf, and servers not supporting NT1 won’t work with such a workaround of course. There has been talk of implementing other protocols (as Windows now does) to include Avahi, SSDP etc (refer post #25).
