[Samba] Looking for a set of definitive answers (long)
John H Terpstra
jht at samba.org
Wed May 21 20:31:48 GMT 2008
OK - I'll respond too. I see Jeremy has beaten me to it.
Let me tell you up front, if you want the documentation to be improved the
best thing you can do is contribute changes and updates. Making us aware of
docuentation problems is a good start, but please take this a step further -
send us your updates and changes.
One other thing, before I get too far into answer or commenting is this: The
Official Samba3 HOWTO and Reference Guide (TOSHARG) is a document (book) that
sets out how specific parts of Samba function. It was never intended to
provide a working template or a scripted recipe.
I did write the Samba3-ByExample book with the specific objective to provide
detailed step-by-step, fully worked, examples of real working networks, did
you consult that document at any time? Are you offering to improve its value
and utility by contributing your experiences and recommendations?
Users and admins like yourself are in the best position to improve the
Please see comments below.
On Wednesday 21 May 2008 01:47:52 pm Avery Payne wrote:
> We recently moved to a Samba-based file server, which holds mission-
> critical data on it (.dbf files used by our Accounting software, etc.)
> The goal was to create a file server that had excellent performance while
> providing Volume Management, but we felt that something like Veritas was
> overkill for our needs.
A noble goal that can be achieved.
> Design Goals:
> - Redundant Hardware
> - Manual Failover (this was an acceptable solution)
> - Very large storage capacity (minimum 1 Terabyte)
> - Better than 100Mbyte/sec throughput
> - Volume Management, Journaled Filesystem
> - Drop-In Replacement for aging Win2k file server
> - Use existing admin tools to avoid retraining
The last two goals are a little ambitious. A drop-in replacement is a tall
order that I believe can not be met today. There are some existing tools,
but none are a complete replacement for the nicely integrated Microsoft
> The proposed solution was a Samba file server running on a pair of
> redundant servers, with one connected to an eSATA raid box, with LVM and
> Ext3 providing volume management and journaling.
I would not architect the solution this way. There are way too many pitfals
with this solution. You have identified one already - the SID <=> UID/GID
I would have used a RAID5 array in each server with rsync to synchronize from
the master to the slave. This could be run from cron. Anyhow, this is a
digression from your problems.
> Our transition was a
> bit rough, but in the end it has been very stable and fast. We have been
> really pleased with the performance of the hardware/software combo,
> seeing sustained throughput of about 250Mbyte/sec with peaks as high as
> 300Mbyte/sec. But along the way, we encountered some oddities, and I
> have some remaining questions.
What lab work did you do in a test environment before rolling this life?
Proper pre-rollout evaluation can save a lot of head-banging later.
> First, the oddities (long-time Samba devs and admins, take this with a
> grain of salt, when I say oddity I mean it from the perspective of an
> experienced Windows administrator):
Grain of salt taken. Your initiative to write this email is most appreciated.
It is a first step in the process of improvement.
> - File permissions do not behave as expected (from the viewpoint of other
> staff working with the server).
> The *nix permission bits cause a user, group, and "Everyone" entry to
> become permanent and persistent. There was some initial grousing over
> this fact as our long-time Windows admin scratched his head over why he
> couldn't remove these entries as he saw fit.
Samba is an engine that sits on top of a host OS. That host OS is NOT Windows.
Samba has to go along with the rules imposed by the host OS. The TOSHARG
chapter on "File, Directory, and Share Access Controls" should be the red
flag that underlying file system semantics are exerted by Samba. Windows
admins need to be trained to understand that Samba is not Windows NT/2Kx,
Jeremy's notes about the VFS modular work aimed at providing better Windows
ACLs emulation may provide the solution you are looking for.
> After explaining that there
> would always be three settings no matter what, that they could never be
> deleted, and that they represented actual filesystem-level bits that
> wouldn't go away, it was accepted. I didn't notice if this was in the
> docs or not, but I certainly didn't find it.
It would help me to understand your problem if you can point out how you went
about searching for answers. What questions did you frame mentally in your
search? Where and how did you look?
Did you use a hard-copy of the book? Search online in the HTML web pages? Or
did you download the PDF of the book and use the hotlinked pages in the
subject and topic indexes?
> It also meant enabling ACLs
> on all of the filesystems and doing some creative thinking with the
> permissions. The closest I could do was to map all files as owner root,
> group set to Domain Admins, and Everyone set to disallowed; members of
> the IT staff would be mapped with the "admin users" parameter; from
> there, any additional permissions would be mapped via ACLs. We've found
> that this method has the closest behavior to a "real" Windows server and
> has satisfied everyone.
Please write this up in a step-by-step form that can be added to one of the
> - Permissions don't propigate through the filesystem.
> On a Real Windows Box(tm) you would be able to set permissions at the
> parent level of a directory and have them show up for each child object.
> Because the filesystem semantics are not the same in *nix-land, you need
> to go into the directly and manually propigate the permissions, or if
> you're stuck trying to administer permissions through a windows session
> (like the other IT staffers in my department), using the Advanced setting
> to force-reset all permissions on all child objects.
You can also add to the smb.conf share definition stanza the following
parameters that are documented in the smb.conf man page:
Did you consider these? If so, what problems did they cause you?
> This has also
> caused a bit of grousing as we have several nested directories with a
> heiarchy of permissions; getting one parent directory wrong means
> rebuilding permissions for several child directories as well. I have
> never been able to get a satisfactory answer as to how to resolve this
> issue, other than the process I described above (which I had to resolve
> for myself without documentation).
OK - I understand the problem. What did you do to bring about better
documentation? Did you consider contributing some guidance documentation and
then circulation to get positive feedback from other Samba users?
Better documentation is always welcome. Contributions are continually sought.
> - To oplock or not to oplock: that is the question
> The documentation is not entirely clear about when you should and
> shouldn't use oplocks on shared files. It would have been much simplier
> (IMHO) to simply say "use your best judgement, BUT if you are using
> shared data files like Access or Excel or DBF's, you will want to disable
> them or you'll have problems!". Yes those words show up on newsgroups,
> but it should also show up in the documentation clearly.
I have not seen a single installation where DBF files and MDB file sharing
works acceptably with more than 3-5 concurrent users. It makes not
difference if the files are served off Windows Server 2003 or off a Samba
server. Oplocks slow things down and have side-effects. What-ever problems
you have with Windows servers will follow you to the Samba server also.
Best advice is do not use file sharing for multiple concurrent access database
files. Instead, use a SQL backend database.
> - Office file locking workaround(s) were not immediately obvious
> Buried in the nice (but large) Official Samba Reference and HOWTO is a
> fix for sharing Word and Excel files through Samba, which involves using
> the sticky bit for group permissions. While the fix was adequate and
> works well, it should have been I think a little more prominently
> displayed in the documentation.
Where in the book would you prefer to see this documented? What changes would
you make to the documentation to make this more prominent and more readily
capble of being found?
> - What? You want me to unlock that file?
> We have had recurring instances where a workstation on the network has
> seized a DBF file and held onto it, not allowing any other workstation or
> server to perform writes to the file. This locking issue shows up in
> random intervals and always requires that we have the person quit the
> program we are using and log back in. It is not an application issue
> that we can determine - the rest of the system continues to funciton, it
> just prevents one of our servers (or anyone else) from locking the file.
This is a client-side caching issue. Samba does not know that the file has
been released until the client notifies Samba that it has released the file.
Windows clients can go down without ever releasing the file. There are
Microsoft KB articles on how to disable client-side caching. Should this be
more vigorously documented in the HOWTO? If so, where should it be documented
> - Speaking of which - just WHO does have that file lock?
> For some reason, using the computer management tool in a windows
> workstation shows stale information. In our past arrangement, we were
> able to determine who would have the locked file by simply connecting the
> tool to the server, and sorting on the number of locks present; the tool
> would show the data file with a lock count greater than zero. Apparently
> this doesn't fly when connecting to the Samba server - it shows files
> open, but the lock count is for ALL locks (including reads) and not just
> write locks.
What tool are you using to explore this?
> - You sure you still have that file open? It says you don't even have it!
> The computer management tool also has an issue with data appearing to be
> stale. Workstations that have been powered down still show a file open.
See comment to previous question about this.
> Or in some cases, the workstation is working with the file, but no file
> handle appears in the tool! This was (and still is) a major issue for
> our staff, and as a result of this they have learned not to trust this
> once-reliable tool, because from their point of view, it lies to them. I
> have had to come up with some work-arounds and while they do work they
> are suboptimal in their eyes.
This sounds like a bug. How can we reproduce this?
> Now, the remaining question(s):
> - The vendor initially set up our authentication via tdb files and
> Winbind. We have been using this combination succesfully for some time,
> but in the Official Samba Guide it talks about regular maintenance of the
> tdb files via tdbbackup.
Unless I am sadly mistaken, the TOSHARG docs are correct. You really should
use tdbbackup on a regular basis in every large installation.
> The department head has asked that I find the
> definitive answer on how to do this, as we cannot afford more than a few
> minutes of scheduled downtime. The vendor's response was that tdb files
> should not be used because they can be corrupted when applying tdbbackup
> to them (despite the fact that it was the vendor that set us up to use
> them to begin with - go figure).
The vendor is mistaken. Please ask the vendor to speak with one of the Samba
> This has caused even more concern -
> millions of dollars in business and 50+ users are supported by this
> server, running 24/7/365. So, if we were to loose our file server
> tomorrow, and had to activate the backup server (which we would do by
> plugging in the eSATA array into the new units and starting up the
> system), how could we guarantee that the GUIDs, etc. would be consistent
> and we wouldn't have a complete mess on our hands? I have seen someone
> else recently mention that they should be using an LDAP authentication
> backend. So who's correct, the vendor's original setup which uses tdb
> files, or the 2nd vendor response which says don't use them, or should we
> be on LDAP authentication connected to our Win2k3 domain controllers?
LDAP is the way to go for IDMAP sharing across domain member servers. The tdb
files really should not be replicated across servers.
> - Is there a way to get the Computer Mangement tool to not "lie" to us
> about the state of file handles and locks? It would be a godsend to not
> have to watch everyone roll their eyes because the "expected" way of
> locating file issues simply doesn't work for them. This is an ongoing
> issue and I can't really provide a satisfactory answer - even SWAT
> appears to have this issue as well!
SWAT is not being actively maintained.
> I have resorted to shell scripting
> to provide us with the answers we need but this is hardly a long-term
> solution. Is there some magic setting I need to flip in the registry for
> our Windows XP clients to make this issue just go away? Is it related to
> protocol changes in the newer versions of the Windows redirectors? Just
> why does this happen?
So far as I am aware Samba fully matches the behavior of Windows server 2003.
Samba can not fix client-sied issues. You need to set your client registry
correctly to stop client-side caching for MDB and DBF files. I do believe
that is documented somewhere in TOSHARG.
> A parting thought as well:
> It would have been nice to have had a reasonably generic template or
> example somewhere that pointed this out, instead of wasting an incredible
> amount of time (a month!) reading many many many pages of documentation,
> sometimes scattered into different chapters, as well as contacting the
> vendor twice with over a half-dozen messages. I would think that a
> simple, single smb.conf file named "smb.conf.dom-member.filesserver" with
> a generic looking setup would have resolved many of these issues, by
Where would you search for this information? Which chapter? Which book? How
should it be documented? Are you willing to write this up in a usable form?
> having the appropriate settings and comments already in the file while
> pointing out what parts of the template needed to be changed. Everyone
> that I have talked to outside of my work looks at Samba as a drop-in
> replacement for existing Win2k(3) file servers,
Everyone can be mistaken, fortunately not everone is always mistaken.
> and a template with
> settings that come closest to emulating that same behavior would go a
> long ways towards adoption. I'm not trying to be overly critical, but
> rather, I'm trying to point out a missing part of the software package
> that I think administrators would like to have, especially as more and
> more companies start to operate in mixed environments.
I want to commend you on your email. You comments are due criticism. Your
assistance to close out your concerns is most appreciated.
More information about the samba