Alexander Gast
2015-May-21 13:40 UTC
[Samba] STATUS_SHARE_VIOLATION when Read while Write on GPFS + CTDB
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
Volker Lendecke
2015-Jun-04 06:45 UTC
[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
Alexander Gast
2015-Jun-05 09:09 UTC
[Samba] 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
Seemingly Similar Threads
- STATUS_SHARE_VIOLATION when Read while Write on GPFS + CTDB
- Antw: Re: STATUS_SHARE_VIOLATION when Read while Write on GPFS + CTDB
- STATUS_SHARE_VIOLATION when Read while Write on GPFS + CTDB
- 3.0.25 *breaks* stand alone server, 3.0.24 works fine
- Saving files with MS Word to samba3 server is very slow!