SMBFS workarounds

[Rashkae]

Well, yes, I see your point about smbfs mounting the file system in single
user, but I see soooo many ways to quickly get around that....

Assuming your passwords are stored in properly read protected files, why
could you not configure smbfs to mount the file system somewhere in the
users home directory with the proper username/password for the user when
he/she logs in?  I agree that this would be a pain to set up and far from
ideal,, but smbsh is really not nearly good enough, (IMNSHO) for actually
sharing a network file system.

On a side note: I think a reason that your comments attracted so much
critism is not because people think samba doesn't take corruption
seriously (I'm a big fan of Samba and samba team myself,, and I think the
level of support offered on the mailing list by samba developers is
nothing short of superb), but your clain that Samba never shiped a version
with data corruption bugs... (Maybe what you meant to say was that you
never shiped a version with *known* data corrution bugs at the time it was
shipped.)

____________________________________________
Oct 24  12:39pm


They hang the man and flog the woman
That steal the goose from off the common,
But let the greater villain loose
That steals the common from the goose.
  --English folk poem, circa 1764








On Thu, 24 Oct 2002, John H Terpstra wrote:

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