Many of the tweaks used to fine-tune a Samba server are identical to the fine-tuning of any server, particularly a Web server. So if you have tuned an Apache server for better performance you can apply much of the tuning – that you so carefully documented at the time – to wring extra speed from Samba servers.
The biggest difference between an HTTP server and a Samba server is that Samba may well be handling writes-to-file as well as reads-from-file. And note that a Samba server that is hosting a legacy database such as Access, Paradox, FoxPro or QuickBooks, may be seeing many more writes than reads. Keep the distinction between file writes and file reads in mind as you consider the tips below.
Before tussling with the server itself, learn to interpret the output of the tools you will you use to assess the impact of your tuning tweaks. Check for vmstat, which is usually installed by default on most mainstream Linux distributions. When you run the command “vmstat”, the key column headings to check are:
“r”, which shows processes waiting. Should be as low as possible and not above 10
“in”, which shows interrupts/second and signifies network card and disk overload if the number is too high
“cs”, which, put simply, shows how often the kernel is changing the program it is working. This number should be low
Both “in” and “cs” are hard to make recommendations on because the actual numbers vary with the system hardware and software configuration. If possible, work around this by comparing their running values against a lightly loaded server with the same hardware and software.
Netstat and ps – with liberal use of ps’s built-in arguments – are also essential.
Easiest to squeeze extra performance from are Samba file servers that supply read-only documents or which serve them up for reading and writing in environments where it is not important to know the last-modified time. When turned on – as it usually is by default – the file system’s “atime” option forces the operating system to perform the slow action of writing the “last-accessed time” to disk each time a file is read.
Turn off atime at partition mount time by inserting the “noatime” switch in the options column of /etc/fstab. The line should look something like this:

/dev/sda5 /samba ext3 noatime 1 2
On a Red Hat system, it will look more like this:
LABEL=/samba /samba ext3 noatime 1 2
Another tweak suitable for read-only Samba servers is to turn the network interface card’s full duplex feature off. This only helps if traffic is heavily biased in one direction – as it typically is with read-only file servers. Typically that means adding an “option” statement for the NIC alias in /etc/modules.conf along the lines of:
options tulip full_duplex = 0
Many well-known network bottlenecks also impact Samba server performance, including NIC duplex interoperability with various hubs and switches, TCP window size mismatches with routers and poor DNS.
Ensure you choose or specify a network card that is well supported on Linux -- in other words, a NIC for which there are mature, heavily used drivers. Check the driver’s documentation to see how full duplex is turned on or off and for other potential optimisation tweaks.
Disk-bound beasts that they are, Samba servers provide most optimisation potential in the I/O and memory subsystems. So make friends with the server’s virtual memory buffer disk controls. On popular Linux distributions, these are often set (by bdflush) to deliver better performance for desktop activity than for file server activity. Check the current settings by reading bdflush directly with the following command:
cat /proc/sys/vm/bdflush
which will return something like:
30 500 0 0 500 3000 60 20 0
Read the bdflush section of /usr/src/linux/Documentation/sysctl/vm.txt to establish what each setting does. In practice though, the best settings depend on how workers load the samba shares, so the only way to optimise these settings is to adjust them and benchmark the results. A good place to start is to adjust the settings with this command (all on one line):
echo 100 5000 0 0 150 30000 5000 1884 0 > /proc/sys/vm/bdflush
and test-load the file server. Remember to watch the samba server’s memory while testing because changing these settings plays off speedy file read/write requirements against memory availability.
As with NICs, you can dig into low-level disk hardware to find hidden optimisation potential. If the file server uses SCSI drives, check if the SCSI controller card supports tagged command queuing (TCQ). This is the disk hardware tuning option that is most likely to deliver a big performance return if tweaked. Adaptec’s very common aic7xxx SCSI controller cards support TCQ and can be turned on in /etc/modules.conf with an “option” statement, typically:
SCSI configuration varies a lot so read Adaptec’s documentation and the Web to find settings appropriate for the server’s disk array.

Firewall issues
Firewalling a Samba file-server is a common way to ease life as a lowly sysadmin and protect against boo-boos caused by learning to interoperate both Windows and Linux file and share permissions on one server asset. But incorrectly configured firewalls slow Samba performance.
Forensic examination of the iptables firewall rules on countless Samba file-servers shows many administrators do not know what ports and protocols are really required to maintain Samba traffic.
It’s common, for example, to find both UDP and TCP enabled on ports 137, 138 and 139. Samba actually requires UDP protocol on ports 135 (Windows’ RPC mapper, similar to Linux portmapper), 137 and 138 and only tcp on port 139.
If you have Windows 2000 and Windows XP clients, consider allowing TCP on port 445. This should speed Samba access from Windows 2000 and later clients because they try to use port 445 before dropping to 139 if port 445 fails.
Finally, try adding

read raw = no
write raw = yes
in Samba’s smb.conf file. Raw read and write are enabled by default but some clients run faster with it disabled. Only testing will determine which setting works best.
There is much, much more you can do to fine-tune a file server and the Samba web site offers Samba-specific hints at
Finally, prepare for better Samba testing in the future – the Samba team says it will improve testability in Samba 4 to cover many more features in the vast SMB/CIFS protocol on which Samba is based.

Example firewall settings for Samba servers
If you use Red Hat’s default Lokkit tool for configuring firewall rules, you can manually add the correct rules by editing /etc/sysconfig/iptables and adding (where represents your subnet address):

-A RH-Lokkit-0-50-INPUT -s -p udp --dport 135 -j ACCEPT
-A RH-Lokkit-0-50-INPUT -s -p udp --dport 137:138 -j ACCEPT

-A RH-Lokkit-0-50-INPUT -s -p tcp --dport 139 -j ACCEPT
-A RH-Lokkit-0-50-INPUT -s -p tcp --dport 445 -j ACCEPT