[Samba] RE: [Samba]DOS app won't run off a Samba drive!

[Greg Conway]

Hi John,

Thanks for the comments, but the original problem was entirely to do with
Win2K and Win98!

I have a Linux Samba Server that provides network drives to a small LAN.

The client already had three networked DOS apps running off this Samba
Server.

I added a fourth, and a problem reared it's ugly head.... One single user
could access the net app, but when a second tried to log in, the Windows
client froze for about 30 secs, then returned "Unknown disc error on drive
X", and the app bombed out.

Thanks to this group, I've solved the problem within twelve hours of my
original posting! For which I am most grateful.

For all those that missed it, adding the line 'kernel oplocks = no' fixed
it.

But your input is also very welcomed, thanks!

Regards,

Greg.

> -----Original Message-----
> From: Nelson, John P. [mailto:john.nelson at teradyne.com]
> Sent: 29 January 2002 18:52
> To: 'greg at gmlnt.com'
> Subject: Re: [Samba]DOS app won't run off a Samba drive!
>
>
> >Hi Rashkae,
>
> You sent this to the list, so I assume you don't mind someone else poking
> their nose in.
>
> I didn't see the original question (I just can't keep up with the
> volume on
> the Samba list).  From the subject line, I think I know the
> problem.  There
> is a bug in Win9x with long directory names in a network share.
> If you try
> to run a DOS program from a directory that contains "long" directory name
> components (more than 8.3 filenames), it will not run properly.
> This is not
> specific to Samba - it behaves the same way if the files reside on an
> NT/Win2k server (with the same pathname).  The bug is in Win9X itself.
>
> I used to know what the failure mechanism was, but I forget now.
> But if you
> eliminate any "long" pathname components, it doesn't happen.  And the
> problem doesn't impact Windows NT client systems.  It also doesn't impact
> WIN32 applications.
>
> >Well, all these "oplocks" are a little new to me!
>
> Oplocks (short for opportunistics locks) are an optimization for better
> performance!
>
> Oplocks allow a client to cache a file's data locally, without
> the overhead
> of continuously syncronizing with the server.  The server can grant a read
> oplock to multiple clients which allows them to cache the file contents
> without checking for changes on the server - any network request to modify
> the file will cause the server to revoke all read oplocks, which causes
> clients to revert to normal behavior.  A write oplock can only be
> granted if
> a single client has the file open - this allows the client to
> cache changes
> to the file locally - whenever another client requests any form
> of access to
> the file, the oplock is revoked and the client with the lock must
> commit any
> changes to the network copy.
>
> >you can put a "oplocks" section in the [global] section, to
> enable oplocks
> -
> >are they enabled by default?
>
> Oplocks are enabled by default.  It turns out that they result in a
> significant improvement in throughput.
>
> The biggest problem with using oplocks is if you share files between unix
> applications and PC clients - most unixes do not understand the oplock
> protocol.  Enabling oplocks may result in unexpected caching
> behavior on the
> PC clients.
>
> Other than that, there is no reason to disable oplocks.
> Databases work fine
> with oplocks - if more than one client tries to use the database, then
> oplocks with be denied (or revoked).  The only case where oplocks are a
> problem would be a database that is shared between PC and unix client
> applications.
>
> >you can then put a "veto oplocks" section into individual shares
> ie [data],
> >to remove oplocks from that particular share.
>
> "Veto oplocks" is used to remove oplock behavior from specific filenames.
> If you want to remove oplocking behavior from a share, simply put
> "oplocks =
> NO" in the definition of the share.
>
> >Why do my Win2k
> >machines work be default but not my Win98 machines?
>
> I'm guessing that this has NOTHING to do with oplocks.  Of
> course, I haven't
> heard the whole story, so I could be wrong.
>
> sincerely,
>
>   - john nelson (john.nelson at teradyne.com)

***********************************************************************
This is a confidential communication between sender and addressee. If you are not the intended recipient of this message, please notify the sender and do not read, copy, use or disclose this communication to others. Any opinions or views expressed are those of the individual, and unless otherwise stated, are not those of the company. All attachments and intellectual rights remain the property of GML (NT) Limited.
***********************************************************************