Red Hat Bugzilla – Bug 200759
Samba (CIFS) lock recovery after a failover.
Last modified: 2007-11-30 17:07:26 EST
Description of problem:
After a service failover, Samba (CIFS) locks are not reserved. Also (Windows)
clients who previously owned the locks are not notified about the Samba service
failover. A new client can acquire the same lock, thus data corruption might
I think this bug is more on the Samba side. One of your colleague,
firstname.lastname@example.org, has asked me to log this bug.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Samba lock failover / recovery is partially a limitation of the CIFS protocol.
As I understand it, locks are connection based and tied to the connection.
After a failover, the connection is lost - therefore, so are the locks
associated with the connection. Clients are expected to reacquire all locks
after reconnecting, which might not be directly possible if they are blocked in
I/O with a lock held at the time of a failover. If a layer under an application
reconnects transparently and the application is not notified to reacquire
any/all locks, then the application will assume state is okay and proceed,
potentially causing data corruption if another application acquired a lock after
The connection/lock association makes implementation of transparent lock
failover itself fairly difficult. I had attempted to write a howto based on
storing lock information on shared storage so that it might retrieve the lock
information, which is what several other Open Source projects do. This is,
however inadequate. That there is no reclaim protocol for locks similar to the
NLM reclaim protocol for NFS, or at least, I am not aware of any. Even some
proprietary vendors do not claim Samba lock failover in their expensive
There are, however, several ideas on how to make Samba work more reliably in
high availability environments.
Indeed. This bug calls for protocol extensions, client updates, and should be
considered in that context (ie, not going to happen...).
I'm marking this as CANTFIX, as I think that's the best description.