[Samba] Re: How Samba let us down

John H Terpstra jht at samba.org
Thu Oct 24 16:16:02 GMT 2002


On Thu, 24 Oct 2002, Rashkae wrote:

> John, Please ignore this question from someone who probaby doesn't know
> enough to make sound statements, and who hasn't really followed the list
> closely lately....

I choose to help, not ignore.

>
> Has there ever been an explanation found for the brief rash of people who
> had tidbits of Samba log file data inserted in their network shared files
> when sharing over a Samba server??  If indeed that problem was ever
> confirmed, I can't see how any of the problems you mention can be the
> cause.

Not one confirmed reproducible case to my knowledge. What we need is a
reproducible test case, otherwise how can we locate the source of the
problem?

>
> Also, since smbfs is such undesirable technology,, what do you suggest we
> use to mount file systems between unix hosts?? nfs is great, I suppose, if
> everyone is logged into the same server or using something like LDAP to
> make sure all login machines have synchroized login accounts,, but
> somehow, the simple flexabilility of samba and smbfs always impresses me.x

There is a facility called smbsh (it is part of samba but you need to
build it separately). It creates a user space file system under /smb. If
uses the LD_PRELOAD facility. Unfortunately, recent glibc changes have
broken the ability to use this. To use this /smb facility (which works
great on Sun Solaris) you run smbsh, enter your user name and password, cd
/smb, then ls will list the workgroups (domains) in your network
neighborhood, cd to a machine name, ls will list the shared resources, cd
into a shared resource and ls will list the files. You can operate on
these files like they are local.

The key benefit of this is that the smbsh session is authenticated as the
remote user, thus the remote user gains access only to resources
(files/directories) that he/she is entitled to access.

With smbfs though the remote resource is mounted as a single UID/GID at
the LInux end, and ALL communication with the remote server is as a single
user (ie: one SID). I personally dislike this from a security and control
perspective because I approach all Unix/Linux interoperability from the NT
Administrator's perspective. After all, why have individual user accounts
if everyone is going to access the remote files as just one user.

Hope that helps to explain my position.

Cheers,
John T.

>
>
>
> On Wed, 23 Oct 2002, John H Terpstra wrote:
>
> Jay,
>
> For the record, I thouroughly test samba pre-releases before we ever ship.
> To the best of my knowledge, NOT ONE version of samba we have released
> ever CAUSED (or resulted in) file/data corruption. If I sound defensive -
> that's is exactly correct because file corruption is a DEATH issue!
>
> Please note: This does NOT include smbfs, which is not officially part of
> Samba. I can make NO assertions regarding the integrity of smbfs as I
> regard this as most undesirable technology. I do NOT test smbfs at all.
>
> Every reported case of file corruption I have looked at has been due to:
>
> 	1. Bad or defective or low grade ethernet cards
> 	2. Defective HUBs / Ether-Switches
> 	3. Defective Hardware on the Server
> 	4. Incorrect Protocol Stack configuration on the MS Windows client
>
> FHIW:	My current testbed consists of:
>
> 	Tyan 2460 motherboard, 2 X MP1600+ CPUs
> 	1 GB DDR2100 RAM
> 	1 Gigabit Intel Enternet
> 	2 x Intel EEpro100
> 	1 x 3Ware 7540 IDE RAID
> 		- 3 WD 60  GB IDE HdD
> 	2 x IBM 40GB IDE driver (native to system)
> 	Caldera OpenLinux 3.1.1 with 2.4.18 kernel with ACL patch applied.
>
> Test load on system with up to 60 sessions doing full load work. Peak IDE
> I/O bandwidth is 452 MBytes/sec. Peak network I/O is 117 MBytes/sec. Samba
> peak I/O depends on nature of operations. In other words, I beat the
> living daisies out of samba during test.
>
> Tests done with Samba with Win9X, WinME, Win2K (Pro + Adv Server),
> WinXPPro.
>
> I can vouch for the fact that not one file corruption problem has been
> detected during the 2.2.x series, nor on any prior series.
>
> Cheers,
> John T.
>
>
> On Wed, 23 Oct 2002, Jay Ts wrote:
>
> > Jeremy Allison (jra at dp.samba.org) wrote:
> > > Jay Ts wrote:
> > > >
> > > > > The corruption might be related to oplocks.  I'm doing
> >
> > Just to keep myself out of more trouble today, I'd like
> > to point out that I didn't write the above. ;-)
> >
> > > File corruption is treated as a drop everything - priority
> > > 1 bug in Samba. If this were a generic problem known with
> > > 2.2.6 we'd be issuing a patch *immediately*.
> >
> > I'm really lost at this point (too many replies to too many
> > threads while having "one of those days"), but I think I/we
> > suggested he _upgrade_ to 2.2.6, if he isn't already running
> > a pretty recent release.
> >
> > I've seen problems in the early 2.2.x releases (when transferring
> > large files) that could be perceived as (or called) "file corruption",
> > but the problem went away sometime before 2.2.4.
> >
> > Jay Ts
> >
>
>

-- 
John H Terpstra
Email: jht at samba.org




More information about the samba-technical mailing list