Ted Roche wrote:
> I've got a client using a Samba server to hosts DBFs used in a
> multi-user order entry and accounting application. Sometimes things
> don't work right. The operators insist "I didn't do anything" but we
> know they reboot once in a while and also there seems to be a point in
> their application (20-year-old FoxBase code) where the system crashes,
> although we are remote and haven't yet got sufficient instrumentation
> to figure out all of the details.
>
> I wanted to make sure I've got the Samba configuration correct for
> multi-user locking; there's usually only one developer here in the
> office using an app, and we usually all just develop on our own
> machines, so the infrequent testing on our in-house Samba shares is
> certainly not conclusive. Has anyone found an authoritative reference
> that recommends the use of the 'oplock' or 'spinlock' directives in
> smb.conf for successful VFP operations? Or know conclusively they are
> not needed? It would be good to eliminate this as a possible cause of
> their data problems.
Ted, I've found that setting oplocks and level 2 oplocks to no are
critical for any file-based database access, including FoxPro,
Peachtree, Quickbooks, and the like. Here are the relevant settings in
my smb.conf:
[sbs]
comment = SBS Custom App Data
path = /var/local/samba/sbs
public = yes
read only = no
oplocks = no
fake oplocks = no
level 2 oplocks = no
create mask = 770
directory mask = 770
I hope it helps! This samba setup has been working as a PDC sharing this
and several other shares to 20 users for about 5 years now. The VFP app
uses views heavily, lots of reads and commits coming over the wire all
day every day. There hasn't been any data corruption, ever, except
during a hard drive failure about a year ago, from which we successfully
recovered from the hourly backup.
Workstations are all currently Windows XP, although they used to be a
mix of NT4 and Win2k; server is FC2 running Samba 3.0.10-fc2.
If you suspect a samba problem you may want to step up your log level to
2 or 3 or even higher and take a good look at the logs, especially if
you can target a time frame when the bad events occur.
Paul
©2008 Paul McNett |
