Eric Chris Garrison wrote:
> So, I think it's some kind of file locking issue, possibly due to
> disconnecting and reconnecting to another server due to round-robin, but
> I'm not sure that's the actual case, it's just a theory at this point. The
> users have claimed to map to a specific machine and then get the error
> anyway, but I haven't been able to reproduce that so far.
> 
> We get a lot of errors in the logs that say, "kernel: afs: byte-range
> lock/unlock ignored; make sure no one else is running this program."
> That's probably from openafs-client since it's kernel-level where smbd
> isn't.  Not sure if that's related. The intermittent nature of the problem
> makes it especially frustrating.  Samba logs don't even indicate a problem
> at the time of the error message, so I guess it's all on the client's side.

Eric:

Using a cluster of Samba servers as a front-end to AFS is not going to
be safe in my opinion.  Samba has to claim to support mandatory locking
semantics which AFS does not support.  Even if Samba server A issues a
lock that was granted from the AFS file server, there is nothing to
prevent Samba server B to perform a store operation against that locked
file.  The various Samba servers cannot perform distributed file locking.

The OpenAFS Windows client goes to great lengths to implement file
locking in a safe manner.  It isn't easy to get correct and I'm not sure
if the Samba file locking code is AFS aware enough to take the necessary
steps.

The "xxx is read only" error is a bit weird though.  I would expect a
sharing violation error not a "is read only" error.  On IRC yesterday
someone was asking about a volume that temporarily appeared to be read
only.  A restart of the cache manager caused the problem to go away so
perhaps the issue that you are seeing is related.

If you can identify a user at the time the problem occurs it would be
useful to obtain a tcp dump of the smb traffic to the samba server as
well as the afs traffic to the afs file server.  At least then you would
know what was actually being requested and what is failing.

Jeffrey Altman

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to