Samba Server Implementation Details and Best Practices

This question will be submitted as a wiki. The intent is to gather valuable configurations, deployment ideas, and smb.conf settings to assist with this wonderful service.

Having used this for over a year in a mission-critical role, I can safely say that there are ups and downs to using this software; but along the way, I also learned a thing or two that separates truth from hype. What things have you encountered, done, or otherwise thought of to make this service work its best?

Follow-up:

I've taken to posting answers to my own question, as no-one seems to have an "incentive" to provide their own answers. Even though it's a community wiki I would rather refrain from answering my own questions, if possible, so if you have something to share, please please please leave an answer!

Solution 1:

Let's get the ball rolling:

Ok, so the first thing I learned is: newer versions of Samba reload their settings on-the-fly. That's right, the moment you save that smb.conf file, Samba notices the change in the file and reloads the settings from it. This answered an age-old issue: how to reload settings into Samba without restarting the services (which then cuts file access to all users - not a good thing when users are still using file-based databases). If you've had Windows admins sit there and point out "I can add shares on the fly, how do you expect to do this?", well, now you have an answer on how to do it.

The version of Samba I was using was packaged with RHEL 5.1, and this behavior continued even after a package update.

Solution 2:

Occasional maintenance isn't necessary, but on busy systems (at least for installs older than 3.0.x) sometimes it helps to do a little maintenance. You can do this by going into the directories that store your .tdb files and using the tdbbackup command. First do

tdbbackup *.tdb

Follow this up with

tdbbackup -v *.tdb

Which regenerates your files if they encounter any corruption.

I normally wouldn't recommend this, but as I've mentioned elsewhere, some of the versions of Samba that are shipped by vendors happen to be "slightly broken", and doing this regular maintenance helps with issues you may encounter.

Solution 3:

While Samba isn't running you can safely remove the locking.tdb file at any time. Should you run into an issue with locks, stop the service, remove the file, and start it. Samba will automagically recreate the file.

And yes, the file contains state information on what files/byte ranges are locked.