Treating share modes as advisory when set by Mac clients

[Brian Campbell]

On Mon, Mar 12, 2012 at 3:59 PM, Volker Lendecke
<Volker.Lendecke at sernet.de>wrote:

> On Mon, Mar 12, 2012 at 03:27:01PM -0400, Brian Campbell wrote:
> > I work on network attached storage for video editing. Our customers use
> > both Mac and Windows workstations, and on the Mac, they generally use
> > Thursby Software's DAVE as a client, as it works much better than the
> > built-in smbfs on Mac OS X.
> >
> > On Mac OS X, when opening a file, you can request a shared or exclusive
> > lock on the file using the O_SHLOCK or O_EXLOCK flags in the open() call.
> > On local filesystems, these are implemented as locks with flock()
> semantics.
> >
> > Thursby recently added support in DAVE to implement these flags using
> share
> > modes (DENY_WRITE/DENY_ALL). They apparently did this because Microsoft
> > Word depends on these locks working, and was getting confused when two
> > people could edit the same file at the same time. This also appears to be
> > how smbfs on Mac OS X implements these open() flags.
> >
> > This has caused a problem for our customers using Final Cut (and possibly
> > some other video editing software). When Final Cut writes files out in
> > certain situations (renders, and log and transfer), it opens the file
> with
> > the O_EXLOCK flag, and holds the file open with that exclusive lock even
> > after it's done writing, until you close out the entire project. Locally,
> > that doesn't cause any problems, since the lock is advisory and most
> > software that needs to read the file doesn't try to obtain any locks on
> the
> > file.
>
> My initial reaction is that it is a bug in Final Cut, but
> that does not help you much now.


Yeah, this seems like a bug in Final Cut to me. But Apple has killed Final
Cut Pro 7 in favor of Final Cut Pro X, which is a completely different
product which our customers don't use. We still need to support Final Cut
Pro 7, even if Apple no longer does.


> Does that behave in any way
> differently if you store it on Windows servers? I can't
> imagine that Final Cut can't be used when storing files
> there. If Samba behaves differently, then we need
> comparative network traces.
>

I have not tried this on Windows. I would expect it to work the same; I can
try to find a Windows server to test against.

In general, we try to support setups that aren't officially supported by
the non-linear editors. For example, Avid generally refuses to write to
network drives, but we convince it that it is writing to a local disk in
order to get it to work. I believe that Final Cut also expects to be
writing to a local disk or SAN, but one of our differentiating features is
that we make NAS work for video editing which can make it a lot easier to
quickly and seamlessly share media.


> As an immediate relief, you might want to take a look at
> "share modes = no". This is a per-share parameter which
> makes Samba not use and respect share modes at all.


As Jeremy mentions, this feature has bit-rotted, and when I did a quick
test of it, it didn't fix the problem at all. We turned on "share modes =
no" for a share, wrote to it with Final Cut, and when we tried opening it
on a Windows machine with Final Cut open, it failed to be open, and
smbstatus still reported that the file had share mode DENY_ALL.


> You can
> play similar tricks as mentioned in
> https://wiki.samba.org/index.php/Client_specific_Log to
> restrict the dangerous use to specific clients and specific
> share.


As a separate issue, in the past we've tried using similar tricks with %a
to distinguish Mac from Windows clients. The problem is, %a reports "Vista"
for DAVE, Mac OS X's smbfs, and Windows 7. It looks like set_remote_arch()
in lib/util.c has an option for OSX, but reply_negprot() in smbd/negprot.c
never uses that (and looks like a real hack based on the particular list of
protocols the client reports support for).

Would it be reasonable to add support for detecting Mac OS X and setting
the remote arch to support this kind of trick, so that our customers don't
have to maintain lists of which IPs run Mac OS X and which run Windows? I
don't think that reply_negprot() is the right place to set this; it looks
like much better information shows up in the NativeOS and NativeLanMan
fields of the SESSION_SETUP_ANDX message.

-- Brian


> With best regards,
>
> Volker
>
> --
> SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
> phone: +49-551-370000-0, fax: +49-551-370000-9
> AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
> http://www.sernet.de, mailto:kontakt at sernet.de
>