Samba 3 for Windows Vista and later

Published on
14,283 Points
8 Endorsements
Last Modified:
Community Pick
Daniel McAllister
Working in computing since 1987, and in IT since 2000, Dan McAllister is a Developer & Admin for the QMail Toaster project.
Samba is the de-facto standard program (or, more correctly: suite of programs) that UNIX and Linux systems use to share files with Microsoft Windows (and more recently, Mac OS-X) systems.

Currently, there are 2 common versions of Samba available, and they are designed for different tasks.
- Samba 3 is the long-standing "king" of solving the UNIX/Linux connection to Windows file sharing puzzle. Over the years, they have continued to keep up with a Microsoft development team that, until recently, was not only opposed to interacting with UNIX/Linux systems, but actually made implementation decisions designed to break the existing systems ability to connect. Fortunately, this is no longer the case, as Microsoft now shares their proprietary CIFS APIs with the Samba team, as well as many other companies and teams. The result has been a more robust and resilliant interface with even better performance - for all concerned!
 - Samba 4 was more than a decade in the making, with the sole intent of being able to replicate the Active Directory capabilities of Windows Server versions 2000 and later.  While it also can do basic file sharing, the primary purpose of Samba 4 is the Active Directory Server component.

For most Linux distrubutions, both Samba 3 and Samba 4 are available... but in my opinion, Samba 4 should be reserved for when you want the Active Directory Server component to work. Specifically, if all you want to do is share files, Samba 3 will be easier to get working and just as fast as Samba 4.

So, this article is primarily focused on making Samba 3 more efficient and more compatible with new Windows OSes - including Vista, 7, 8, and 8.1. The recommendations from this article actually do apply to Samba 4, but no configuration changes to Samba 4 would be needed, as these settings are already the defaults in the new suite.

For those who are impatient, I’ll skip to the end first, and then I will tell you how I got there:

For best performance with newer Windows systems:
  - Upgrade Samba to version 3.6 or higher – even if you have to do it manually
  - Enable port 445 in both TCP and UDP
  - Disable the traditional ports 137-139 (in both TCP and UDP)

OK... right about now, many experienced Samba administrators are saying," WAIT!  You HAVE to enable ports 137-139!  Those are the Microsoft File Sharing Ports!"

Well… yes and no.  The quick and dirty answers are:
Samba 3.5 introduced support for SMB2 – the preferred version of SMB for Windows Server 2008, Windows Vista, and later (including Server 2008 & 2012, and desktop versions 7, 8, and 8.1).
Port 445 is the preferred port (TCP for overhead, UDP for data transfer) for the SMB protocols.
Ports 137-139 are NetBIOS ports and were used in Windows 3x and Windows 9x. Unless you still have pre-Windows 2000 client systems out there (those would be Windows NT, 3x, 9x and Me), you can safely stop listening on those ports.
You want details and explanations?

Early (1980’s) Windows file sharing used NetBIOS, which was natively developed on an old IBM networking protocol called PCNet (also written PC-Net or PC-NET). NetBIOS is non-routable and remarkably (even for those days) insecure.

After a while (a short while, at that!), other types of network protocols became far more popular – like Token Ring, IPX/SPX, TCP/IP, and even something called MS-Net  – but Microsoft didn’t really want any part of the “network wars”, so they made NetBIOS able to be “encapsulated” into virtually any of the competing protocols. They called the encapsulated version NetBEUI (NetBIOS Extended User Interface). (NOTE: There is some historical confusion between NetBEUI and something called NBT , or NetBT – it’s not worth more than this mention – Microsoft mostly calls it NetBEUI!)

NetBIOS itself has no knowledge of “ports”, so the NetBEUI implementation on TCP/IP used ports 137-139: three ports, because NetBIOS offers 3 distinct services:

1)  Port 137 UDP provides the NetBIOS NAME service
2)  Port 138 UDP provides the NetBIOS DATAGRAM service
3)  Port 139 TCP provides the NetBIOS SESSION service (aka: authentication)
NOTE: Many Samba admins, not knowing ALL of the details of NetBIOS, open both UDP and TCP on all 3 ports. This works, but there have been examples of Trojans and viruses that exploit this opening. Look closely above: ports 137 & 138 UDP, and 139 TCP are the only ones that should be open.
  With the delivery of Windows 2000, Microsoft correctly read the writing on the wall and realized that TCP/IP had won the Network Wars (in no small part due to the onset of the Internet).  Realizing that NetBIOS over TCP/IP was inefficient, Microsoft switched to using port 445 (both TCP and UDP).  As with the earlier implementation using ports 137-139, TCP is used for administration and UDP for data transfer. Whereas ports 137-139 were referred to as NetBIOS over TCP/IP (or NetBT), port 445 is referred to as SMB over TCP/IP.  For more specifics on that evolution, look here:


To remain backwards-compatible, Windows Clients (like Windows 2000, 2003, and XP) send connection requests on BOTH ports 139 and 445. If a reply on port 445 arrives BEFORE a connection is established on port 139, the client politely closes the port 139 connection and continues with the port 445 connection. However, if the port 139 connection is complete, replies from port 445 are just ignored.  (This is basic computer theory: “If it ain’t broke, don’t fix it” and “Once you find what you’re looking for, stop looking.”)

So why turn these old ports off? Simple… to make the Windows Clients perform faster.  IF (and when) a successful connection is made on port 139, you’re using NetBIOS (not SMB) – and thus have all of the requisite overhead of the protocol encapsulation. SMB is strongly preferred for speed and reliability.

But the story doesn’t end there. The Internet has become far more ubiquitous than Microsoft (or most anyone else) expected, and some people have tried to establish SMB connections over the Internet. (NOTE: DO NOT – UNDER ANY CIRCUMSTANCES – try to open port 445 to the Internet!  It is far, Far, FAR from having sufficient security!  In fact, many ISPs will block port 445 anyway, so it may not work even if you open the ports on your firewall. If you want to use SMB over the Internet, tunnel it through a VPN!). But the SMB protocols were designed for LANs (albeit 10-base-T LANS), and it doesn’t react well to the increased latency inherent in Internet connections.

The result is that Microsoft has developed SMB2. There are many upgrades, but the driving force for the development of SMB2 was making it usable, though not necessarily secure, over the Internet. For a full description of SMB (and SMB2) please see:


SMB2 is used in Microsoft Windows Server 2008, Vista, and now Windows 7 (as well as later server and desktop versions of Windows).  In fact, each of these products comes out-of-the-box WITHOUT backwards compatibility to NetBIOS over TCP/IP! (You have to make a registry change to force them to use ports 137-139!)

Some final notes on Samba

Samba developers have successfully implemented SMB2 into both the Samba 3 product (beginning with Samba 3.5.0) and the Samba 4 product. Recall that Samba 4 is primarily a re-write of Samba to enable it to act as an Active Directory Server, whereas Samba 3 can be a PDC, BDC and Active Directory Member – but not an AD Server.

So, in conclusion:  To get the most out of your Samba 3 installation and your Windows Vista and 7 clients:
Upgrade to Samba 3.6 (to get SMB2 support)
Open port 445 (to get SMB - and SMB2 - over TCP/IP support)
Shut off ports 137-139 (to avoid NetBIOS overhead)
LVL 18

Expert Comment

by:Ravi Agrawal
good insight

Expert Comment

Thanks for the input, and the history lesson!

Featured Post

Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

Join & Write a Comment

Michael from AdRem Software outlines event notifications and Automatic Corrective Actions in network monitoring. Automatic Corrective Actions are scripts, which can automatically run upon discovery of a certain undesirable condition in your network.…
In this video, Percona Solutions Engineer Barrett Chambers discusses some of the basic syntax differences between MySQL and MongoDB. To learn more check out our webinar on MongoDB administration for MySQL DBA: https://www.percona.com/resources/we…
Other articles by this author

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month