Samba 3 for Windows Vista and later

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:
 
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:

            http://support.microsoft.com/kb/204279

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:

      http://wikipedia.org/wiki/Server_Message_Block

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: