Subject: Locking propigation probelm samba to netatalk & netatalk to samba

From: Mike Fedyk <[email-masked]>
Date: Wed, 18 Oct 2000 01:12:00 -0700

Take a look at this output from lsof:
smbd    11490        0    8u   REG    3,3 55296 1136647 Maintenanc.fp5
afpd    31010        0    2u   REG    3,3  3207 1136655 auction - envelope.rtf
afpd    31010        0    5u   REG    3,3  4156 1136656 Word Work File L 1
afpd    31010        0    8u   REG    3,3 55296 1136647 Maintenanc.fp5
smbd    31386        0    9u   REG    3,3  4156 1136656 Word Work File L 1

This is showing a rtf file open in word on mac and windows, both writable.  I am
able to save on one while the other has the same file open.  The information
isn't transferring between samba and netatalk.  Locking works within samba and
within netatalk, meaning mac-mac locking conflicts are reported and smb-smb
locking conflicts are too.  But if you have the same file open in windows and
mac, there isn't any warning!

I've turned off oplocks, level 2 oplocks, kernel oplocks and turned on strict
locking.  Same difference.

This is a Debian 2.2 box running 2.2.17  I am attaching my netatalk and samba
configs.

Please help!

I'm getting corrupted files because of this. :(
-- 

Mike Fedyk                   "They that can give up essential liberty
Information Systems           to obtain a little temporary safety
Match Mail Productions Inc.   deserve neither liberty nor safety."
[email-masked]                                   Ben Franklin

---

From: Mike Brodbelt <[email-masked]>
Date: Wed, 18 Oct 2000 11:22:14 +0100

> mac, there isn't any warning!

As I understand it, Samba 2.0.7 implements oplocks for windows clients,
but those locks do not propagate to the underlying Unix system. This can
cause locking problems with Unix apps and windows apps accessing the
same files, which is essentially what you are seeing. Neither Netatalk
or Samba have any idea that the file is locked by the other.

One of the new features of Samba 2.2 is the mapping of oplocks to POSIX
locks. From the release notes:-

========================================================
Rewritten internal locking semantics for more robustness.
This alpha supports full 64 bit locking semantics on all
(even 32 bit) platforms. SMB locks are mapped onto POSIX
locks (32 bit or 64 bit) as the underlying system allows.
========================================================

This should mean that, assuming your undelying system supports POSIX
locks, then Samba will have done its bit with regard to this. You still
need Netatalk to honour the POSIX locks, and also to map Mac locks to
POSIX locks to be able to use this sort of setup with impunity. I have
no idea what the state of this sort of thing is within Netatalk - maybe
someone on the Netatalk list will know this...

I'd suggest that you make Mac and Windows users use different shares for
write access. Allow both groups read-only access to the others shares,
and if they need to edit a file, they can make a copy. Otherwise, you're
probably in for large amounts of pain....

HTH

Mike.

---

From: Mike Fedyk <[email-masked]>
Date: Wed, 18 Oct 2000 11:35:26 -0700

> locks. From the release notes:-

I have disabled oplocks, and kernel oplocks.  Oplocks aren't the problem, and
they work perfectly, even level 2 oplocks in a smb only setup.

It looks like older versions of netatalk used flock, but newer versions may be
using fcntl.  This makes me think that the underlying unix will see the lock.

I've also read that samba needs fcntl locks to work properly.  Why don't they
see each other's locks if both are using fcntl?

> probably in for large amounts of pain....

This would be a major pain because we have two departments that are slowly
replacing macs with  NT and they need to work on the same sets of files with
working locks.  

If this can't happen, I'll look into smb from the mac, and as a last resort,
I've tested this under NT and the locking works between smb and afp, although
it'll be slower, that's better than data corruption.  That would be bad, because
I'm trying to move all of our file serving from mac (completed) and NT over to
linux.

--