Filepro and Samba

Thu Nov 9 06:54:32 PST 2006

> Date: Wed, 8 Nov 2006 18:31:32 -0500
> From: "Brian K. White" <brian at aljex.com>
> Subject: Re: Filepro and Samba
> To: <filepro-list at lists.celestial.com>
> Message-ID: <024901c7038e$061e8010$6400000a at venti>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> 	reply-type=original
>
>
> ----- Original Message ----- 
> From: "Jay R. Ashworth" <jra at baylink.com>
> To: <filepro-list at lists.celestial.com>
> Sent: Wednesday, November 08, 2006 5:48 PM
> Subject: Re: Filepro and Samba
>
>
>   
>> On Wed, Nov 08, 2006 at 05:41:15PM -0500, Fairlight wrote:
>>     
>>> No offense, nothing at all personal, and I say this with the sole intent 
>>> of
>>> trying to prevent you from digging a hole for yourself as I've seen 
>>> others
>>> do over the years.
>>>       
>> But if you *do* dig yourself a hole, my number's in the sig; I'm sure
>> Mark will quote you a rate on request, too.  :-)
>>
>> That said, there is one point I don't think Mark made: "is Linux a
>> better choice than Windows as a server OS for the things it can do?"
>>
>> Whoa, yeah.  Hands down.
>>     
>
> Aren't there file lock behaiour options you need to change from the stock 
> defaults in samba for windows filepro to work ok?
>
> I have a couple older customers who swapped out ther win boxes without ever 
> telling us until after it all puked.
>
> When I got in and peiced together what really happened, that was the main 
> thing that fixed it was I twiddled some smb.conf options for the filepro 
> share that changed lock behaviour and maybe default dir mask and filemask 
> to.
> There are several lock related options and their actions and combined 
> interactions were somewhat subtle as I recall.
> This was a couple years ago and it was before samba 3 for one thing, so 
> perhaps the defaults are different now and don't need tweaking out of the 
> box. Could also have been distro supplied defaults related not stock samba 
> defaults related. Don't recal the dist.
>
> I say yes it is a perfectly well working system and no reason not to go 
> ahead and swap out netware for linux in his case. It works great and is 
> reliable and easy to maintain, repair, migrate, backup, restore, etc... once 
> it's working.
>
> But only if he takes Marks advise. Have not only a good linux guy set it all 
> up, but preferrably one whos familiar with filepro and specifically 
> Windows-filepro, and specifically ready to spot and resolve issues like what 
> I described above about unexpected problems with file locks on the samba 
> share that may only affect filepro even though the share seems to work fine 
> for sharing excel docs etc...
>
> And even though I went through exactly all that and resolved it and that 
> site hasn't called me back in years and the results of what I did are still 
> chugging away and are now proven by that, I do not suggest to call me for 
> this. That was one site. I use linux a lot now but it's all for unix/linux 
> stuff and have just about 0 use for samba and don't have it running on any 
> of my own boxes so far. It is running at a couple clients but they are using 
> it for general file sharing and printer sharing, their filepro is native 
> linux filepro, so no windows-filepro sharing specialness.
>
> Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
> filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!
>   
First, let me say that I appreciate the warnings from everyone, but I am
on a tight budget and I have confidence in myself that I can set things
up.  I also feel that I have room for some screw-ups since our computer
system is in support of our operations and not key to them.  While I
wouldn't like to go without it, I have done so for a day or two.

With regards to Samba file-locking, is this what you were referring to?
http://www.oreilly.com/catalog/samba/chapter/book/ch05_05.html

"Windows systems cooperate well to avoid overwriting each other's
changes. But if a file stored on a Samba system is accessed by a Unix
process, this process won't know a thing about Windows oplocks and could
easily ride roughshod over a lock. Some Unix systems have been enhanced
to understand the Windows oplocks maintained by Samba. Currently the
support exists only in SGI Irix 6.5.2f and later; Linux and FreeBSD
should soon follow.

If your system does not support kernel oplocks, you could end up with
corrupted data when somebody runs a Unix process that reads or writes a
file that Windows users also access. However, Samba provides a rough
protection mechanism in the absence of kernel oplocks: the | veto| |
oplock| | files| option. If you can anticipate which Samba files are
used by both Windows users and Unix users, set their names in a | veto|
| oplock| | files| option. This will suppress the use of oplocks on
matching filenames, which will supress client caching, and let the
Windows and Unix programs use system locking or update times to detect
competition for the same file. A sample option is:

veto oplock files = /*.dbm/

This option allows both Unix processes and Windows users to edit files
ending in the suffix / .dbm/. Note that the syntax of this option is
similar to | veto| | files|."

I'm still interested in trying this out and would like some advice as to
where to go to get started.

Boaz