First sorry , I want report to product-workstation at first time. 
After many tests I came to the conclusion if samba service is not enable in firewall , the  detection of network neighborhood fails many times , but after the network neighborhood detected, I can see the computers without samba service enabled, the problem is in initial detection . 

Thanks.

This is a problem on Fedora 24. I can only browse Samba shares from the Trusted zone in Dolphin regardless of having samba and samba-client services enabled in a different zone.

This happens on F23, I have a setup here.

The problem is in firewalld, it needs to enable access to source port 137 and protocol UDP when samba-client is allowed.

Current samba sends an ICMP with sport 137 and protocol UDP, which contains some netbios information for the samba network master. This packet is blocked by firewalld.

(In reply to gala_dragos from comment #3)
> This happens on F23, I have a setup here.
> 
> The problem is in firewalld, it needs to enable access to source port 137
> and protocol UDP when samba-client is allowed.
> 
> Current samba sends an ICMP with sport 137 and protocol UDP, which contains
> some netbios information for the samba network master. This packet is
> blocked by firewalld.

smbclient opens ports 137/udp and 138/udp , we need something else ? , I didn't understand

you need to add port 137 as source port also. I'll make a screenshot when I get home.

Created attachment 1208077 [details]
screenshot of adding the samba source port 137 UDP.

firewalld also needs this setting for letting samba-client to work. Might be necessary for the samba server as well, put I haven't tested that.

(In reply to gala_dragos from comment #5)
> you need to add port 137 as source port also. I'll make a screenshot when I
> get home.

ah ok ! thanks for the info .

When I checked the services for firewalld I had 137 udp open but still could not browse my shares in Dolphin (on Fedora 24)

I checked the Samba documentation on ports - https://wiki.samba.org/index.php/Samba_port_usage

All 3 of these list port 135 for the "End Point Mapper (DCE/RPC Locator Service)"

When I added port 135 tcp to my Samba service file (/usr/lib/firewalld/services/samba.xml) I was then able to successfully browse my Samba shares.

(In reply to JR Peck from comment #8)
> When I checked the services for firewalld I had 137 udp open but still could
> not browse my shares in Dolphin (on Fedora 24)
> 
> I checked the Samba documentation on ports -
> https://wiki.samba.org/index.php/Samba_port_usage
> 
> All 3 of these list port 135 for the "End Point Mapper (DCE/RPC Locator
> Service)"
> 
> When I added port 135 tcp to my Samba service file
> (/usr/lib/firewalld/services/samba.xml) I was then able to successfully
> browse my Samba shares.

Try "smbtree" command, if it shows network shares then it's a Dolphin problem.

You need fuse-smb to browse samba from a file browser.

I can remove the change I made to the service file when I'm back in the office tomorrow and try that but I do think it was the fact that the firewall was blocking a port that needed to be open.

As I worked my way through the problem the first thing I tried was shutting the firewall down - when I did then I could browse my shares normally in Dolphin. When I started the firewall back up I was unable to do so.

And if it were a Dolphin problem - I would expect that the changes I made to unblock the port wouldn't have fixed the situation either - but they did.

I am not technical enough to know whether or not everyone needs 135 unblocked to use the samba client successfully on a network but I thought this seemed like the best place to report it in case it is a change that is needed to the service definition. If not I apologize.

Please have a look at firewalld version 0.4.4.1. This will be available in testing soon and should fix this issue.

firewalld-0.4.4.1-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d2828a4793

firewalld-0.4.4.1-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-8d90406113

firewalld-0.4.4.1-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c57b0ba2d4

firewalld-0.4.4.1-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d2828a4793

firewalld-0.4.4.1-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c57b0ba2d4

firewalld-0.4.4.1-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8d90406113

firewalld-0.4.4.1-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

firewalld-0.4.4.2-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3dd8b5f4e1

firewalld-0.4.4.2-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b566ecf579

firewalld-0.4.4.2-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b566ecf579

firewalld-0.4.4.2-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3dd8b5f4e1

firewalld-0.4.4.2-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

firewalld-0.4.4.2-2.fc23 selinux-policy-3.13.1-158.25.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-8a0533d057

I'm using Fedora 24 with firewalld-0.4.4.2-1.fc24 and firewalld-selinux-0.4.4.2-1.fc24.noarch

I thought I had solved the issue by opening the ports I had mentioned above but I find that now it is not fixed.

With firewalld running smbtree returns nothing. When I stop firewalld and run smbtree I get back the expected list of shares available on my network.

I apologize if this is the wrong place to put this now - I'm really not sure what to do. I don't use the samba shares on our network a lot and I'm behind a corporate firewall so I just shut it down on my machine for the brief time I need to access the samba shares.

But others may have this issue so I'm trying to help.

Hi, I'm using Fedora24 and ever since upgrading from Fedora 23 to 24, I found I could no-longer browse for Shares on my home NAS server from this Fedora 24 client while it's Firewall was running.

As other's have reported, closing down the firewall would allow browsing for shared folders to work again.

However the good news is, that after reading through this bug report I saw mention of the need to have a source port open, namely 137 udp.

I haven't noticed source ports being mentioned in other reports about this particular samba browsing bug, even the Samba wiki site didn't seem to make it clear that a source port was needed, in addition to other ports being open. But I may have just missed the reference to source ports.

I had already added numerous suggested ports under the "Ports" section in Firewall configuration tool, but found it hadn't fixed the problem. 
I was using the HOME Zone as my default before I upgraded to Fedora24 and had to change it back to that default Zone after the upgrade because the default zone had changed during the upgrade process.


So after reading about the need for specifying a "Source port", I tested adding in a 137 udp "Source Port" as well as having the other Ports listed under "Ports" section, then when I reloaded the firewall I found I was able to browse to my network shares again.


It seems then, that when I had upgraded from Fedora 23 to 24, the installation had taken out (or not put in) the 137 udp Source Port reference in the Firewall configuration file, as well as having changed my default zone from the previous installation.

At present my Browsing of shared folders is working again, so lets see if it stays like that when I upgrade to Fedora 25.

firewalld-0.4.4.2-2.fc23, selinux-policy-3.13.1-158.25.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8a0533d057

(In reply to Matthew from comment #26)
> Hi, I'm using Fedora24 and ever since upgrading from Fedora 23 to 24, I
> found I could no-longer browse for Shares on my home NAS server from this
> Fedora 24 client while it's Firewall was running.
> 
> As other's have reported, closing down the firewall would allow browsing for
> shared folders to work again.
> 
> However the good news is, that after reading through this bug report I saw
> mention of the need to have a source port open, namely 137 udp.
> 
> I haven't noticed source ports being mentioned in other reports about this
> particular samba browsing bug, even the Samba wiki site didn't seem to make
> it clear that a source port was needed, in addition to other ports being
> open. But I may have just missed the reference to source ports.
> 
> I had already added numerous suggested ports under the "Ports" section in
> Firewall configuration tool, but found it hadn't fixed the problem. 
> I was using the HOME Zone as my default before I upgraded to Fedora24 and
> had to change it back to that default Zone after the upgrade because the
> default zone had changed during the upgrade process.
> 
> 
> So after reading about the need for specifying a "Source port", I tested
> adding in a 137 udp "Source Port" as well as having the other Ports listed
> under "Ports" section, then when I reloaded the firewall I found I was able
> to browse to my network shares again.
> 
To allow the source port for samba is a work around that opens a big hole in the firewall.

Because of a kernel change it is needed since kernel 4.7 to use the netfilter conntrack helpers in a different way than before. This also applies to the netbios-ns helper that is used for samba. The support for the now required handling of conntrack helpers has been introduced with firewalld version 0.4.4, but there has been an issue with SELinux as firewalld needs to be able to search for kernel modules and to analyse them.

> 
> It seems then, that when I had upgraded from Fedora 23 to 24, the
> installation had taken out (or not put in) the 137 udp Source Port reference
> in the Firewall configuration file, as well as having changed my default
> zone from the previous installation.
> 
> At present my Browsing of shared folders is working again, so lets see if it
> stays like that when I upgrade to Fedora 25.

Please try again with the latest firewalld and selinux* packages installed without the source port added.

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

I'm still seeing this on F25. Can we follow Arch's lead here and add:

iptables -t raw -A OUTPUT -p udp -m udp --dport 137 -j CT --helper netbios-ns

to the "samba-client" service?

https://wiki.archlinux.org/index.php/samba#.22Browsing.22_network_fails_with_.22Failed_to_retrieve_share_list_from_server.22

This finally fixes the issue.

Hmm, as it turns out it does add that rule, sort of, but it's in a different chain (I mean the fact that it's a subset of PREROUTING and not OUTPUT i'm unsure of)

-A PRE_internal_allow -p udp -m udp --dport 137 -j CT --helper netbios-ns

So it's still broken for me, but my problem is due to the way I use firewalld. 

The way Fedora has configured this it works _if and only if_ the connection zone is set to one that allows "samba-client" - any sources with samba-client also add the RAW rule, but it's completely ineffective. Anyone that only uses sources to match subnets to zones like I do will perceive this as broken. 

The way I typically use firewalld is to add subnets as sources to zones like internal, which is what I have done in this case, allwhile keeping the default zone less permissive, usually public. 

The problem is I guess the source subnet attached to the internal zone doesn't come into play so it appears as if it's broken, but works when you change the connection/interface default zone to be FedoraWorkstation rather than public. 

Then there's what I think I also fell into which is that the KDE spin uses public as the default zone and the XFCE spin uses FedoraWorkstation, so it was pretty confusing at first before I knew what was going on when two otherwise identical VMs except for choice of DE yielded different `smbtree` resutls. 

I think:

1. Fedora should mandate spins use a certain default firewall configuration

2. If samba-client is SUPPOSED to work on zones with sources:
    1. This is a bug and that need to be fixed somehow

3. If samba-client is NOT SUPPOSED to work on zones with sources:
    1. It should be documented somewhere that the default zone overrides the source rules
    2. Consider if 2.1(above) is maybe more appropriate

I'm probably doing something wrong, but also with firewalld disabled smbtree refuses to find the master browser...

Hi, we have 2 things new , the samba version and the kernel version I heard the new kernel change the defaults of samba (again) , i.e. please check if you updated samba or kernel ? 

Thanks

(In reply to Sergio Monteiro Basto from comment #33)
> Hi, we have 2 things new , the samba version and the kernel version I heard
> the new kernel change the defaults of samba (again) , i.e. please check if
> you updated samba or kernel ? 
> 
> Thanks

I've just upgraded to F27, so I'm now using:
kernel 4.13.12-300.fc27.x86_64
samba-client-4.7.1-0.fc27.x86_64

I'm not able to find master browser with and without firewalld:
# systemctl stop firewalld

$ smbtree -b -N -d=4
lp_load_ex: refreshing parameters
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[global]"
doing parameter workgroup = WORKGROUP
doing parameter security = user
doing parameter passdb backend = tdbsam
doing parameter printing = cups
doing parameter printcap name = cups
doing parameter load printers = yes
doing parameter cups options = raw
pm_process() returned Yes
added interface enp3s0 ip=192.168.1.10 bcast=192.168.1.255 netmask=255.255.255.0
added interface virbr0 ip=192.168.122.1 bcast=192.168.122.255 netmask=255.255.255.0
name_resolve_bcast: Attempting broadcast lookup for name __MSBROWSE__<0x1>
Unable to find master browser by broadcast

I still had to add source port UDP 137 to get Samba browsing working with Fedora 26.

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.