jn at it.swin.edu.au
Thu Oct 24 23:38:00 GMT 2002
> 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
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
> 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
> 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
> 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
>>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.
> John T.
>>On Wed, 23 Oct 2002, John H Terpstra wrote:
>>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),
>>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.
>>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.
Information Technology Innovation Group
Swinburne University. Melbourne, Australia
More information about the samba-technical