[Samba] File Locking on Samba & Terminal Server 2008R2

Nick Couchman Nick.Couchman at seakr.com
Tue Jan 7 11:33:58 MST 2014


>> 
>> Anyone have any solutions/suggestions for this problem, since MS dropped 
> that particular registry fix?
> 
> I don't know of *any* existing bugs in Samba's
> handling of file locking - whether over a multi-user
> connection or not.
> 
> Can you point to a *specific* example of what
> you consider a file locking bug please ?
> 
> Jeremy.

I don't know whether to consider it a bug or not...bear with me while I try to describe the situation...

We have a document management system (DMS) where all of our documents are stored and users have either an HTTP interface or a .NET application (that uses HTTP) to download the files from the DMS to the system for viewing.  The DMS allows us to specify what directory these are saved to - for various reasons we're saving them to a Samba server.  The Samba server (3.6.18 on Solaris) has a per-user share defined:

[doc_checkout]
        path = /storage/doc_checkout/%U
        comment = IFS Shared Document Checkout Space
        force create mode = 0200
        read only = No
        inherit permissions = yes
        inherit acls = yes
        wide links = yes
        map archive = no
        map readonly = no
        vfs objects = zfsacl
        nfs4:mode = special
        nfs4:acedup = merge
        zfsacl:acesort = dontcare
        preexec = /storage/doc_checkout/mkdoc.sh %U
        postexec = /storage/doc_checkout/cleandoc.sh %U
        veto files = /mkdoc.sh/cleandoc.sh/*.lnk/autorun.inf/
        csc policy = disable
        guest ok = no

In certain situations, multiple users on the same terminal server try to view (or check out to edit) the same document from the DMS.  Let's say the document is document1.doc, and usera and userb are the two users trying to open the document.  usera downloads document1.doc, which goes to filesystem as /storage/doc_checkout/usera/document1.doc, but is opened on the file server as \\server\doc_checkout\document1.doc.  userb downloads the same document, which goes to the filesystem as /storage/doc_checkout/userb/document1.doc, but is opened on the file server as \\server\doc_checkout\document1.doc.  In this scenario, one or the other of the users (whomever opened it second/third/etc.) will get an error that "file document1.doc is already in use by usera."  I'm guessing that, because terminal server aggregates the users under a single connection, and because Samba has a single PID opened, and either the document name or the SMB file path (\\server\doc_checkout\document1.doc) is the same, Samba or Windows (or both) believe that the file is already locked even though, at the filesystem level, the files are completely different and should have different locks.

This scenario looked very similar to ones described several years ago that were fixed by using the "MultiUserEnabled" registry tweak in Windows, which is what I've been trying to chase down, but apparently does not exist in the most recent versions of Windows.  I suppose I ought to try giving up on the fancy per-user share and just have \\server\doc_checkout point to /storage/doc_checkout, and then have the application use the username to figure out the rest of the path, but it isn't quite as simple or elegant to implement that way, from the application perspective.

-Nick



--------
This e-mail may contain SEAKR Engineering (SEAKR) Confidential and Proprietary Information.  If this message is not intended for you, you are strictly prohibited from using this message, its contents or attachments in any way.  If you have received this message in error, please delete the message from your mailbox.  This e-mail may contain export-controlled material and should be handled accordingly.


More information about the samba mailing list