Skip to main content
NetApp Knowledge Base

How to troubleshoot CIFS client access issues caused by oplock delayed breaks

Last Updated:

Applies to

  • Data ONTAP 8.2 7-Mode
  • Data ONTAP 8.1 7-Mode
  • Data ONTAP 7 and earlier


Oplock delayed breaks are generally noticed in the storage system message log after end users report 'Access Denied' errors or general connectivity issues to the storage system. The error itself is not indicative of an issue with the storage system. In fact, the storage system is reporting an issue associated with the client. To understand the oplock delayed break message, it is important to understand how oplocks work.

The general flow of oplocks is as follows:

  1. Client1 opens a \storage systemsharefile1 requesting a batch or exclusive oplock
  2. Storage system responds with a batch or exclusive oplock for file1 to Client1
  3. Client2 attempts to open  \storage systemsharefile1 requesting a batch or exclusive oplock
  4. Storage system holds off on the open request to Client2 and sends an Oplock Break Request to Client1 requesting it to flush all its locks
  5. Client1 responds to the Oplock Break Request flushing its cache
  6. Storage system grants the open to Client2 with the appropriate lock

In the above example, in Step 4 when the storage system sends an Oplock Break Request to Client1, a 35 second timer is started. If Client1 does not respond to the Oplock Break Request in 35 seconds, the storage system does three things:

  1. Log an Oplock Delayed Break message that includes the IP Address of the offending client to the syslog
    Sun Nov 1 09:51:29 CET [srv123@ntap1:cifs.oplock.break.timeout:warning]: CIFS: An oplock break request to station <IP>()
  2. Forcefully clean up any locks associated on the file for Client1
  3. Grant the open response to Client2

Since Oplock Delayed Breaks are indicative of issues with the client, troubleshooting efforts should be focused on the client. There are three common reasons why a client will not respond to an oplock break request:

  1. The client rebooted abnormally (such as blue screened) and therefore no longer believes it holds a lock on the file.
  2. The client has too many open connections to the storage system and therefore cannot respond to the Oplock Break Request.
  3. There is network connectivity issues between the client and the storage system inhibiting the client from receiving the Oplock Break Request.


Sign in to view the entire content of this KB article.

New to NetApp?

Learn more about our award-winning Support

Scan to view the article on your device