If this problem suddenly appeared out of the blue even though nothing was changed on either the Samba server or the NFS backend, it could be network related (routers, firewalls, NAT etc). If you've recently introduced new Windows clients running a later version of Windows, it could also be SMB/CIFS related. (Here's some information
about SMB/CIFS oplocks.)
"Oplock break failed" means Samba thinks the file is in use and "opportunistically locked" by another client, but is unable to force this client to release the oplock and write cached information back to the file.
There could be several reasons for this. The file may in fact be in use, but something prevents Samba from sending a break message to the client, or it never receives a reply. This could be an SMB dialect issue or simply a bug in Samba.
It is also possible that the file is not actually in use, but Samba believes that it is due to stale session information. In that case, Samba sends a break message to a client that may actually be offline, and once the timeout period has expired you get the "oplock break failed" message in the log.
You could try the following:
- add SO_KEEPALIVE to "socket options" to have Samba check clients for reachability at regular intervals and remove stale sessions
- disable oplocks on the share in question "oplocks = no" (this may affect performance)
- upgrade to the latest Samba release to eliminate protocol/SMB dialect issues