I'm not sure what to file this against, but i'll start with system-config-securitylevel. The default firewall rule breaks smb browsing in gnome-vfs/nautilus. I'm not sure what is to blame, gnome-vfs, samba, or the firewall rules, but when you enable the firewall it breaks, and it works when you disable it.
I'm not sure it's possible to make it work through the current firewall, at least without the kernel firewall rules having very deep knowledge about the SMB protocol. Since I think we're keeping the firewall on, I think we'll unfortunately have to punt this to FC4. Dan Reed should know more about this, adding him to CC.
The firewall will definitely block the UDP port 137 and 139 incoming which are necessary for passively getting service broadcasts from other machines on the network. Active service discovery is another question. I'm not sure whether the firewall state tracking understands it.
just noting this is somewhat simliar to bug 131745
Bug 58004 is the original version of this.
We can't just punt this and have a completely non-working samba UI on the desktop. Windows interoperability was supposed to be important in the release.
notting: Thats not really the same, is it? I read that as punching hole for a samba server. This is about allowing the client to browse for samba shares.
Bug 113918 seems very related though.
As i mentioned in bug 113918 i wrote a kernel module that fixes this: http://www.redhat.com/archives/fedora-devel-list/2004-September/msg01178.html I posted it both on upstream netfilter and fedora lists, but as yet i've gotten no real responses about it. Hopefully upstream is interested and we'll be able to get it into the kernel like that. But this seems it will take some time.
Marking high priority, whatever that will do. But this still doesn't work by default and we really need to have this done.
Bryan: Its highly unlikely this will move at all. The kernel people want it upstream before taking it, and upstream doesn't seem to care. No replies to: https://lists.netfilter.org/pipermail/netfilter-devel/2004-September/016986.html
Alex - I can put something like this in by default this round and get a UI update later to allow selection: -A -p udp --dport 137:139 -j ACCEPT Can someone confirm if that is sufficient and I'll add (and get added to the release notes).
No. That is not sufficient. The only stateless rule that works is to open all high port to udp packets from port 137.
eh, that sounds confusing. We'd need to allow udp packets from port 137 to any high port on the local box. The rule you posted is for running a smb server. Not for the client.
paul, did this get commited?
Created attachment 105322 [details] ip_conntrack_netbios_ns.c
Created attachment 105323 [details] Makefile for ip_conntrack_netbios_ns.c
I added the two files for convenience. Just for clarity: ip_conntrack_netbios_ns.c is written by Alexander Larsson. You can blame the Makefile to compile the module outside the kernel on me though.
In the hope of getting some form of response i re-posted this to the netfilter list: https://lists.netfilter.org/pipermail/netfilter-devel/2004-October/017159.html
Looks like there was some feedback this time - Alex did you get any take further upstream?
I'm new to Linux. I have Fedora Core 2 installed. I wanted to use samba on my small in-house network. I wanted to access my printer connected to a Windows PC from my Linux box. (The reverse will not happen.) My email is jeff12 . After reading this page it seems to indicate samba doesn't work even on Fedora Core 3. So I guess I'll give up at this point. Does anyone know when I'll be able to even get the rpm to work, much less hoping for the graphical Add/Remove Programs to work on samba? I have no idea how anyone expects Linux to fly unless it can be cooperative on a Windows network without requiring a $150,000 Linux Nerd.
It will work if you run System Settings -> Security Level and set the firewall to disabled.
I have a hack which is at least a partial solution to this problem. (1) disable Block broadcast traffic in Firestarter Preferences -> Firewall -> Advanced options (2) Add the following line to the file /etc/firestarter/user-post $IPT -A INPUT -i $INIF -j ACCEPT You can then browse the samba share using Konqueror smb:/ Ron Hawkins Lansoftemail.au
Arghh - my apologies - I take it all back my last post refers to a fix for Firestarter, While you needed a fix for system-config-securitylevel Opening these ports to the Internet is dangerous, Just opening these ports to the internal network should work.
*** Bug 140763 has been marked as a duplicate of this bug. ***
pnasrat: I think the latest version is in: https://lists.netfilter.org/pipermail/netfilter-devel/2004-October/017261.html It seemed to work in some tests i did. I haven't done any more work on this since then. It would be nice if we could get one of our network people to look at this, such as jmorris. He could help getting this stuff upstream which seems to be necessary for inclusion.
OK. I have turned off the firewall completely. In Gnome browsing samba/windows shares doesn't work at ALL... KDE I can get the browsing to work, once Lisa is activated, but I like the visual appearance of Gnome. What must I do to get browsing shares to work in Gnome? Thanks, G
For questions on how to get things working, you should use a support channel such as a mailing list (or Red Hat support if using a purchased product). https://bugzilla.redhat.com/bugzilla/ has a note on why this is important - in short to keep bugzilla usable for developer task tracking. If in the course of figuring out your problem you discover a software bug and can characterize it in enough detail for a developer to investigate, please file a separate bugzilla report for each such bug with the details of your setup and configuration. If you aren't sure how to characterize a problem, forums such as the lists can help with that as well.
I have the iptables rutned off. I have the firewall turned off based on a previous comment above. Gnome browsing shares on either windows or linux machines (samba shares) does NOT work. KDE broswing (provide lisa is activated) works but I prefer the look of Gnome (better fonts easier on the eyes) Please advise as to how to fix this... Thank you, ~G
Greg please file a new bug for your issues - this one is specifically aimed at dealing with transparent browsing firewall rules.
Easy this one, I have used browsing samba shares in all fedora releases, its just a pain theres no tick boxes for these ports. In the security level window accessed through menu system settings, enable firewall add the following to the enable other ports bit, 137:udp, 137:tcp, 139:udp, 139:tcp, 445:udp, 445:tcp this allows me to browse my samba shares with the firewall enabled, using win98 win2k and winXP and fedora. windoze type sharing still uses netbios over tcp and uses the above ports, sometimes port 138 needs to be opened too. You should get all yor shares with this including the printers. Hope this is of help Cheers Danielle.
But isn't this dangerous? Doesn't this open a door in your computer for hackers to come through? Please explain all the risks in doing this. Thanks, O.R. (In reply to comment #34) > In the security level window accessed through menu system settings, > enable firewall add the following to the enable other ports bit, > > 137:udp, 137:tcp, 139:udp, 139:tcp, 445:udp, 445:tcp > > this allows me to browse my samba shares with the firewall enabled, > using win98 win2k and winXP and fedora.
The more open your firewall, the more possible security issues, but also the more useful your computer.
Updated s-c-securitylevel in rawhide to include an option for enabling browsing of Samba networks based on documentation provided by Jay Fenalson. It's my understanding that some work will still need to be done on the kernel for the serving side of this bug, however.
Could the release notes be chnaged to talk about enabling just those ports, just on local interfaces, to use SMB, rather than disabling the entire firewall?
clumens: Exactly what ports did you enable to get samba browsing to work? I ask, because the only stateless rule that could work is for all udp packets from port 137 to any high port to go through the firewall. And this is a very dangerous rule to add, since it essentially disables the firewall for udp. The real solution is to get the right kernel people to review the netfilter module I wrote and get it into the fc kernel.
I only enabled ports to allow browsing Samba shares on other machines, not to enable sharing your own stuff out through your firewall. My modifications were based on the following: 10:47 <hack> Page 215 of /usr/share/doc/samba-3.0.15/docs/Samba-HOWTO-collection.pdf 10:47 <hack> section 16.3.4 says 10:47 <hack> 16.3.4 Using a Firewall 10:47 <hack> Many people use a firewall to deny access to services they do not want exposed outside their 10:47 <hack> network. This can be a good idea, although I recommend using it in conjunction with the 10:47 <hack> above methods so you are protected even if your firewall is not active for some reason. 10:47 <hack> If you are setting up a firewall, you need to know what TCP and UDP ports to allow and 10:47 <hack> block. Samba uses the following: 10:47 <hack> UDP/137 - used by nmbd 10:47 <hack> UDP/138 - used by nmbd 10:47 <hack> TCP/139 - used by smbd 10:47 <hack> TCP/445 - used by smbd 10:47 <hack> The last one is important as many older firewall setups may not be aware of it, given that 10:47 <hack> this port was only added to the protocol in recent years. 10:47 <hack> These are for incoming connections.
That is a firewall rule for the samba server. But this bug is about smb browsing. Let me take an example. I'm using Nautilus to browse the smb neigbourhood, and I'm not using wins or anything like that. What happens then is that nautilus sends a broadcast udp message to port 137. To do this nautilus has to open a socket, which then gets allocated a high port, say it gets port 14525. The various smb machines on the network respond to this broadcast by sending a reply from to the broadcast. This reply is an UDP packet with source port 137 and destination port 14525. These packets will be filtered out by the firewall, even with the firewall rules you listed above. Since the high port the application gets is dynamic the only way to make a static firewall rule handle this is to allow UDP packets from port 137 to any port. This is clearly bad. The alternative is a statefull firewall that keeps track of the broadcast to port 137 and allows the replies to go throught the firewall. The iptables module I wrote does this. However, no kernel developers seem to have any interest in it.
Ok further to my post above here is an eplanation of how smb works: If the client has NetBT enabled, it will always try to connect to the server at both port 139 and 445 simultaneously. If there is a response from port 445, it sends a RST to port 139, and continues it's SMB session to port 445 only. If there is no response from port 445, it will continue it's SMB session to port 139 only, if it gets a response from there. If there is no response from either of the ports, the session will fail completely. If the client has NetBT disabled, it will always try to connect to the server at port 445 only. If the server answers on port 445, the session will be established and continue on that port. If it doesn't answer, the session will fail completely. This is the case if the server for example runs Windows NT 4.0. If the server has NetBT enabled, it listens on UDP ports 137, 138, and on TCP ports 139 , 445. If it has NetBT disabled, it listens on TCP port 445 only. Opening up these ports is a risk yes but you always have to way up the pro's and con's. Set any network firewall to block these ports from leaving the local network and the information will not get out.(In reply to comment #0) > I'm not sure what to file this against, but i'll start with > system-config-securitylevel. > > The default firewall rule breaks smb browsing in gnome-vfs/nautilus. > > I'm not sure what is to blame, gnome-vfs, samba, or the firewall > rules, but when you enable the firewall it breaks, and it works when > you disable it. (In reply to comment #34) > Easy this one, I have used browsing samba shares in all fedora > releases, its just a pain theres no tick boxes for these ports. > > In the security level window accessed through menu system settings, > enable firewall add the following to the enable other ports bit, > > 137:udp, 137:tcp, 139:udp, 139:tcp, 445:udp, 445:tcp > > this allows me to browse my samba shares with the firewall enabled, > using win98 win2k and winXP and fedora. > > windoze type sharing still uses netbios over tcp and uses the above > ports, sometimes port 138 needs to be opened too. You should get all > yor shares with this including the printers. > > Hope this is of help > > Cheers > > Danielle. > >
There are two separate issues getting confused here: 1) In order to allow clients to browse samba shares on a given samba server, you need to open certain ports in the firewall. system-config-securitylevel allows you to do this. No issue here. 2) In order for a client to be able to browse samba shares, it needs to be able to receive UDP packets on port 137 that are sent by servers in response to a broadcast query. This isn't something you should need to switch on explicitly, clients should be able to browse for Samba shares without changing any configuration. So, Alex has written a ip_conntrack module which allows UDP packets on port 137 so long as they are actually in response to a query initiated by the client. There's nothing to be done in system-config-securitylevel, I don't think. This should probably be just marked as a dup of bug #113918
Agreeing with Mark, marking as duplicate. Will add bug #113918 to FC5 target, as this is a target too. *** This bug has been marked as a duplicate of 113918 ***
(In reply to comment #44) > 2) In order for a client to be able to browse samba shares, it needs > to be able to receive UDP packets on port 137 that are sent by > servers in response to a broadcast query. > > This isn't something you should need to switch on explicitly, clients > should be able to browse for Samba shares without changing any > configuration. > > So, Alex has written a ip_conntrack module which allows UDP packets > on port 137 so long as they are actually in response to a query > initiated by the client. I was totally wrong about this bit - the replies don't come in on UDP port 137, but on a random high numbered port. Alex's ip_conntrack tracks outgoing packets on UDP port 137 and allows replies to them on high numbered ports within a timeout. So, without Alex's module, you can't get SMB browsing to work on the client just by opening UDP 137 - you need to totally disable the firewall.
I have the Firewall disabled, and sharing doesn't work under FC4. However, if I su to root and run smbd -D manually, it works great. If I restart with service smb restart, it's broken again. Also, if I just try to launch it directly (hack /etc/init.d/samba) and then exit 0 immediately.
firewall settings does not matter for me. The command server# smbclient //<server_ip>/<share_name> -U <user_name> will fail if you start up samba like this: # /etc/init.d/smb start But it will work if you start it like this # sh /etc/init.d/smb start It would be nice to know why such a huge difference.