[Samba] tdb lock failures

[David Nash]

We've just gone live with a file & print server, and are having major
problems with Samba.  When used out of hours, with all PCs switched on
and connected to the domain, everything works fine.  However, during the
day, we have problems where users can't print to any samba-hosted
printer, Access database applications (where the database is held on the
server) won't work, or work briefly before experiencing data corruption.
Our system log file is filling at an alarming rate with messages about
tdb lock failures.

 

Part of log file when trying to print:

 

[2004/06/29 11:15:27, 2] lib/access.c:(329)
  Allowed connection from  (192.0.0.123)
[2004/06/29 11:15:27, 0] tdb/tdbutil.c:(531)
  tdb(/usr/lib/samba/var/locks/printing.tdb): tdb_lock failed on list
107 ltype=1 (No record locks available)
[2004/06/29 11:15:27, 0] tdb/tdbutil.c:(531)
  tdb(/usr/lib/samba/var/locks/printing.tdb): tdb_lock failed on list 91
ltype=1 (No record locks available)
[2004/06/29 11:15:27, 0] tdb/tdbutil.c:(531)
  tdb(/usr/lib/samba/var/locks/printing.tdb): tdb_lock failed on list 80
ltype=2 (No record locks available)
[2004/06/29 11:15:27, 0] printing/printing.c:(388)
  print_queue_update: Failed to lock printing database

 

Other errors on file access

 

[2004/06/29 11:00:45, 0] tdb/tdbutil.c:(531)
  tdb(/usr/lib/samba/var/locks/brlock.tdb): tdb_unlock: count is 0
[2004/06/29 11:00:45, 2] smbd/close.c:(229)
  janette closed file templat2/INVESTOR.BMP (numopen=7) 
[2004/06/29 11:00:45, 0] tdb/tdbutil.c:(531)
  tdb(/usr/lib/samba/var/locks/locking.tdb): tdb_lock failed on list 39
ltype=2 (No record locks available)
[2004/06/29 11:00:45, 0] tdb/tdbutil.c:(531)
  tdb(/usr/lib/samba/var/locks/locking.tdb): tdb_lock failed on list 39
ltype=1 (No record locks available)
[2004/06/29 11:00:45, 0] tdb/tdbutil.c:(531)
  tdb(/usr/lib/samba/var/locks/locking.tdb): tdb_unlock: count is 0
[2004/06/29 11:00:45, 0] tdb/tdbutil.c:(531)
  tdb(/usr/lib/samba/var/locks/brlock.tdb): tdb_lock failed on list 39
ltype=2 (No record locks available)
[2004/06/29 11:00:45, 0] tdb/tdbutil.c:(531)
  tdb(/usr/lib/samba/var/locks/brlock.tdb): tdb_lock failed on list 39
ltype=1 (No record locks available)
[2004/06/29 11:00:45, 0] tdb/tdbutil.c:(531)
  tdb(/usr/lib/samba/var/locks/brlock.tdb): tdb_unlock: count is 0
[2004/06/29 11:00:45, 2] smbd/close.c:(229)
  janette closed file Wills04/~$25.1will.jrh.doc (numopen=9) 
[2004/06/29 11:00:48, 0] tdb/tdbutil.c:(531)
  tdb(/usr/lib/samba/var/locks/locking.tdb): tdb_lock failed on list 65
ltype=2 (No record locks available)
 

 

With the printing problem, I can log onto the domain as 'root' and
successfully printing to the waterroom1 printer.  Out of hours, I am
able to login to my PC as 'mike', and print to the same printer which
fails during the day for any user other than root.

 

 

We're on UnixWare 7.1.3.Pack 3, and Samba 2.2.8a

 

The other related (I think) problem we have is with a 40MB access
database on the 'estate' share - it works for a wee while, then we get
database errors and have to restore from a good copy.  We've turned off
Oplocks on the XP PCs, and tried various settings on the Samba share.
When Oplocks are off on Samba we can't even open the application.  We
turned off oplocks on all shares last night (but didn't set strict
locking) but this morning users couldn't open shared templates that are
held on the 'templates' share, and we had problems with users being
unable to open spreadsheets on the 'cashroom' share.  We've turned
oplocks on for all samba shares, but still have printing and database
problems during the day.

 

In the 100MB+ sys file, I've seen errors saying  'no record locks
available - this can happen when using 64bit lock offsets'.

 

I read something on the web about similar problems when the lock files
are held on NFS partitions, and am wondering whether the /root partition
is incompatible (I think it's vxfs).  I'm also wondering about the 'lock
spin count' and 'lock spin time' parameters...

 

I've had to set up some local printers, and a couple of departments
haven't been able to work for the last couple of days!

 

David