[KLUG Members] Re:Samba reprocess config file question

[members@kalamazoolinux.org]

>>>I have not been able to prevent a Win98 0E exception error that occurs
>>>when certain Win98 clients accesses some specific Samba shares on my cenral
>>>file server. The error is reproducible and leads to a Win98 lockup some time
>>>after the blue screen, generally resulting in loss of data.
>>I've never seen that one,  but I've seen some strange things.  I'd
>>suspect oplocks,  which are a bit wobbly in old versions of Samba.  Can't 
>>hurt to try and turn them off.
>Until I can figure out how to migrate my users to the new Monarch server
>running on RedHat 7.2, my Samba server is Samba 1.9.18p5 ala May 1998
>running on Red Hat 5.1 Kernel 2.0.36.

Yikes!!!  Samba 1.9.x doesn't "support" anything much newer than NT4.0sp3.  
Running an old Samba with new/updated clients is as perilous as meddling in the 
affairs of wizards.  M$ is constantly "tweaking" and extending the CIFS 
protocol and their RPC suite,  newer Samba's are aware of the tweaks and adjust 
accordingly.

>I will try turning off the oplocks to see if that helps, but I have made
>some interesting observations on the problem.
>The diabolical Samba share has logical links for company wide, read only
>access to various files. These files have world read only permissions. To
>be on the safe side, the Samba share is read only as well.

I've seen M$ clients lock read-only files (even executables!).  Use smbstatus 
to see if any funny locking is going on.

>The files being accessed via the share are Lotus 123 V5 .WK4 files. If I
>open them from another computer using Lotus 123 V5, I get a repeatable blue
>screen 0E exception in VxD Vredir called from VxD IFSMGR. The error message

Do you have any "process no longer exists" messages in your log file?  We have 
Lotus users, and Lotus exhibits the most bizarre file management techniques.  
We've actually unconvered and reported Samba bugs based upon Lotus 123 
Millenium.  (It ain't much better sharing from a true M$ file server).  
Expidite your upgrade.

>says it may be possible to continue normally if you press any key. When you
>press a key, often you can load the file and continue on.

Sounds like an "I'm opening this read-only file read-write" problem.

>However, Win98 becomes unstable and locks up sometimes hours later when you
>are putting the final touches on your presentation you have to make in 15
>minutes.

Of course,  even Star Office does this.  It is the pre-ordained punishment for 
anyone adjusting their presentation within 7 hours of presenting it.

>Today, I tried using Lotus Millenium edition (V9) to access the same files
>in the same diabolical share. The error message changed. Millenium does not
>generate a blue screen, rather a message box pops up saying the file you
>are attempting to open cannot be found on the network. When you click on OK,
>the file magically appears in Lotus anyway!!!

Set level 10 logging for one machine and record the session.

In "main" smb.conf -
[global]
. . .
include = /etc/samba/smb.conf.%m
. . .
debug level = 3
. . .
log file = /var/log/samba/log.%m

In "smb.conf.{testmachine}" -
[global]
debug level = 10

This way you can increase the log level to 10 (required for debugging) on just 
ONE machine.  If you raise it to 10 across the board your log files will 
***EXPLODE***HUGE*** and performance drop down to somewhere around glacial.  
The above "log file =" makes Samba keep a seperate log file for each client,  
which is darn handy in a pinch.  (adjust paths to taste, of course).

>The windows clients who own the shared files are routinely and massively
>massaging those files all day long with no errors. I don't understand why
>sharing them in a common directory via a logical link in another samba
>share should cause a networking error.

Possibly the file is changing "beneath" the read-only client?  This will be 
*BAD*.  IMHO, you need to look at a somewhat more sophisticated technique 
for "publishing" the files.  Dealing with file-locking issues is tricky,  and 
due to partial writes performed by the read-write clients I don't think you can 
arbitrarily just copy the files.  You need to test for locks,  and copy 
unlocked files periodically.

Not to be a pin head, but it sort of sounds like your trying to use a 
spreadsheet to do the job of a database.

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/