diff options
Diffstat (limited to 'docs/htmldocs/Samba3-HOWTO/locking.html')
| -rw-r--r-- | docs/htmldocs/Samba3-HOWTO/locking.html | 711 |
1 files changed, 0 insertions, 711 deletions
diff --git a/docs/htmldocs/Samba3-HOWTO/locking.html b/docs/htmldocs/Samba3-HOWTO/locking.html deleted file mode 100644 index cb494cd21c..0000000000 --- a/docs/htmldocs/Samba3-HOWTO/locking.html +++ /dev/null @@ -1,711 +0,0 @@ -<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 17. File and Record Locking</title><link rel="stylesheet" href="../samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="The Official Samba 3.5.x HOWTO and Reference Guide"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="prev" href="AccessControls.html" title="Chapter 16. File, Directory, and Share Access Controls"><link rel="next" href="securing-samba.html" title="Chapter 18. Securing Samba"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 17. File and Record Locking</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="AccessControls.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="securing-samba.html">Next</a></td></tr></table><hr></div><div class="chapter" title="Chapter 17. File and Record Locking"><div class="titlepage"><div><div><h2 class="title"><a name="locking"></a>Chapter 17. File and Record Locking</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Jeremy</span> <span class="surname">Allison</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:jra@samba.org">jra@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jelmer</span> <span class="othername">R.</span> <span class="surname">Vernooij</span></h3><div class="affiliation"><span class="orgname">The Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:jelmer@samba.org">jelmer@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:jht@samba.org">jht@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Eric</span> <span class="surname">Roseme</span></h3><div class="affiliation"><span class="orgname">HP Oplocks Usage Recommendations Whitepaper<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:eric.roseme@hp.com">eric.roseme@hp.com</a>></code></p></div></div></div></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="locking.html#id383088">Features and Benefits</a></span></dt><dt><span class="sect1"><a href="locking.html#id383174">Discussion</a></span></dt><dd><dl><dt><span class="sect2"><a href="locking.html#id383412">Opportunistic Locking Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="locking.html#id384264">Samba Oplocks Control</a></span></dt><dd><dl><dt><span class="sect2"><a href="locking.html#id384333">Example Configuration</a></span></dt></dl></dd><dt><span class="sect1"><a href="locking.html#id384716">MS Windows Oplocks and Caching Controls</a></span></dt><dd><dl><dt><span class="sect2"><a href="locking.html#id384868">Workstation Service Entries</a></span></dt><dt><span class="sect2"><a href="locking.html#id384888">Server Service Entries</a></span></dt></dl></dd><dt><span class="sect1"><a href="locking.html#id384944">Persistent Data Corruption</a></span></dt><dt><span class="sect1"><a href="locking.html#id384963">Common Errors</a></span></dt><dd><dl><dt><span class="sect2"><a href="locking.html#id385014">locking.tdb Error Messages</a></span></dt><dt><span class="sect2"><a href="locking.html#id385042">Problems Saving Files in MS Office on Windows XP</a></span></dt><dt><span class="sect2"><a href="locking.html#id385065">Long Delays Deleting Files over Network with XP SP1</a></span></dt></dl></dd><dt><span class="sect1"><a href="locking.html#id385094">Additional Reading</a></span></dt></dl></div><p> -<a class="indexterm" name="id383078"></a> -One area that causes trouble for many network administrators is locking. -The extent of the problem is readily evident from searches over the Internet. -</p><div class="sect1" title="Features and Benefits"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id383088"></a>Features and Benefits</h2></div></div></div><p> -<a class="indexterm" name="id383095"></a> -Samba provides all the same locking semantics that MS Windows clients expect -and that MS Windows NT4/200x servers also provide. -</p><p> -<a class="indexterm" name="id383106"></a> -The term <span class="emphasis"><em>locking</em></span> has exceptionally broad meaning and covers -a range of functions that are all categorized under this one term. -</p><p> -<a class="indexterm" name="id383121"></a> -<a class="indexterm" name="id383128"></a> -<a class="indexterm" name="id383135"></a> -Opportunistic locking is a desirable feature when it can enhance the -perceived performance of applications on a networked client. However, the -opportunistic locking protocol is not robust and therefore can -encounter problems when invoked beyond a simplistic configuration or -on extended slow or faulty networks. In these cases, operating -system management of opportunistic locking and/or recovering from -repetitive errors can offset the perceived performance advantage that -it is intended to provide. -</p><p> -<a class="indexterm" name="id383149"></a> -The MS Windows network administrator needs to be aware that file and record -locking semantics (behavior) can be controlled either in Samba or by way of registry -settings on the MS Windows client. -</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -<a class="indexterm" name="id383163"></a> -Sometimes it is necessary to disable locking control settings on the Samba -server as well as on each MS Windows client! -</p></div></div><div class="sect1" title="Discussion"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id383174"></a>Discussion</h2></div></div></div><p> -<a class="indexterm" name="id383182"></a> -<a class="indexterm" name="id383189"></a> -There are two types of locking that need to be performed by an SMB server. -The first is <span class="emphasis"><em>record locking</em></span> that allows a client to lock -a range of bytes in an open file. The second is the <span class="emphasis"><em>deny modes</em></span> -that are specified when a file is open. -</p><p> -<a class="indexterm" name="id383207"></a> -<a class="indexterm" name="id383214"></a> -<a class="indexterm" name="id383221"></a> -<a class="indexterm" name="id383228"></a> -<a class="indexterm" name="id383234"></a> -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 cannot be fully correct for several reasons. The simplest is -that a Windows client is allowed to lock a byte range up to 2^32 or 2^64, -depending on the client OS. The UNIX locking only supports byte ranges up to 2^31. -So it is not possible to correctly satisfy a lock request above 2^31. There are -many more differences, too many to be listed here. -</p><p> -<a class="indexterm" name="id383249"></a> -<a class="indexterm" name="id383256"></a> -Samba 2.2 and above implement record locking completely independently of the -underlying UNIX system. If a byte-range lock that the client requests happens -to fall into the range of 0 to 2^31, Samba hands this request down to the UNIX system. -No other locks can be seen by UNIX, anyway. -</p><p> -<a class="indexterm" name="id383269"></a> -<a class="indexterm" name="id383276"></a> -Strictly speaking, 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 overstress -the <code class="literal">rpc.lockd</code>. This is almost always unnecessary because clients are -independently supposed to make locking calls before reads and writes if locking is -important to them. By default, Samba only makes locking calls when explicitly asked -to by a client, but if you set <a class="link" href="smb.conf.5.html#STRICTLOCKING" target="_top">strict locking = yes</a>, it -will make lock checking calls on <span class="emphasis"><em>every</em></span> read and write call. -</p><p> -<a class="indexterm" name="id383312"></a> -You can also disable byte-range locking completely by using -<a class="link" href="smb.conf.5.html#LOCKING" target="_top">locking = no</a>. -This is useful for those shares that do not support locking or do not need it -(such as CD-ROMs). In this case, Samba fakes the return codes of locking calls to -tell clients that everything is okay. -</p><p> -<a class="indexterm" name="id383336"></a> -<a class="indexterm" name="id383342"></a> -<a class="indexterm" name="id383349"></a> -<a class="indexterm" name="id383356"></a> -<a class="indexterm" name="id383363"></a> -<a class="indexterm" name="id383370"></a> -<a class="indexterm" name="id383376"></a> -The second class of locking is the <span class="emphasis"><em>deny modes</em></span>. 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 -<code class="constant">DENY_NONE</code>, <code class="constant">DENY_READ</code>, -<code class="constant">DENY_WRITE</code>, or <code class="constant">DENY_ALL</code>. There are also special compatibility -modes called <code class="constant">DENY_FCB</code> and <code class="constant">DENY_DOS</code>. -</p><div class="sect2" title="Opportunistic Locking Overview"><div class="titlepage"><div><div><h3 class="title"><a name="id383412"></a>Opportunistic Locking Overview</h3></div></div></div><p> -<a class="indexterm" name="id383420"></a> -<a class="indexterm" name="id383427"></a> -<a class="indexterm" name="id383433"></a> -Opportunistic locking (oplocks) is invoked by the Windows file system -(as opposed to an API) via registry entries (on the server and the client) -for the purpose of enhancing network performance when accessing a file -residing on a server. Performance is enhanced by caching the file -locally on the client that allows the following: -</p><div class="variablelist"><dl><dt><span class="term">Read-ahead:</span></dt><dd><p> -<a class="indexterm" name="id383454"></a> - The client reads the local copy of the file, eliminating network latency. - </p></dd><dt><span class="term">Write caching:</span></dt><dd><p> -<a class="indexterm" name="id383471"></a> - The client writes to the local copy of the file, eliminating network latency. - </p></dd><dt><span class="term">Lock caching:</span></dt><dd><p> -<a class="indexterm" name="id383488"></a> - The client caches application locks locally, eliminating network latency. - </p></dd></dl></div><p> -<a class="indexterm" name="id383501"></a> -<a class="indexterm" name="id383508"></a> -<a class="indexterm" name="id383515"></a> -The performance enhancement of oplocks is due to the opportunity of -exclusive access to the file even if it is opened with deny-none -because Windows monitors the file's status for concurrent access from -other processes. -</p><div class="variablelist" title="Windows Defines Four Kinds of Oplocks:"><p class="title"><b>Windows Defines Four Kinds of Oplocks:</b></p><dl><dt><span class="term">Level1 Oplock</span></dt><dd><p> -<a class="indexterm" name="id383543"></a> -<a class="indexterm" name="id383550"></a> -<a class="indexterm" name="id383557"></a> -<a class="indexterm" name="id383564"></a> - The redirector sees that the file was opened with deny - none (allowing concurrent access), verifies that no - other process is accessing the file, checks that - oplocks are enabled, then grants deny-all/read-write/exclusive - access to the file. The client now performs - operations on the cached local file. - </p><p> -<a class="indexterm" name="id383576"></a> -<a class="indexterm" name="id383583"></a> -<a class="indexterm" name="id383590"></a> -<a class="indexterm" name="id383597"></a> - If a second process attempts to open the file, the open - is deferred while the redirector "breaks" the original - oplock. The oplock break signals the caching client to - write the local file back to the server, flush the - local locks, and discard read-ahead data. The break is - then complete, the deferred open is granted, and the - multiple processes can enjoy concurrent file access as - dictated by mandatory or byte-range locking options. - However, if the original opening process opened the - file with a share mode other than deny-none, then the - second process is granted limited or no access, despite - the oplock break. - </p></dd><dt><span class="term">Level2 Oplock</span></dt><dd><p> -<a class="indexterm" name="id383619"></a> -<a class="indexterm" name="id383626"></a> -<a class="indexterm" name="id383633"></a> - Performs like a Level1 oplock, except caching is only - operative for reads. All other operations are performed - on the server disk copy of the file. - </p></dd><dt><span class="term">Filter Oplock</span></dt><dd><p> -<a class="indexterm" name="id383651"></a> - Does not allow write or delete file access. - </p></dd><dt><span class="term">Batch Oplock</span></dt><dd><p> -<a class="indexterm" name="id383668"></a> - Manipulates file openings and closings and allows caching - of file attributes. - </p></dd></dl></div><p> -<a class="indexterm" name="id383682"></a> -An important detail is that oplocks are invoked by the file system, not -an application API. Therefore, an application can close an oplocked -file, but the file system does not relinquish the oplock. When the -oplock break is issued, the file system then simply closes the file in -preparation for the subsequent open by the second process. -</p><p> -<a class="indexterm" name="id383695"></a> -<a class="indexterm" name="id383701"></a> -<a class="indexterm" name="id383708"></a> -<a class="indexterm" name="id383715"></a> -<span class="emphasis"><em>Opportunistic locking</em></span> is actually an improper name for this feature. -The true benefit of this feature is client-side data caching, and -oplocks is merely a notification mechanism for writing data back to the -networked storage disk. The limitation of oplocks is the -reliability of the mechanism to process an oplock break (notification) -between the server and the caching client. If this exchange is faulty -(usually due to timing out for any number of reasons), then the -client-side caching benefit is negated. -</p><p> -<a class="indexterm" name="id383733"></a> -The actual decision that a user or administrator should consider is -whether it is sensible to share among multiple users data that will -be cached locally on a client. In many cases the answer is no. -Deciding when to cache or not cache data is the real question, and thus -oplocks should be treated as a toggle for client-side -caching. Turn it <span class="quote">“<span class="quote">on</span>”</span> when client-side caching is desirable and -reliable. Turn it <span class="quote">“<span class="quote">off</span>”</span> when client-side caching is redundant, -unreliable, or counterproductive. -</p><p> -<a class="indexterm" name="id383754"></a> -Oplocks is by default set to <span class="quote">“<span class="quote">on</span>”</span> by Samba on all -configured shares, so careful attention should be given to each case to -determine if the potential benefit is worth the potential for delays. -The following recommendations will help to characterize the environment -where oplocks may be effectively configured. -</p><p> -<a class="indexterm" name="id383770"></a> -<a class="indexterm" name="id383776"></a> -Windows oplocks is a lightweight performance-enhancing -feature. It is not a robust and reliable protocol. Every -implementation of oplocks should be evaluated as a -trade-off between perceived performance and reliability. Reliability -decreases as each successive rule above is not enforced. Consider a -share with oplocks enabled, over a wide-area network, to a client on a -South Pacific atoll, on a high-availability server, serving a -mission-critical multiuser corporate database during a tropical -storm. This configuration will likely encounter problems with oplocks. -</p><p> -<a class="indexterm" name="id383791"></a> -Oplocks can be beneficial to perceived client performance when treated -as a configuration toggle for client-side data caching. If the data -caching is likely to be interrupted, then oplock usage should be -reviewed. Samba enables oplocks by default on all -shares. Careful attention should be given to the client usage of -shared data on the server, the server network reliability, and the -oplocks configuration of each share. -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 -failover replacement will be available immediately to provide -continuous data availability. -</p><p> -<a class="indexterm" name="id383808"></a> -<a class="indexterm" name="id383814"></a> -Windows client failover behavior is more at risk of application -interruption than other platforms because it is dependent upon an -established TCP transport connection. If the connection is interrupted - as in a file server failover a new session must be established. -It is rare for Windows client applications to be coded to recover -correctly from a transport connection loss; therefore, most applications -will experience some sort of interruption at worst, abort and -require restarting. -</p><p> -<a class="indexterm" name="id383837"></a> -<a class="indexterm" name="id383843"></a> -<a class="indexterm" name="id383850"></a> -If a client session has been caching writes and reads locally due to -oplocks, it is likely that the data will be lost when the -application restarts or recovers from the TCP interrupt. When the TCP -connection drops, the client state is lost. When the file server -recovers, an oplock break is not sent to the client. In this case, the -work from the prior session is lost. Observing this scenario with -oplocks disabled and with the client writing data to the file server -real-time, the failover will provide the data on disk as it -existed at the time of the disconnect. -</p><p> -In mission-critical, high-availability environments, careful attention -should be given to oplocks. Ideally, comprehensive -testing should be done with all affected applications with oplocks -enabled and disabled. -</p><div class="sect3" title="Exclusively Accessed Shares"><div class="titlepage"><div><div><h4 class="title"><a name="id383868"></a>Exclusively Accessed Shares</h4></div></div></div><p> -Oplocks 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 oplocks is the local -client caching of data, any operation that interrupts the caching -mechanism will cause a delay. -</p><p> -Home directories are the most obvious examples of where the performance -benefit of oplocks can be safely realized. -</p></div><div class="sect3" title="Multiple-Accessed Shares or Files"><div class="titlepage"><div><div><h4 class="title"><a name="id383885"></a>Multiple-Accessed Shares or Files</h4></div></div></div><p> -As each additional user accesses a file in a share with oplocks -enabled, the potential for delays and resulting perceived poor -performance increases. When multiple users are accessing a file on a -share that has oplocks enabled, the management impact of sending and -receiving oplock breaks and the resulting latency while other clients -wait for the caching client to flush data offset the performance gains -of the caching user. -</p><p> -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. -</p></div><div class="sect3" title="UNIX or NFS Client-Accessed Files"><div class="titlepage"><div><div><h4 class="title"><a name="id383903"></a>UNIX or NFS Client-Accessed Files</h4></div></div></div><p> -<a class="indexterm" name="id383911"></a> -<a class="indexterm" name="id383918"></a> -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 -write to a file that has been cached by a Windows client, which -exposes the file to likely data corruption. -</p><p> -If files are shared between Windows clients and either local UNIX -or NFS users, turn oplocks off. -</p></div><div class="sect3" title="Slow and/or Unreliable Networks"><div class="titlepage"><div><div><h4 class="title"><a name="id383934"></a>Slow and/or Unreliable Networks</h4></div></div></div><p> -<a class="indexterm" name="id383942"></a> -<a class="indexterm" name="id383949"></a> -<a class="indexterm" name="id383955"></a> -The biggest potential performance improvement for oplocks -occurs when the client-side caching of reads and writes delivers the -most differential over sending those reads and writes over the wire. -This is most likely to occur when the network is extremely slow, -congested, or distributed (as in a WAN). However, network latency also -has a high impact on the reliability of the oplock break -mechanism, and thus increases the likelihood of encountering oplock -problems that more than offset the potential perceived performance -gain. Of course, if an oplock break never has to be sent, then this is -the most advantageous scenario in which to utilize oplocks. -</p><p> -If the network is slow, unreliable, or a WAN, then do not configure -oplocks if there is any chance of multiple users -regularly opening the same file. -</p></div><div class="sect3" title="Multiuser Databases"><div class="titlepage"><div><div><h4 class="title"><a name="id383974"></a>Multiuser Databases</h4></div></div></div><p> -<a class="indexterm" name="id383982"></a> -<a class="indexterm" name="id383989"></a> -<a class="indexterm" name="id383996"></a> -Multiuser databases clearly pose a risk due to their very nature they are typically heavily -accessed by numerous users at random intervals. Placing a multiuser database on a share with oplocks 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 oplocks disabled. -</p></div><div class="sect3" title="PDM Data Shares"><div class="titlepage"><div><div><h4 class="title"><a name="id384012"></a>PDM Data Shares</h4></div></div></div><p> -<a class="indexterm" name="id384020"></a> -<a class="indexterm" name="id384026"></a> -<a class="indexterm" name="id384032"></a> -<a class="indexterm" name="id384039"></a> -<a class="indexterm" name="id384046"></a> -Process data management (PDM) applications such as IMAN, Enovia, and Clearcase are increasing in usage with -Windows client platforms and therefore with SMB datastores. PDM applications manage multiuser environments for -critical data security and access. The typical PDM environment is usually associated with sophisticated client -design applications that will load data locally as demanded. In addition, the PDM application will usually -monitor the data state of each client. In this case, client-side data caching is best left to the local -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 oplocks management, by disabling oplocks on the share. -</p></div><div class="sect3" title="Beware of Force User"><div class="titlepage"><div><div><h4 class="title"><a name="id384068"></a>Beware of Force User</h4></div></div></div><p> -<a class="indexterm" name="id384075"></a> -Samba includes an <code class="filename">smb.conf</code> parameter called <a class="link" href="smb.conf.5.html#FORCEUSER" target="_top">force user</a> that changes the user -accessing a share from the incoming user to whatever user is defined by the <code class="filename">smb.conf</code> variable. If oplocks is -enabled on a share, the change in user access causes an oplock break to be sent to the client, even if the -user has not explicitly loaded a file. In cases where the network is slow or unreliable, an oplock break can -become lost without the user even accessing a file. This can cause apparent performance degradation as the -client continually reconnects to overcome the lost oplock break. -</p><p> -Avoid the combination of the following: -</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - <a class="link" href="smb.conf.5.html#FORCEUSER" target="_top">force user</a> in the <code class="filename">smb.conf</code> share configuration. - </p></li><li class="listitem"><p> - Slow or unreliable networks. - </p></li><li class="listitem"><p> - Oplocks enabled. - </p></li></ul></div></div><div class="sect3" title="Advanced Samba Oplocks Parameters"><div class="titlepage"><div><div><h4 class="title"><a name="id384149"></a>Advanced Samba Oplocks Parameters</h4></div></div></div><p> -<a class="indexterm" name="id384157"></a> -<a class="indexterm" name="id384163"></a> -<a class="indexterm" name="id384170"></a> -Samba provides oplock 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 -<a class="link" href="smb.conf.5.html#OPLOCKBREAKWAITTIME" target="_top">oplock break wait time</a>, and -<a class="link" href="smb.conf.5.html#OPLOCKCONTENTIONLIMIT" target="_top">oplock contention limit</a>. -</p><p> -<a class="indexterm" name="id384206"></a> -For most users, administrators, and environments, if these parameters -are required, then the better option is simply to turn oplocks off. -The Samba SWAT help text for both parameters reads: <span class="quote">“<span class="quote">Do not change -this parameter unless you have read and understood the Samba oplock code.</span>”</span> -This is good advice. -</p></div><div class="sect3" title="Mission-Critical, High-Availability"><div class="titlepage"><div><div><h4 class="title"><a name="id384220"></a>Mission-Critical, High-Availability</h4></div></div></div><p> -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 -failover replacement will be available immediately to provide -continuous data availability. -</p><p> -Windows client failover behavior is more at risk of application -interruption than other platforms because it is dependent upon an -established TCP transport connection. If the connection is interrupted - as in a file server failover a new session must be established. -It is rare for Windows client applications to be coded to recover -correctly from a transport connection loss; therefore, most applications -will experience some sort of interruption at worst, abort and -require restarting. -</p><p> -If a client session has been caching writes and reads locally due to -oplocks, it is likely that the data will be lost when the -application restarts or recovers from the TCP interrupt. When the TCP -connection drops, the client state is lost. When the file server -recovers, an oplock break is not sent to the client. In this case, the -work from the prior session is lost. Observing this scenario with -oplocks disabled, if the client was writing data to the file server -real-time, then the failover will provide the data on disk as it -existed at the time of the disconnect. -</p><p> -In mission-critical, high-availability environments, careful attention -should be given to oplocks. Ideally, comprehensive -testing should be done with all affected applications with oplocks -enabled and disabled. -</p></div></div></div><div class="sect1" title="Samba Oplocks Control"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id384264"></a>Samba Oplocks Control</h2></div></div></div><p> -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 -enterprise computing. -</p><p> -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. -</p><p> -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. -</p><p> -Level1 Oplocks (also known as just plain <span class="quote">“<span class="quote">oplocks</span>”</span>) is another term for opportunistic locking. -</p><p> -Level2 Oplocks provides opportunistic locking for a file that will be treated as -<span class="emphasis"><em>read only</em></span>. 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. -</p><p> -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. -</p><p> -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. -</p><p> -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. -</p><p> -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. -</p><div class="sect2" title="Example Configuration"><div class="titlepage"><div><div><h3 class="title"><a name="id384333"></a>Example Configuration</h3></div></div></div><p> -In the following section we examine two distinct aspects of Samba locking controls. -</p><div class="sect3" title="Disabling Oplocks"><div class="titlepage"><div><div><h4 class="title"><a name="id384342"></a>Disabling Oplocks</h4></div></div></div><p> -You can disable oplocks on a per-share basis with the following: -</p><p> -</p><table border="0" summary="Simple list" class="simplelist"><tr><td> </td></tr><tr><td><em class="parameter"><code>[acctdata]</code></em></td></tr><tr><td><a class="indexterm" name="id384367"></a><em class="parameter"><code>oplocks = False</code></em></td></tr><tr><td><a class="indexterm" name="id384379"></a><em class="parameter"><code>level2 oplocks = False</code></em></td></tr></table><p> -</p><p> -The default oplock type is Level1. Level2 oplocks are enabled on a per-share basis -in the <code class="filename">smb.conf</code> file. -</p><p> -Alternately, you could disable oplocks on a per-file basis within the share: -</p><p> - </p><table border="0" summary="Simple list" class="simplelist"><tr><td><a class="indexterm" name="id384413"></a><em class="parameter"><code>veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/</code></em></td></tr></table><p> -</p><p> -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. -</p></div><div class="sect3" title="Disabling Kernel Oplocks"><div class="titlepage"><div><div><h4 class="title"><a name="id384432"></a>Disabling Kernel Oplocks</h4></div></div></div><p> -Kernel oplocks is an <code class="filename">smb.conf</code> 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 <code class="filename">smb.conf</code> file. -</p><p> -</p><table border="0" summary="Simple list" class="simplelist"><tr><td><a class="indexterm" name="id384466"></a><em class="parameter"><code>kernel oplocks = yes</code></em></td></tr></table><p> -The default is no. -</p><p> -<span class="emphasis"><em>Veto oplocks</em></span> is an <code class="filename">smb.conf</code> 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 -<code class="filename">smb.conf</code> file as shown in <a class="link" href="locking.html#far1" title="Example 17.1. Share with Some Files Oplocked">“Share with Some Files Oplocked”</a>. -</p><p> -</p><div class="example"><a name="far1"></a><p class="title"><b>Example 17.1. Share with Some Files Oplocked</b></p><div class="example-contents"><table border="0" summary="Simple list" class="simplelist"><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id384535"></a><em class="parameter"><code>veto oplock files = /filename.htm/*.txt/</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[share_name]</code></em></td></tr><tr><td><a class="indexterm" name="id384556"></a><em class="parameter"><code>veto oplock files = /*.exe/filename.ext/</code></em></td></tr></table></div></div><p><br class="example-break"> -</p><p> -<a class="link" href="smb.conf.5.html#OPLOCKBREAKWAITTIME" target="_top">oplock break wait time</a> is an <code class="filename">smb.conf</code> parameter -that adjusts the time interval for Samba to reply to an oplock break request. Samba recommends: -<span class="quote">“<span class="quote">Do not change this parameter unless you have read and understood the Samba oplock code.</span>”</span> -Oplock break wait time can only be configured globally in the <code class="filename">smb.conf</code> file as shown: -</p><p> - </p><table border="0" summary="Simple list" class="simplelist"><tr><td><a class="indexterm" name="id384608"></a><em class="parameter"><code>oplock break wait time = 0 (default)</code></em></td></tr></table><p> -</p><p> -<span class="emphasis"><em>Oplock break contention limit</em></span> is an <code class="filename">smb.conf</code> 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 -<span class="quote">“<span class="quote">Do not change this parameter unless you have read and understood the Samba oplock code.</span>”</span> -Oplock break contention limit can be enabled on a per-share basis, or globally for -the entire server, in the <code class="filename">smb.conf</code> file as shown in <a class="link" href="locking.html#far3" title="Example 17.2. Configuration with Oplock Break Contention Limit">“Configuration with Oplock Break Contention Limit”</a>. -</p><p> -</p><div class="example"><a name="far3"></a><p class="title"><b>Example 17.2. Configuration with Oplock Break Contention Limit</b></p><div class="example-contents"><table border="0" summary="Simple list" class="simplelist"><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id384678"></a><em class="parameter"><code>oplock break contention limit = 2 (default)</code></em></td></tr><tr><td> </td></tr><tr><td><em class="parameter"><code>[share_name]</code></em></td></tr><tr><td><a class="indexterm" name="id384699"></a><em class="parameter"><code>oplock break contention limit = 2 (default)</code></em></td></tr></table></div></div><p><br class="example-break"> -</p></div></div></div><div class="sect1" title="MS Windows Oplocks and Caching Controls"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id384716"></a>MS Windows Oplocks and Caching Controls</h2></div></div></div><p> -There is a known issue when running applications (like Norton Antivirus) 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 -operating system. When a workstation -attempts to access shared data files located on another Windows 2000/XP computer, -the Windows 2000/XP operating system will attempt to increase performance by locking the -files and caching information locally. When this occurs, the application is unable to -properly function, which results in an <span class="quote">“<span class="quote">Access Denied</span>”</span> - error message being displayed during network operations. -</p><p> -All Windows operating systems in the NT family that act as database servers for data files -(meaning that data files are stored there and accessed by other Windows PCs) may need to -have oplocks disabled in order to minimize the risk of data file corruption. -This includes Windows 9x/Me, Windows NT, Windows 200x, and Windows XP. -<sup>[<a name="id384740" href="#ftn.id384740" class="footnote">5</a>]</sup> -</p><p> -If you are using a Windows NT family workstation in place of a server, you must also -disable oplocks on that workstation. For example, if you use a -PC with the Windows NT Workstation operating system instead of Windows NT Server, and you -have data files located on it that are accessed from other Windows PCs, you may need to -disable oplocks on that system. -</p><p> -The major difference is the location in the Windows registry where the values for disabling -oplocks are entered. Instead of the LanManServer location, the LanManWorkstation location -may be used. -</p><p> -You can verify (change or add, if necessary) this registry value using the Windows -Registry Editor. When you change this registry value, you will have to reboot the PC -to ensure that the new setting goes into effect. -</p><p> -The location of the client registry entry for oplocks has changed in -Windows 2000 from the earlier location in Microsoft Windows NT. -</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -Windows 2000 will still respect the EnableOplocks registry value used to disable oplocks -in earlier versions of Windows. -</p></div><p> -You can also deny the granting of oplocks by changing the following registry entries: -</p><p> -</p><pre class="programlisting"> - HKEY_LOCAL_MACHINE\System\ - CurrentControlSet\Services\MRXSmb\Parameters\ - - OplocksDisabled REG_DWORD 0 or 1 - Default: 0 (not disabled) -</pre><p> -</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -The OplocksDisabled registry value configures Windows clients to either request or not -request oplocks on a remote file. To disable oplocks, the value of - OplocksDisabled must be set to 1. -</p></div><p> -</p><pre class="programlisting"> - HKEY_LOCAL_MACHINE\System\ - CurrentControlSet\Services\LanmanServer\Parameters - - EnableOplocks REG_DWORD 0 or 1 - Default: 1 (Enabled by Default) - - EnableOpLockForceClose REG_DWORD 0 or 1 - Default: 0 (Disabled by Default) -</pre><p> -</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -The EnableOplocks value configures Windows-based servers (including Workstations sharing -files) to allow or deny oplocks on local files. -</p></div><p> -To force closure of open oplocks on close or program exit, EnableOpLockForceClose must be set to 1. -</p><p> -An illustration of how Level2 oplocks work follows: -</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - Station 1 opens the file requesting oplock. - </p></li><li class="listitem"><p> - Since no other station has the file open, the server grants station 1 exclusive oplock. - </p></li><li class="listitem"><p> - Station 2 opens the file requesting oplock. - </p></li><li class="listitem"><p> - Since station 1 has not yet written to the file, the server asks station 1 to break - to Level2 oplock. - </p></li><li class="listitem"><p> - Station 1 complies by flushing locally buffered lock information to the server. - </p></li><li class="listitem"><p> - Station 1 informs the server that it has broken to level2 Oplock (alternately, - station 1 could have closed the file). - </p></li><li class="listitem"><p> - The server responds to station 2's open request, granting it Level2 oplock. - Other stations can likewise open the file and obtain Level2 oplock. - </p></li><li class="listitem"><p> - Station 2 (or any station that has the file open) sends a write request SMB. - The server returns the write response. - </p></li><li class="listitem"><p> - The server asks all stations that have the file open to break to none, meaning no - 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. - </p></li></ul></div><div class="sect2" title="Workstation Service Entries"><div class="titlepage"><div><div><h3 class="title"><a name="id384868"></a>Workstation Service Entries</h3></div></div></div><pre class="programlisting"> - \HKEY_LOCAL_MACHINE\System\ - CurrentControlSet\Services\LanmanWorkstation\Parameters - - UseOpportunisticLocking REG_DWORD 0 or 1 - Default: 1 (true) -</pre><p> -This indicates whether the redirector should use oplocks performance -enhancement. This parameter should be disabled only to isolate problems. -</p></div><div class="sect2" title="Server Service Entries"><div class="titlepage"><div><div><h3 class="title"><a name="id384888"></a>Server Service Entries</h3></div></div></div><pre class="programlisting"> - \HKEY_LOCAL_MACHINE\System\ - CurrentControlSet\Services\LanmanServer\Parameters - - EnableOplocks REG_DWORD 0 or 1 - Default: 1 (true) -</pre><p> -This specifies whether the server allows clients to use oplocks on files. Oplocks are a -significant performance enhancement, but have the potential to cause lost cached -data on some networks, particularly WANs. -</p><pre class="programlisting"> - MinLinkThroughput REG_DWORD 0 to infinite bytes per second - Default: 0 -</pre><p> -This specifies the minimum link throughput allowed by the server before it disables -raw I/O and oplocks for this connection. -</p><pre class="programlisting"> - MaxLinkDelay REG_DWORD 0 to 100,000 seconds - Default: 60 -</pre><p> -This specifies the maximum time allowed for a link delay. If delays exceed this number, -the server disables raw I/O and oplocks for this connection. -</p><pre class="programlisting"> - OplockBreakWait REG_DWORD 10 to 180 seconds - Default: 35 -</pre><p> -This 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. -</p></div></div><div class="sect1" title="Persistent Data Corruption"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id384944"></a>Persistent Data Corruption</h2></div></div></div><p> -If you have applied all of the settings discussed in this chapter but data corruption problems -and other symptoms persist, here are some additional things to check out. -</p><p> -We have credible reports from developers that faulty network hardware, such as a single -faulty network card, can cause symptoms similar to read caching and data corruption. -If you see persistent data corruption even after repeated re-indexing, you may have to -rebuild the data files in question. This involves creating a new data file with the -same definition as the file to be rebuilt and transferring the data from the old file -to the new one. There are several known methods for doing this that can be found in -our knowledge base. -</p></div><div class="sect1" title="Common Errors"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id384963"></a>Common Errors</h2></div></div></div><p> -In some sites locking problems surface as soon as a server is installed; in other sites -locking problems may not surface for a long time. Almost without exception, when a locking -problem does surface, it will cause embarrassment and potential data corruption. -</p><p> -Over the past few years there have been a number of complaints on the Samba mailing lists -that have claimed that Samba caused data corruption. Three causes have been identified -so far: -</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - Incorrect configuration of oplocks (incompatible with the application - being used). This is a common problem even where MS Windows NT4 or MS Windows - 200x-based servers were in use. It is imperative that the software application vendors' - instructions for configuration of file locking should be followed. If in doubt, - disable oplocks on both the server and the client. Disabling of all forms of file - caching on the MS Windows client may be necessary also. - </p></li><li class="listitem"><p> - Defective network cards, cables, or hubs/switches. This is generally a more - prevalent factor with low-cost networking hardware, although occasionally there - have also been problems with incompatibilities in more up-market hardware. - </p></li><li class="listitem"><p> - There have been some random reports of Samba log files being written over data - files. This has been reported by very few sites (about five in the past 3 years) - and all attempts to reproduce the problem have failed. The Samba Team has been - unable to catch this happening and thus unable to isolate any particular - cause. Considering the millions of systems that use Samba, for the sites that have - been affected by this as well as for the Samba Team, this is a frustrating and - vexing challenge. If you see this type of thing happening, please create a bug - report on Samba <a class="ulink" href="https://bugzilla.samba.org" target="_top">Bugzilla</a> without delay. - Make sure that you give as much information as you possibly can to help isolate the - cause and to allow replication of the problem (an essential step in problem isolation and correction). - </p></li></ul></div><div class="sect2" title="locking.tdb Error Messages"><div class="titlepage"><div><div><h3 class="title"><a name="id385014"></a>locking.tdb Error Messages</h3></div></div></div><p> - <span class="quote">“<span class="quote"> - We are seeing lots of errors in the Samba logs, like: - </span>”</span> -</p><pre class="programlisting"> -tdb(/usr/local/samba_2.2.7/var/locks/locking.tdb): rec_read bad magic - 0x4d6f4b61 at offset=36116 -</pre><p> - - <span class="quote">“<span class="quote"> - What do these mean? - </span>”</span> - </p><p> - This error indicates a corrupted tdb. Stop all instances of smbd, delete locking.tdb, and restart smbd. - </p></div><div class="sect2" title="Problems Saving Files in MS Office on Windows XP"><div class="titlepage"><div><div><h3 class="title"><a name="id385042"></a>Problems Saving Files in MS Office on Windows XP</h3></div></div></div><a class="indexterm" name="id385048"></a><p>This is a bug in Windows XP. More information can be - found in <a class="ulink" href="http://support.microsoft.com/?id=812937" target="_top">Microsoft Knowledge Base article 812937</a></p>. - - </div><div class="sect2" title="Long Delays Deleting Files over Network with XP SP1"><div class="titlepage"><div><div><h3 class="title"><a name="id385065"></a>Long Delays Deleting Files over Network with XP SP1</h3></div></div></div><p><span class="quote">“<span class="quote">It sometimes takes approximately 35 seconds to delete files over the network after XP SP1 has been applied.</span>”</span></p><a class="indexterm" name="id385076"></a><p>This is a bug in Windows XP. More information can be found in <a class="ulink" href="http://support.microsoft.com/?id=811492" target="_top"> - Microsoft Knowledge Base article 811492</a></p>. - </div></div><div class="sect1" title="Additional Reading"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id385094"></a>Additional Reading</h2></div></div></div><p> -You may want to check for an updated documentation regarding file and record locking issues on the Microsoft -<a class="ulink" href="http://support.microsoft.com/" target="_top">Support</a> web site. Additionally, search for the word -<code class="literal">locking</code> on the Samba <a class="ulink" href="http://www.samba.org/" target="_top">web</a> site. -</p><p> -Section of the Microsoft MSDN Library on opportunistic locking: -</p><p> -<a class="indexterm" name="id385128"></a> -Microsoft Knowledge Base, <span class="quote">“<span class="quote">Maintaining Transactional Integrity with OPLOCKS</span>”</span>, -Microsoft Corporation, April 1999, <a class="ulink" href="http://support.microsoft.com/?id=224992" target="_top">Microsoft -KB Article 224992</a>. -</p><p> -<a class="indexterm" name="id385151"></a> -Microsoft Knowledge Base, <span class="quote">“<span class="quote">Configuring Opportunistic Locking in Windows 2000</span>”</span>, -Microsoft Corporation, April 2001 <a class="ulink" href="http://support.microsoft.com/?id=296264" target="_top">Microsoft KB Article 296264</a>. -</p><p> -<a class="indexterm" name="id385173"></a> -Microsoft Knowledge Base, <span class="quote">“<span class="quote">PC Ext: Explanation of Opportunistic Locking on Windows NT</span>”</span>, -Microsoft Corporation, April 1995 <a class="ulink" href="http://support.microsoft.com/?id=129202" target="_top">Microsoft -KB Article 129202</a>. -</p></div><div class="footnotes"><br><hr width="100" align="left"><div class="footnote"><p><sup>[<a name="ftn.id384740" href="#id384740" class="para">5</a>] </sup>Microsoft has documented this in Knowledge Base article 300216.</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="AccessControls.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="securing-samba.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 16. File, Directory, and Share Access Controls </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 18. Securing Samba</td></tr></table></div></body></html> |