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

[erpo41 at gmail.com]

Here is a document recommending the MultiUserEnabled trick on windows
server 2008 R2 and explaining how to set it up:
http://support.citrix.com/article/CTX131577

It may solve your problem, but I'm not convinced I really understand the
underlying issue yet. The documentation for Microsoft KB 913835 kind of
makes it sound like the redirector on the terminal server maintains a
single connection to the server for multiple users, but IIRC the samba
documentation says that authentication is done one time at the beginning of
the connection. If that's the case, it's not clear to me how Microsoft
intends that ACLs be enforced. Suppose the server has a file at
\\FileServer\sharename\file.dat that User_A should be able to read, but
User_B shouldn't. If User_A logs into TerminalServer first and opens a
connection to \\FileServer\sharename, what is to prevent User_B from
logging into TerminalServer and reading \\FileServer\sharename\file.dat
through User_A's connection? What if User_B had logged in first and opened
the connection, and then User_A tried to read file.dat? Would FileServer
refuse the read request because the connection had been opened using
User_B's credentials?

Anyway, good luck!

Eric


On Jan 7, 2014 11:34 AM, "Nick Couchman" <Nick.Couchman at seakr.com> 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.
>
> -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.
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>