13.3 Samba Opportunistic Locking Control

Opportunistic locking 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. Opportunistic locking 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 enterprise computing.

Like Windows, Samba implements opportunistic locking as a server-side component of the client caching mechanism. Because of the lightweight nature of the Windows feature design, effective configuration of opportunistic locking 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.

Opportunistic locking essentially means that the client is allowed to download and cache a file on their 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 read only . 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 , as 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.

13.3.1 Example Configuration

In the following section we examine two distinct aspects of Samba locking controls.

13.3.1.1 Disabling Oplocks

You can disable oplocks on a per-share basis with the following:

  oplocks = False   level2 oplocks = False

The default oplock type is Level1. Level2 oplocks are enabled on a per-share basis in the smb.conf file.

Alternately, you could disable oplocks on a per-file basis within the share:

  veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/

If you are experiencing problems with oplocks as apparent from Samba's log entries, you may want to play it safe and disable oplocks and Level2 oplocks.

13.3.1.2 Disabling Kernel Oplocks

Kernel oplocks is an smb.conf parameter that notifies Samba (if the UNIX kernel has the capability to send a Windows client an oplock break) when a UNIX process is attempting to open the file that is cached. This parameter addresses sharing files between UNIX and Windows with oplocks enabled on the Samba server: the UNIX process can open the file that is Oplocked (cached) by the Windows client and the smbd process will not send an oplock break, which exposes the file to the risk of data corruption. If the UNIX kernel has the ability to send an oplock break, then the kernel oplocks parameter enables Samba to send the oplock break. Kernel oplocks are enabled on a per-server basis in the smb.conf file.

  kernel oplocks = yes

The default is no.

Veto opLocks is an smb.conf parameter that identifies specific files for which oplocks are disabled. When a Windows client opens a file that has been configured for veto oplocks, the client will not be granted the oplock, and all operations will be executed on the original file on disk instead of a client-cached file copy. By explicitly identifying files that are shared with UNIX processes and disabling oplocks for those files, the server-wide Oplock configuration can be enabled to allow Windows clients to utilize the performance benefit of file caching without the risk of data corruption. Veto Oplocks can be enabled on a per-share basis, or globally for the entire server, in the smb.conf file as shown in Example 13.1.

Example 13.1 Share with some files oplocked

  [global]   veto oplock files = /filename.htm/*.txt/   [share_name]   veto oplock files = /*.exe/filename.ext/

oplock break wait time is an smb.conf parameter that adjusts the time interval for Samba to reply to an oplock break request. Samba recommends: " Do not change this parameter unless you have read and understood the Samba oplock code ." oplock break Wait Time can only be configured globally in the smb.conf file as shown below.

  oplock break wait time = 0 (default)

Oplock break contention limit is an smb.conf parameter that limits the response of the Samba server to grant an oplock if the configured number of contending clients reaches the limit specified by the parameter. Samba recommends " Do not change this parameter unless you have read and understood the Samba oplock code ." Oplock break Contention Limit can be enable on a per-share basis, or globally for the entire server, in the smb.conf file as shown in Example 13.2.

Example 13.2 Configuration with oplock break contention limit

  [global]   oplock break contention limit = 2 (default)   [share_name]   oplock break contention limit = 2 (default)