Red Hat Bugzilla – Bug 377621
Error acquiring lock on secrets.tdb
Last modified: 2010-10-22 16:12:09 EDT
From time to time I got errors from windows clients (mainly W2k3) trying to
access resources shared via SMB.
The error reported in the smb logs seems to be related with acquiring a lock on
the server credentials file:
[2007/11/10 05:02:39, 0] tdb/tdbutil.c:tdb_log(725)
tdb(/var/spool/six/nas/fi_nodo1/secrets.tdb): tdb_lock failed on list 2 type=1
(Interrupted system call)
[2007/11/10 05:02:39, 0] tdb/tdbutil.c:tdb_chainlock_with_timeout_internal(77)
tdb_chainlock_with_timeout_internal: alarm (10) timed out for key replay cache
mutex in tdb /var/spool/six/nas/fi_nodo1/secrets.tdb
The server is running RHEL 4 update 4 on x86_64, with:
The samba server is running with security = ADS (see attached configuration)
Created attachment 255091 [details]
smb configuration used
The location of the file is not the standard location.
Why have you changed it?
Is it on an NFS share?
NFS storage is not ok for .tdb files as locking over NFS is usually not good
enough to correctly preserve the database integrity.
(In reply to comment #2)
These server are a sort of homemade NAS hence this samba service is managed by
the Cluster infrastructure (only one node active at once), this is the reason
for using a different location for smb.conf.
The filesystem used is ext3 on internal SCSI disks.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
The customer has tested the packages and they have not had a samba lockup
since, so it would appear that this patch is ready for a hotfix.
Internal Status set to 'Waiting on Support'
Status set to: Waiting on Tech
This event sent from IssueTracker by jwest
I've tested the new release and it seems to work fine (no problems on
secrets.tdb) but the smbclient shipped with this version seems not to be working
properly with smb packet signing since when doing
smbclient //servername/servershare -c 'dir'
I got errors like this (the command does not succede):
OS=[Windows Server 2003 3790 Service Pack 2] Server=[Windows Server 2003 5.2]
client_check_incoming_message: received message with mid 7 with no matching send
SMB Signature verification failed on incoming packet!
Server packet had invalid SMB signature! listing \*
Error in dskattr: Server packet had invalid SMB signature!
The previous command only works if packet signing is disabled.
Since the samba version shipped with RHEL 5 (3.0.25b) works fine, might it
depend on the fix to smb signing introduced in this release?
We shouldn't have signing problems in this release, can you please open a new
bug and post there the problem with your smb.conf and the output of smbclient
with the -d 10 switch ?
Closing this one as fixed.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.