Chapter 14. File and Record Locking

One area which causes trouble for many network administrators is locking. The extent of the problem is readily evident from searches over the internet. -

Features and Benefits

Samba provides all the same locking semantics that MS Windows clients expect and that MS Windows NT4 / 200x servers provide also.

@@ -23,13 +23,13 @@ settings on the MS Windows client.

Note

Sometimes it is necessary to disable locking control settings BOTH on the Samba server as well as on each MS Windows client! -

Discussion

There are two types of locking which need to be performed by a SMB server. The first is record locking which allows a client to lock a range of bytes in a open file. The second is the deny modes that are specified when a file is open.

-Record locking semantics under Unix is very different from record locking under +Record locking semantics under UNIX are very different from record locking under Windows. Versions of Samba before 2.2 have tried to use the native fcntl() unix system call to implement proper record locking between different Samba clients. This can not be fully correct due to several reasons. The simplest is the fact @@ -40,29 +40,29 @@ many more differences, too many to be listed here.

Samba 2.2 and above implements record locking completely independent of the underlying unix system. If a byte range lock that the client requests happens -to fall into the range 0-2^31, Samba hands this request down to the Unix system. +to fall into the range 0-2^31, Samba hands this request down to the UNIX system. All other locks can not be seen by unix anyway.

-Strictly a SMB server should check for locks before every read and write call on -a file. Unfortunately with the way fcntl() works this can be slow and may overstress +Strictly an SMB server should check for locks before every read and write call on +a file. Unfortunately with the way fcntl() works this can be slow and may over-stress the rpc.lockd. It is also almost always unnecessary as clients are supposed to independently make locking calls before reads and writes anyway if locking is important to them. By default Samba only makes locking calls when explicitly asked -to by a client, but if you set strict locking = yes then it +to by a client, but if you set strict locking = yes then it will make lock checking calls on every read and write.

-You can also disable by range locking completely using locking = no. +You can also disable byte range locking completely using locking = no. This is useful for those shares that don't support locking or don't need it (such as cdroms). In this case Samba fakes the return codes of locking calls to tell clients that everything is OK.

-The second class of locking is the deny modes. These +The second class of locking is the deny modes. These are set by an application when it opens a file to determine what types of access should be allowed simultaneously with its open. A client may ask for DENY_NONE, DENY_READ, DENY_WRITE or DENY_ALL. There are also special compatibility modes called DENY_FCB and DENY_DOS. -

Opportunistic Locking Overview

Opportunistic locking (Oplocks) is invoked by the Windows file system (as opposed to an API) via registry entries (on the server AND client) for the purpose of enhancing network performance when accessing a file @@ -185,7 +185,7 @@ In mission critical high availability environments, careful attention should be given to opportunistic locking. Ideally, comprehensive testing should be done with all affected applications with oplocks enabled and disabled. -

Exclusively Accessed Shares

Opportunistic locking is most effective when it is confined to shares that are exclusively accessed by a single user, or by only one user at a time. Because the true value of opportunistic locking is the local @@ -194,7 +194,7 @@ mechanism will cause a delay.

Home directories are the most obvious examples of where the performance benefit of opportunistic locking can be safely realized. -

Multiple-Accessed Shares or Files

As each additional user accesses a file in a share with opportunistic locking enabled, the potential for delays and resulting perceived poor performance increases. When multiple users are accessing a file on a @@ -206,17 +206,17 @@ of the caching user. As each additional client attempts to access a file with oplocks set, the potential performance improvement is negated and eventually results in a performance bottleneck. -

Unix or NFS Client Accessed Files

-Local Unix and NFS clients access files without a mandatory +

UNIX or NFS Client Accessed Files

+Local UNIX and NFS clients access files without a mandatory file locking mechanism. Thus, these client platforms are incapable of initiating an oplock break request from the server to a Windows client -that has a file cached. Local Unix or NFS file access can therefore +that has a file cached. Local UNIX or NFS file access can therefore write to a file that has been cached by a Windows client, which exposes the file to likely data corruption.

-If files are shared between Windows clients, and either local Unix +If files are shared between Windows clients, and either local UNIX or NFS users, then turn opportunistic locking off. -

Slow and/or Unreliable Networks

The biggest potential performance improvement for opportunistic locking occurs when the client-side caching of reads and writes delivers the most differential over sending those reads and writes over the wire. @@ -231,7 +231,7 @@ the most advantageous scenario to utilize opportunistic locking. If the network is slow, unreliable, or a WAN, then do not configure opportunistic locking if there is any chance of multiple users regularly opening the same file. -

Multi-User Databases

Multi-user databases clearly pose a risk due to their very nature - they are typically heavily accessed by numerous users at random intervals. Placing a multi-user database on a share with opportunistic @@ -239,7 +239,7 @@ locking enabled will likely result in a locking management bottleneck on the Samba server. Whether the database application is developed in-house or a commercially available product, ensure that the share has opportunistic locking disabled. -

PDM Data Shares

Process Data Management (PDM) applications such as IMAN, Enovia, and Clearcase, are increasing in usage with Windows client platforms, and therefore SMB data stores. PDM applications manage multi-user @@ -252,8 +252,8 @@ application and PDM server to negotiate and maintain. It is appropriate to eliminate the client OS from any caching tasks, and the server from any oplock management, by disabling opportunistic locking on the share. -

Beware of Force User

-Samba includes an smb.conf parameter called force user that changes +

Beware of Force User

+Samba includes an smb.conf parameter called force user that changes the user accessing a share from the incoming user to whatever user is defined by the smb.conf variable. If opportunistic locking is enabled on a share, the change in user access causes an oplock break to be sent @@ -265,26 +265,26 @@ to overcome the lost oplock break.

Avoid the combination of the following:

- force user in the smb.conf share configuration. + force user in the smb.conf share configuration.
Slow or unreliable networks
Opportunistic Locking Enabled -

Advanced Samba Opportunistic Locking Parameters

Samba provides opportunistic locking parameters that allow the administrator to adjust various properties of the oplock mechanism to account for timing and usage levels. These parameters provide good versatility for implementing oplocks in environments where they would likely cause problems. The parameters are: -oplock break wait time, -oplock contention limit. +oplock break wait time, +oplock contention limit.

For most users, administrators, and environments, if these parameters are required, then the better option is to simply turn oplocks off. The samba SWAT help text for both parameters reads "DO NOT CHANGE THIS PARAMETER UNLESS YOU HAVE READ AND UNDERSTOOD THE SAMBA OPLOCK CODE." This is good advice. -

Mission Critical High Availability

In mission critical high availability environments, data integrity is often a priority. Complex and expensive configurations are implemented to ensure that if a client loses connectivity with a file server, a @@ -314,10 +314,10 @@ In mission critical high availability environments, careful attention should be given to opportunistic locking. Ideally, comprehensive testing should be done with all affected applications with oplocks enabled and disabled. -

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 defacto locking feature. +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 @@ -348,7 +348,7 @@ file locking with the under lying OS, SGI IRIX and Linux are the only two OS's t 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 +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 synchronisation of the entire file (not just the single record), which will result in a noticeable performance @@ -364,29 +364,23 @@ of your client sending oplock breaks and will instead want to disable oplocks fo

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. -

Example Configuration

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

Disabling Oplocks

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

-[acctdata]
-	oplocks = False
-	level2 oplocks = False
-

[acctdata]

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/
-

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. -

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 @@ -399,10 +393,7 @@ 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.

-[global]
-kernel oplocks = yes
-

kernel oplocks = yes

The default is "no".

Veto OpLocks is an smb.conf parameter that identifies specific files for @@ -417,24 +408,15 @@ 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:

<title>Example Veto OpLock Settings</title>
-[global]
-        veto oplock files = /filename.htm/*.txt/
-
-[share_name]
-        veto oplock files = /*.exe/filename.ext/
-

Example 14.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 + 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:

-[global]
-          oplock break wait time =  0 (default)
-

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 @@ -444,14 +426,8 @@ 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:

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

MS Windows Opportunistic Locking and Caching Controls

Example 14.2.

[global]

oplock break contention limit = 2 (default)

[share_name]

oplock break contention limit = 2 (default)

MS Windows Opportunistic Locking and Caching Controls

There is a known issue when running applications (like Norton Anti-Virus) on a Windows 2000/ XP workstation computer that can affect any application attempting to access shared database files across a network. This is a result of a default setting configured in the Windows 2000/XP @@ -543,7 +519,7 @@ An illustration of how level II oplocks work: station holds any oplock on the file. Because the workstations can have no cached writes or locks at this point, they need not respond to the break-to-none advisory; all they need do is invalidate locally cashed read-ahead data. -

Workstation Service Entries

 	\HKEY_LOCAL_MACHINE\System\
 		CurrentControlSet\Services\LanmanWorkstation\Parameters
 
@@ -552,7 +528,7 @@ An illustration of how level II oplocks work:

Indicates whether the redirector should use opportunistic-locking (oplock) performance enhancement. This parameter should be disabled only to isolate problems. -

Server Service Entries

 	\HKEY_LOCAL_MACHINE\System\
 		CurrentControlSet\Services\LanmanServer\Parameters
 
@@ -581,8 +557,8 @@ the server disables raw I/O and opportunistic locking for this connection.
 Specifies the time that the server waits for a client to respond to an oplock break
 request. Smaller values can allow detection of crashed clients more quickly but can
 potentially cause loss of cached data.
-

Prev	Up	Next
Chapter 13. File, Directory and Share Access Controls	Home	Chapter 15. Securing Samba