Skip to main content
We are redesigning the NetApp Knowledge Base site to make it easier to use and navigate. The new and improved site will be available the first week of October. Check out our video or read this KB article to know more about changes you’ll see on the site.
NetApp Knowledge Base

How locking works in Clustered ONTAP and how to manually break locks

Last Updated:

Applies to

  • ONTAP 9
  • Clustered Data ONTAP 8
  • NAS Protocol


  • This article discusses two types of Locks
Normal Locks Stops other client machines from accessing file while an existing client is accessing it
Oplocks Allows for sharing of read access of file and client side caching of locked information
  • The First, Locks cannot be removed. They are not controlled by the Oplocks settings on the filer. They are designed to ensure that while you are reading or writing the file, no changes occur to the file by another client machine.
  • The Second, Oplocks are used to allow client machines to access the same file at the same time for read-only access. Once one client needs to perform a write to the file, the locks must be released for an exclusive write lock, which caches some, or all of the file to the client machine for editing.
  • Because of the nature of Oplocks, it was necessary to develop a mechanism to allow for their being broken, either manually by user interaction, or automatically based on the filer’s rules for doing so.

General flow of oplocks is as follows:

  1. Client1 opens \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/commit its changes and release its locks.
  5. Client1 responds to the Oplock Break Request, flushing/committing its cached writes
  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-seconds timer is started. If Client1 does not respond to the Oplock Break Request in 35 seconds, the storage system does three things:
  1. Prior to Data ONTAP 9.0 Log, an Oplock Delayed Break message that includes the IP Address of the offending client to the syslog
  2. Forcefully cleans up any locks associated on the file for Client1
  3. Grants the open response to Client2

 As 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:

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



Registered NetApp customers get unlimited access to our dynamic Knowledge Base.

New authoritative content is published and updated each day by our team of experts.

Current Customer or Partner?

Sign In for unlimited access

New to NetApp?

Learn more about our award-winning Support


******************************************************* *******************************************************