SMBFS workarounds

[John Newbigin]

Rashkae wrote:
> 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.
If you want to do this, have a look at my page here
http://uranus.it.swin.edu.au/~jn/linux/smbfs/index.html

Here you will find tools to mount users home directories using smbfs AND 
I have implemented the UNIX extensions so you can have unix(like) semantics.

> 
> 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
>>>
>>
>>
> 


-- 
Information Technology Innovation Group
Swinburne University. Melbourne, Australia
http://uranus.it.swin.edu.au/~jn