Oplocks is a unique Windows file locking feature. It is
not really file locking, but is included in most discussions of Windows
file locking, so is considered a de facto locking feature.
Oplocks is actually part of the Windows client file
caching mechanism. It is not a particularly robust or reliable feature
when implemented on the variety of customized networks that exist in
Like Windows, Samba implements oplocks as a server-side
component of the client caching mechanism. Because of the lightweight
nature of the Windows feature design, effective configuration of
oplocks requires a good understanding of its limitations,
and then applying that understanding when configuring data access for
each particular customized network and client usage state.
Oplocks essentially means that the client is allowed to download and cache
a file on its hard drive while making changes; if a second client wants to access the
file, the first client receives a break and must synchronize the file back to the server.
This can give significant performance gains in some cases; some programs insist on
synchronizing the contents of the entire file back to the server for a single change.
Level1 Oplocks (also known as just plain “oplocks”) is another term for opportunistic locking.
Level2 Oplocks provides opportunistic locking for a file that will be treated as
. Typically this is used on files that are read-only or
on files that the client has no initial intention to write to at time of opening the file.
Kernel Oplocks are essentially a method that allows the Linux kernel to co-exist with
Samba's oplocked files, although this has provided better integration of MS Windows network
file locking with the underlying OS. SGI IRIX and Linux are the only two OSs that are
oplock-aware at this time.
Unless your system supports kernel oplocks, you should disable oplocks if you are
accessing the same files from both UNIX/Linux and SMB clients. Regardless, oplocks should
always be disabled if you are sharing a database file (e.g., Microsoft Access) between
multiple clients, because any break the first client receives will affect synchronization of
the entire file (not just the single record), which will result in a noticeable performance
impairment and, more likely, problems accessing the database in the first place. Notably,
Microsoft Outlook's personal folders (*.pst) react quite badly to oplocks. If in doubt,
disable oplocks and tune your system from that point.
If client-side caching is desirable and reliable on your network, you will benefit from
turning on oplocks. If your network is slow and/or unreliable, or you are sharing your
files among other file sharing mechanisms (e.g., NFS) or across a WAN, or multiple people
will be accessing the same files frequently, you probably will not benefit from the overhead
of your client sending oplock breaks and will instead want to disable oplocks for the share.
Another factor to consider is the perceived performance of file access. If oplocks provide no
measurable speed benefit on your network, it might not be worth the hassle of dealing with them.