samba - Jun 2015 - Antw: Re: STATUS_SHARE_VIOLATION when Read while Write on GPFS + CTDB

Hello Volker,

I was able to get those level 10 logs - spitted by machine. 
Unfortunately I don't know how attachments behave - Groupwise seems not to
be happy with those - so I try the redundant way:

Here are the logfiles for this event (only one machine, one try):
https://www.bitmammut.de/WDR/log.klnmszap32

In this file there are about 3 occurrences of the
"NT_STATUS_SHARING_VIOLATION".
The first is in line 2661.

Also I'll try to set the share-modes to "no" and look how it
behaves.

Thanks that you want to analyze this. I hope that we would find a solution.

Regards from Cologne,
Alex




Westdeutscher Rundfunk
IT-Services
Rechenzentrum
An der Rechtschule 4
Archivhaus 1145
50667 K?ln
Telefon +49 (0)221 220 6496

alexander.gast at wdr.de
www.wdr.de


 


Bitte denken Sie an die Umwelt, bevor Sie diese E-Mail drucken.
>>> 
Von: Volker Lendecke <Volker.Lendecke at SerNet.DE>
An:Alexander Gast <Alexander.Gast at WDR.DE>
CC:<samba at lists.samba.org>
Datum: 04.06.2015 08:47
Betreff: Re: [Samba] STATUS_SHARE_VIOLATION when Read while Write on GPFS + CTDB
Hello!

We indeed need debug level 10 logs of smbd. But I bet that you're running
into an incompatibility between SMB and GPFS share modes. Those don't
match 100%, so turning off gpfs:sharemodes might be worth a try. Of
course, this means that you lose interop share modes.

I'd be happy to analyze this further and assist you in making a proper
GPFS query out of this if needed.

With best regards,

Volker Lendecke

On Thu, May 21, 2015 at 03:40:58PM +0200, Alexander Gast
wrote:
> Hi,
>  
> in the following scenario I've got the Problem of
"STATUS_SHARE_VIOLATION".
>  
> Client A (with User 1)  copies a file to share X. (with: DENY_NONE 
0x120196    WRONLY     NONE)
> Client B (with User 1) reads this file from share X (with: DENY_NONE 
0x120089    RDONLY     NONE)
>  
> Now Client C (with User 1) wants also to read this file from share X and
gets the STATUS_SHARE_VIOLATION.
> In the same scenario with Client D (and User 2) instead of Client A
everything seems to work brilliantly.
>  
>  
> Clients A to C are Windows Server 2008 R2 - Client D is a RHEL6.X.
>  
> The Samba-Server is a CTDB with 2 nodes. 
> Samba version 4.1.11-SerNet-RedHat-8.el6 (will be updated to 4.1.17
tomorrow)
> CTDB version: 1.0.114.8-1 (will be updated to 1.0.114.9-1 tomorrow)
> The FIle-System the Share is on is GPFS in Version 3.5.0.23
> 
> The relevant File-System parmateres are -D and -k = nfs4.
> 
> Other GPFS-Samba-Parameters as
> 
> cifsBypassShareLocksOnRename
> syncSambaMetadataOps
> cifsBypassTraversalChecking
> allowSambaCaseInsensitiveLookup
> 
> aren't set.
>  
>  
>  
> smb.conf: http://pastebin.com/B5RCAGfv
> 
> share definition for share x:  http://pastebin.com/YNtCR9Wb
> 
> 
> I tried to get log files with this error, but currently the persons I need
to reproduce this error aren't available so I will deliver log files, if
necessary, later on.
> Older log files aren't available because of their small size and much
activity.
> 
> 
> Is there any parameter / option / switch to solve this problem? Or is it
just the way the Client C tires to achieve the lock on this file?
> 
> Thanks and best regards from Cologne,
> Alex
> 
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
-- 
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
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

On Fri, Jun 05, 2015 at 11:09:17AM +0200, Alexander Gast
wrote:
> I was able to get those level 10 logs - spitted by machine. 
> Unfortunately I don't know how attachments behave - Groupwise seems not
to be happy with those - so I try the redundant way:
> 
> Here are the logfiles for this event (only one machine, one try):
> https://www.bitmammut.de/WDR/log.klnmszap32
> 
> In this file there are about 3 occurrences of the
"NT_STATUS_SHARING_VIOLATION".
> The first is in line 2661.
> 
> Also I'll try to set the share-modes to "no" and look how it
behaves.
> 
> Thanks that you want to analyze this. I hope that we would find a solution.
Those sharing violations are real, that works as designed
for SMB. Applications can request to open files exclusively,
and that is what happens here. See for example

[2015/06/05 09:49:34.398654, 10, pid=64463, effective(1901, 1901), real(1901,
0)] ../source3/smbd/open.c:1082(share_conflict)
  share_conflict: check 1 conflict am = 0x120196, right = 0x6, sa = 0x1, share =
0x2
[2015/06/05 09:49:34.398734, 10, pid=64463, effective(1901, 1901), real(1901,
0), class=locking]
../source3/locking/locking.c:652(share_mode_stale_pid) PID 0:27594 (index 0 out
of 1) still exists

Those messages are from SMB only, gpfs:sharemodes=no will
not help here. You should look into your applications to see
why they request exclusive access to files.

With best regards,

Volker Lendecke

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

Good morning,

first of all: Thanks so far.
I've forwarded your mail to the vendor of this software an one of them
assures that their modules aren't requesting full access to those
files.

His suggestion is to set the following parameters to the share:

oplocks = no
blocking locks = no
fake oplocks = no
locking = no
strict locking = no
shares modes = no


Some of them are already set, others are "no" as default.
The only difference seems to be the "locking = no" parameter.
I'm really carefully setting this parameter because of the possibility
of data corruption. Is it wise to set this parameter?
(In the tutorial at the wiki it's explicitly set to "yes")

The whole oplocks, locking and sharemodes configuration is confusing.
The IBM recommendation from Michael Jahn is the following:

oplocks = yes (isn't explicitly set, so I assume it's default)
kernel oplocks = no
level2 oplocks = yes
strict locking = yes
posix locking = no
gpfs:sharemodes = yes
gpfs:leases = yes
gpfs:dfreequota = yes
gpfs:prealloc = yes


It seems that there are many possibilities of configure the whole
locking.
How can I determine which configuration is best for me?

In general the files are created / uploaded via SMB, and then some
other tools access this video-file to create a lower resolution
video-file and some "keyframe"-images. Those other tools are in some
cases SMB clients, in other cases GPFS client machines and the files are
gernerally accessed in "while" mode - to achieve nearly "real
time
prcoessing".

I'll test some variations of the config files tomorrow morning - but it
would be very helpful to get a "best practice" config.

I really hope to be able to close this topic with a solution that
smoothes the vendors / companies.

Thanks for the help till this point and regards,
Alex Gast


-- 
Westdeutscher Rundfunk
IT-Services
Rechenzentrum
An der Rechtschule 4
Archivhaus 1145
50667 K?ln
Telefon +49 (0)221 220 6496

alexander.gast at wdr.de
www.wdr.de

>>> Volker Lendecke <Volker.Lendecke at SerNet.DE> schrieb am
05.06.2015
um 11:26:
> 
> Those sharing violations are real, that works as designed
> for SMB. Applications can request to open files exclusively,
> and that is what happens here. See for example
> 
> [2015/06/05 09:49:34.398654, 10, pid=64463, effective(1901, 1901), 
> real(1901, 0)] ../source3/smbd/open.c:1082(share_conflict)
>   share_conflict: check 1 conflict am = 0x120196, right = 0x6, sa 0x1, 
> share = 0x2
> [2015/06/05 09:49:34.398734, 10, pid=64463, effective(1901, 1901), 
> real(1901, 0), class=locking]
> ../source3/locking/locking.c:652(share_mode_stale_pid) PID 0:27594
(index 0 
> out of 1) still exists
> 
> Those messages are from SMB only, gpfs:sharemodes=no will
> not help here. You should look into your applications to see
> why they request exclusive access to files.
> 
> With best regards,
> 
> Volker Lendecke