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

[Jeremy Allison]

On Tue, Jan 07, 2014 at 11:33:58AM -0700, Nick Couchman wrote:
> >> 
> >> 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 th
>  e 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.

smbd uses the dev_t/ino_t pair as an index
into our file sharing/locking databases.

Are /storage/doc_checkout/usera/document1.doc
and /storage/doc_checkout/userb/document1.doc
actually the same file on the file system ?

If not then I'm at a loss as to how they
can conflict at all, unless you're getting
a locking/sharing violation from the Windows
client redirector.

Do you ever see an error message coming back
from Samba in the wireshark trace ?

Jeremy