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

[Nick Couchman]

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

No, they are not the same on the filesystem - they are different inodes.

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

That wouldn't surprise me too much.

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

I hadn't gone that deep (packet captures) in dealing with this, yet...I'll add it to my list of things to try and see what happens.

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