Most IT learning curves start with an irate user's support call. In enterprise Samba deployments, that learning curve typically starts with hundreds of users' calls.
Unfortunately, much of the available Samba literature and web support focuses on small business scenarios, where users' file-access attempts rarely conflict and where loads rarely leave your file-servers staggering.
Tuning Samba for enterprise use therefore has two goals: to prevent "access denied" problems caused by file-locking conflicts and to boost access speeds to levels that maintain both data integrity and user happiness.
Locking problems are the hidden downside of Samba – a consequence of its relatively strict application of good programming and networking practices to the layers of Windows, CIFS and Unix-style permissions that wriggle in the entrails of modern file-servers.
You can easily prove this to CEOs who learned their Samba skills from Business 2.0 magazine by setting up Windows and Linux clients to read file shares delivered by an untuned Samba server. You should find that Windows clients can read and edit a Samba-hosted Rich Text Format document with ease. KWord users on Linux will also open and read it with no problem but may or may not be able to write to it. OpenOffice users on Linux should be able to open the rtfs in read-only mode alone. AbiWord will generally not open them at all - an error that may be due to rtf formatting problems but picture yourself asking users to give you descriptions that are clear enough to for you to select Samba or AbiWord as the cause.
This simple demo uses word processors. Now imagine the fun when you try to migrate that legacy Access, FoxPro or Paradox database applications to a Samba file share.
Assuming that you are using Windows desktops to run these legacy databases, let’s start to fix these problems.
Samba's performance usually benefits from a statement in its /etc/samba/smb.conf file that sets buffer sizes for the operating system. Typically it should look like:
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
It is often worth adding IPTOS_LOWDELAY to this line and checking for a performance improvement. IPTOS_LOWDELAY affects router performance rather than the server or client performance so its benefit will depend on your network infrastructure.
Samba shares hosting database files which allow simultaneous access but usually require very different buffer options. To improve their performance, try changing the socket options line to:
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=20480 SO_SNDBUF=20480
which increases the amount of buffer memory available to database applications and overrides the operating system’s buffer allocations if necessary.
Try experimenting with this setting while watching both access speeds and server load. Monitor server load with top or free to ensure that using big buffers is not forcing server performance to top out.
Opportunistic locking (oplocks) is another cause of woes for legacy databases on Samba shares. Opportunistic locking is a Windows concept that allows multiple clients to work together quickly when reading shared files. But the flushing and renegotiation it forces clients to go through when they open files with writing in mind imposes heavy drag on performance. Oplocks are turned on by default in Samba but can be turned off on per-share basis with the two statements:
oplocks = 0
level2 oplocks =0
You can also veto opportunistic locking on a per-file basis while leaving it available to other files on the same share. To veto oplocks for Access files, use this statement:
veto oplock files = /*.*db/
This turns off oplocks for Access' .ldb and .mdb files.
It's also worth turning off oplocks on shares that are accessed over any unstable connection such as Wi-Fi – even if the Samba-hosted application data is not written to by multiple users.
Typically this problem shows up as an "unable to save due to file permissions" error for users working in, say, Word, and who have temporarily lost network connectivity. Samba perceives this as a "document locked for editing" situation.
Oplocks control may fix the problem in the long term but the fix to apply the first time the problem shows up is to ask trained users to save the edited file with a different name – or even onto the client machine's local drives, depending on whether the Samba share is available or not. Resolve which file to use by opening the original file in Windows Explorer and comparing the two before deciding which one to delete. Usually users will want to keep the file that they saved to their local drive because it contains the latest version of their work.
If in this situation, users report seeing the "file locked for editing" dialog box, they should also see a "notify when available?" checkbox. Have them check that option. The file usually becomes available a few minutes later, once Windows and Samba have allowed their default timeouts to work through. Then ask users save their edited version of the file over the original version they were trying to edit in the first place.
You can also make a Windows + Samba working environment more robust by turning on Windows clients' "Make Available Offline" option in mapped network drives. Do this by using Windows Explorer's right-click context menu. Or highlight the mapped drive, click the "Folder Options" menu item and select the "Offline Files" tab. Apply the following rules:

Check Enable Offline Files
Set files and folders to synchronise when logging on and logging off.
Optional is “encrypt all files”. This is not recommended because if all else fails, you can usually recover unencrypted documents using a range of other tools.
Do not check the “Never allow my computer to go offline” in the Advanced section. Using offline folders, however, will require managing user expectations on how to handle the small delays while the synchronization engine works out which files in which folders have changed.
In lab and field tests the combination of offline caching and Samba file shares makes a huge difference to user productivity and raises return on capital, by enabling users to work transparently on cheap, effective file shares that work both in the office and out.
This is particularly useful for mobile sales staff using wireless networked laptops, and who may have unstable network connections when they're in the office. Microsoft's built-in file and folder synchronisation routines do a pretty good job of working out which files to synchronise in which direction – and that it works so sell on Samba fileshares shows just how thoroughly the Samba development team have replicated the Windows file-server environment.

Links:
Fine-tuning your email server Proxy servers made easy