Re: [Samba] having issues with shares
That seems to have worked. Thanks for that. On Tuesday, February 12, 2013 09:32 AM CST, Edward Ashley wrote: > Hi, > Okay could you please try: > > share modes = no > locking = no > > on your share. > Thanks > Ned > > > On 12 February 2013 15:06, Donny Brooks wrote: > > > Same thing on both attempts. Here is the veto oplock try: > > > > Locked files: > > Pid UidDenyMode Access R/WOplock > > SharePath Name Time > > > > -- > > 176601258 DENY_NONE 0x20089 RDONLY NONE > > /samba/gis MARIS608/Archaeological_Data.gdb/a0027.gdbtable Tue Feb > > 12 08:55:08 2013 > > 176611149 DENY_NONE 0x20089 RDONLY NONE > > /samba/gis MARIS608/Archaeological_Data.gdb/a0027.gdbtable Tue Feb > > 12 08:55:25 2013 > > 176611149 DENY_WRITE 0x3019f RDWR NONE > > /samba/gis > > MARIS608/Archaeological_Data.gdb/_gdb.SEARCHROOM3.4972.5268.sr.lock Tue > > Feb 12 08:55:13 2013 > > 176601258 DENY_WRITE 0x3019f RDWR NONE > > /samba/gis > > MARIS608/Archaeological_Data.gdb/Survey_Point.GIS.6216.5276.sr.lock Tue > > Feb 12 08:55:08 2013 > > 176611149 DENY_WRITE 0x3019f RDWR NONE > > /samba/gis > > MARIS608/Archaeological_Data.gdb/Site_Poly.SEARCHROOM3.4972.5268.sr.lock > > Tue Feb 12 08:55:24 2013 > > 176611149 DENY_WRITE 0x3019f RDWR NONE > > /samba/gis > > MARIS608/Archaeological_Data.gdb/Survey_Poly.SEARCHROOM3.4972.5268.sr.lock > > Tue Feb 12 08:55:24 2013 > > 176601258 DENY_NONE 0x20089 RDONLY NONE > > /samba/gis MARIS608/Archaeological_Data.gdb/a0028.gdbtablx Tue Feb > > 12 08:55:09 2013 > > 176611149 DENY_NONE 0x20089 RDONLY NONE > > /samba/gis MARIS608/Archaeological_Data.gdb/a0028.gdbtablx Tue Feb > > 12 08:55:24 2013 > > 176601258 DENY_NONE 0x20089 RDONLY NONE > > /samba/gis MARIS608/Archaeological_Data.gdb/a0028.gdbtable Tue Feb > > 12 08:55:09 2013 > > 176611149 DENY_NONE 0x20089 RDONLY NONE > > /samba/gis MARIS608/Archaeological_Data.gdb/a0028.gdbtable Tue Feb > > 12 08:55:24 2013 > > 176601258 DENY_WRITE 0x3019f RDWR NONE > > /samba/gis MARIS608/Archaeological_Data.gdb/Survey_Poly.ed.lock Tue Feb > > 12 08:55:17 2013 > > 176601258 DENY_WRITE 0x3019f RDWR NONE > > /samba/gis MARIS608/Archaeological_Data.gdb/Survey_Line.ed.lock Tue Feb > > 12 08:55:17 2013 > > 176601258 DENY_NONE 0x20089 RDONLY NONE > > /samba/gis MARIS608/Archaeological_Data.gdb/a0029.gdbtable Tue Feb > > 12 08:55:09 2013 > > 176611149 DENY_NONE 0x20089 RDONLY NONE > > /samba/gis MARIS608/Archaeological_Data.gdb/a0029.gdbtable Tue Feb > > 12 08:55:24 2013 > > 176611149 DENY_WRITE 0x3019f RDWR NONE > > /samba/gis > > MARIS608/Archaeological_Data.gdb/Site_Poly.SEARCHROOM3.4972.rd.lock Tue > > Feb 12 08:55:35 2013 > > 176601258 DENY_NONE 0x20089 RDONLY NONE > > /samba/gis MARIS608/Archaeological_Data.gdb/a0029.gdbtablx Tue Feb > > 12 08:55:09 2013 > > 176611149 DENY_NONE 0x20089 RDONLY NONE > > /samba/gis MARIS608/Archaeological_Data.gdb/a0029.gdbtablx Tue Feb > > 12 08:55:24 2013 > > 176601258 DENY_WRITE 0x3019f RDWR NONE > > /samba/gis > > MARIS608/Archaeological_Data.gdb/Site_Poly.GIS.6216.5276.sr.lock Tue Feb > > 12 08:55:08 2013 > > 176611149 DENY_WRITE 0x3019f RDWR NONE > > /samba/gis > > MARIS608/Archaeological_Data.gdb/Survey_Line.SEARCHROOM3.4972.5268.sr.lock > > Tue Feb 12 08:55:24 2013 > > 176601258 DENY_NONE 0x20089 RDONLY NONE > > /samba/gis MARIS608/Archaeological_Data.gdb/a0026.gdbtable Tue Feb > > 12 08:55:08 2013 > > 176611149 DENY_NONE 0x20089 RDONLY NONE > > /samba/gis MARIS608/Archaeological_Data.gdb/a0026.gdbtable Tue Feb > > 12 08:55:25 2013 > > 176601258 DENY_WRITE 0x3019f RDWR NONE > > /samba/gis > > MARIS608/Archaeological_Data.gdb/Survey_Poly.GIS.6216.5276.sr.lock Tue > > Feb 12 08:55:08 2013 > > 176611149 DENY_WRITE 0x3019f RDWR NONE > > /samba/gis > > MARIS608/Archaeological_Data.gdb/Site_Point.SEARCHROOM3.4972.5268.sr.lock > > Tue Feb 12 08:55:24 2013 > > 176601258 DENY_NONE 0x20089 RDONLY NONE > > /samba/gis MARIS608/Archaeological_Data.gdb/a0027.gdbtablx Tue Feb > > 12 08:55:08 2013 > > 176611149 DENY_NONE 0x20089 RDONLY NONE > > /samba/gis MARIS608/Archaeological_Data.gdb/a0027.gdbtablx Tue Feb > > 12 08:55:25 2013 > > 176601258 DENY_NONE 0x20089 RDONLY NONE > >
Re: [Samba] having issues with shares
Hi, Okay could you please try: share modes = no locking = no on your share. Thanks Ned On 12 February 2013 15:06, Donny Brooks wrote: > Same thing on both attempts. Here is the veto oplock try: > > Locked files: > Pid UidDenyMode Access R/WOplock > SharePath Name Time > > -- > 176601258 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0027.gdbtable Tue Feb > 12 08:55:08 2013 > 176611149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0027.gdbtable Tue Feb > 12 08:55:25 2013 > 176611149 DENY_WRITE 0x3019f RDWR NONE > /samba/gis > MARIS608/Archaeological_Data.gdb/_gdb.SEARCHROOM3.4972.5268.sr.lock Tue > Feb 12 08:55:13 2013 > 176601258 DENY_WRITE 0x3019f RDWR NONE > /samba/gis > MARIS608/Archaeological_Data.gdb/Survey_Point.GIS.6216.5276.sr.lock Tue > Feb 12 08:55:08 2013 > 176611149 DENY_WRITE 0x3019f RDWR NONE > /samba/gis > MARIS608/Archaeological_Data.gdb/Site_Poly.SEARCHROOM3.4972.5268.sr.lock > Tue Feb 12 08:55:24 2013 > 176611149 DENY_WRITE 0x3019f RDWR NONE > /samba/gis > MARIS608/Archaeological_Data.gdb/Survey_Poly.SEARCHROOM3.4972.5268.sr.lock > Tue Feb 12 08:55:24 2013 > 176601258 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0028.gdbtablx Tue Feb > 12 08:55:09 2013 > 176611149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0028.gdbtablx Tue Feb > 12 08:55:24 2013 > 176601258 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0028.gdbtable Tue Feb > 12 08:55:09 2013 > 176611149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0028.gdbtable Tue Feb > 12 08:55:24 2013 > 176601258 DENY_WRITE 0x3019f RDWR NONE > /samba/gis MARIS608/Archaeological_Data.gdb/Survey_Poly.ed.lock Tue Feb > 12 08:55:17 2013 > 176601258 DENY_WRITE 0x3019f RDWR NONE > /samba/gis MARIS608/Archaeological_Data.gdb/Survey_Line.ed.lock Tue Feb > 12 08:55:17 2013 > 176601258 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0029.gdbtable Tue Feb > 12 08:55:09 2013 > 176611149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0029.gdbtable Tue Feb > 12 08:55:24 2013 > 176611149 DENY_WRITE 0x3019f RDWR NONE > /samba/gis > MARIS608/Archaeological_Data.gdb/Site_Poly.SEARCHROOM3.4972.rd.lock Tue > Feb 12 08:55:35 2013 > 176601258 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0029.gdbtablx Tue Feb > 12 08:55:09 2013 > 176611149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0029.gdbtablx Tue Feb > 12 08:55:24 2013 > 176601258 DENY_WRITE 0x3019f RDWR NONE > /samba/gis > MARIS608/Archaeological_Data.gdb/Site_Poly.GIS.6216.5276.sr.lock Tue Feb > 12 08:55:08 2013 > 176611149 DENY_WRITE 0x3019f RDWR NONE > /samba/gis > MARIS608/Archaeological_Data.gdb/Survey_Line.SEARCHROOM3.4972.5268.sr.lock > Tue Feb 12 08:55:24 2013 > 176601258 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0026.gdbtable Tue Feb > 12 08:55:08 2013 > 176611149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0026.gdbtable Tue Feb > 12 08:55:25 2013 > 176601258 DENY_WRITE 0x3019f RDWR NONE > /samba/gis > MARIS608/Archaeological_Data.gdb/Survey_Poly.GIS.6216.5276.sr.lock Tue > Feb 12 08:55:08 2013 > 176611149 DENY_WRITE 0x3019f RDWR NONE > /samba/gis > MARIS608/Archaeological_Data.gdb/Site_Point.SEARCHROOM3.4972.5268.sr.lock > Tue Feb 12 08:55:24 2013 > 176601258 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0027.gdbtablx Tue Feb > 12 08:55:08 2013 > 176611149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0027.gdbtablx Tue Feb > 12 08:55:25 2013 > 176601258 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0026.gdbtablx Tue Feb > 12 08:55:08 2013 > 176611149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0026.gdbtablx Tue Feb > 12 08:55:25 2013 > 176601258 DENY_WRITE 0x3019f RDWR NONE > /samba/g
Re: [Samba] having issues with shares
Same thing on both attempts. Here is the veto oplock try: Locked files: Pid UidDenyMode Access R/WOplock SharePath Name Time -- 176601258 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0027.gdbtable Tue Feb 12 08:55:08 2013 176611149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0027.gdbtable Tue Feb 12 08:55:25 2013 176611149 DENY_WRITE 0x3019f RDWR NONE /samba/gis MARIS608/Archaeological_Data.gdb/_gdb.SEARCHROOM3.4972.5268.sr.lock Tue Feb 12 08:55:13 2013 176601258 DENY_WRITE 0x3019f RDWR NONE /samba/gis MARIS608/Archaeological_Data.gdb/Survey_Point.GIS.6216.5276.sr.lock Tue Feb 12 08:55:08 2013 176611149 DENY_WRITE 0x3019f RDWR NONE /samba/gis MARIS608/Archaeological_Data.gdb/Site_Poly.SEARCHROOM3.4972.5268.sr.lock Tue Feb 12 08:55:24 2013 176611149 DENY_WRITE 0x3019f RDWR NONE /samba/gis MARIS608/Archaeological_Data.gdb/Survey_Poly.SEARCHROOM3.4972.5268.sr.lock Tue Feb 12 08:55:24 2013 176601258 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0028.gdbtablx Tue Feb 12 08:55:09 2013 176611149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0028.gdbtablx Tue Feb 12 08:55:24 2013 176601258 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0028.gdbtable Tue Feb 12 08:55:09 2013 176611149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0028.gdbtable Tue Feb 12 08:55:24 2013 176601258 DENY_WRITE 0x3019f RDWR NONE /samba/gis MARIS608/Archaeological_Data.gdb/Survey_Poly.ed.lock Tue Feb 12 08:55:17 2013 176601258 DENY_WRITE 0x3019f RDWR NONE /samba/gis MARIS608/Archaeological_Data.gdb/Survey_Line.ed.lock Tue Feb 12 08:55:17 2013 176601258 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0029.gdbtable Tue Feb 12 08:55:09 2013 176611149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0029.gdbtable Tue Feb 12 08:55:24 2013 176611149 DENY_WRITE 0x3019f RDWR NONE /samba/gis MARIS608/Archaeological_Data.gdb/Site_Poly.SEARCHROOM3.4972.rd.lock Tue Feb 12 08:55:35 2013 176601258 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0029.gdbtablx Tue Feb 12 08:55:09 2013 176611149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0029.gdbtablx Tue Feb 12 08:55:24 2013 176601258 DENY_WRITE 0x3019f RDWR NONE /samba/gis MARIS608/Archaeological_Data.gdb/Site_Poly.GIS.6216.5276.sr.lock Tue Feb 12 08:55:08 2013 176611149 DENY_WRITE 0x3019f RDWR NONE /samba/gis MARIS608/Archaeological_Data.gdb/Survey_Line.SEARCHROOM3.4972.5268.sr.lock Tue Feb 12 08:55:24 2013 176601258 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0026.gdbtable Tue Feb 12 08:55:08 2013 176611149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0026.gdbtable Tue Feb 12 08:55:25 2013 176601258 DENY_WRITE 0x3019f RDWR NONE /samba/gis MARIS608/Archaeological_Data.gdb/Survey_Poly.GIS.6216.5276.sr.lock Tue Feb 12 08:55:08 2013 176611149 DENY_WRITE 0x3019f RDWR NONE /samba/gis MARIS608/Archaeological_Data.gdb/Site_Point.SEARCHROOM3.4972.5268.sr.lock Tue Feb 12 08:55:24 2013 176601258 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0027.gdbtablx Tue Feb 12 08:55:08 2013 176611149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0027.gdbtablx Tue Feb 12 08:55:25 2013 176601258 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0026.gdbtablx Tue Feb 12 08:55:08 2013 176611149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0026.gdbtablx Tue Feb 12 08:5
Re: [Samba] having issues with shares
Hi, Can you try adding: veto oplock files = /*.lock/ to your share definition, and seeing what happens. Also if that doesn't help then try adding: fake oplocks = yes just to see what happens. At this point can I just say that I am not responsible for any file corruption as a result of these settings. Thanks Ned On 12 February 2013 14:37, Donny Brooks wrote: > Actually it does show locks. Here is the pertinent section: > > Locked files: > Pid UidDenyMode Access R/WOplock > SharePath Name Time > > -- > 2752 1149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0027.gdbtable Fri Feb > 8 15:24:47 2013 > 2752 1149 DENY_WRITE 0x3019f RDWR EXCLUSIVE+BATCH > /samba/gis > MARIS608/Archaeological_Data.gdb/Site_Poly.SEARCHROOM3.3480.3228.sr.lock > Fri Feb 8 15:24:46 2013 > 2752 1149 DENY_WRITE 0x3019f RDWR EXCLUSIVE+BATCH > /samba/gis > MARIS608/Archaeological_Data.gdb/Survey_Poly.SEARCHROOM3.3480.3228.sr.lock > Fri Feb 8 15:24:46 2013 > 2752 1149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0028.gdbtablx Fri Feb > 8 15:24:46 2013 > 2752 1149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0028.gdbtable Fri Feb > 8 15:24:46 2013 > 2752 1149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0027.spx Fri Feb 8 > 15:25:21 2013 > 2752 1149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0029.gdbtable Fri Feb > 8 15:24:46 2013 > 2752 1149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0029.gdbtablx Fri Feb > 8 15:24:46 2013 > 2752 1149 DENY_WRITE 0x3019f RDWR EXCLUSIVE+BATCH > /samba/gis > MARIS608/Archaeological_Data.gdb/Survey_Line.SEARCHROOM3.3480.3228.sr.lock > Fri Feb 8 15:24:46 2013 > 2752 1149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a002a.spx Fri Feb 8 > 15:26:55 2013 > 2752 1149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0026.gdbtable Fri Feb > 8 15:24:47 2013 > 2752 1149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0026.spx Fri Feb 8 > 15:27:05 2013 > 2752 1149 DENY_WRITE 0x3019f RDWR EXCLUSIVE+BATCH > /samba/gis > MARIS608/Archaeological_Data.gdb/Site_Point.SEARCHROOM3.3480.3228.sr.lock > Fri Feb 8 15:24:46 2013 > 2752 1149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0027.gdbtablx Fri Feb > 8 15:24:47 2013 > 2752 1149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0026.gdbtablx Fri Feb > 8 15:24:47 2013 > 2752 1149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a002a.gdbtablx Fri Feb > 8 15:24:46 2013 > 2752 1149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0028.spx Fri Feb 8 > 15:27:05 2013 > 2752 1149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a002a.gdbtable Fri Feb > 8 15:24:46 2013 > 2752 1149 DENY_WRITE 0x3019f RDWR EXCLUSIVE+BATCH > /samba/gis > MARIS608/Archaeological_Data.gdb/Survey_Point.SEARCHROOM3.3480.3228.sr.lock > Fri Feb 8 15:24:46 2013 > 2752 1149 DENY_NONE 0x20089 RDONLY NONE > /samba/gis MARIS608/Archaeological_Data.gdb/a0029.spx Fri Feb 8 > 15:27:09 2013 > 2752 1149 DENY_NONE 0x2019f RDWR NONE > /samba/gis MARIS608/Archaeological_Data.gdb/timestamps Fri Feb 8 > 15:24:15 2013 > 2752 1149 DENY_WRITE 0x3019f RDWR EXCLUSIVE+BATCH > /samba/gis > MARIS608/Archaeological_Data.gdb/_gdb.SEARCHROOM3.3480.3228.sr.lock Fri > Feb 8 15:24:15 2013 > > > On Friday, February 8, 2013 06:31 PM CST, Edward Ashley < > n...@redmonkeysoftware.com> wrote: > > > What does smbstatus give you when you have a user using their GIS > software? > > Any locks? > > > > > > On 8 February 2013 21:40, Donny Brooks wrote: > > > > > Everything oplocks related has been disabled. Still the same issue. > There > > > have been no updates to the software as the GIS guy or I would have > had to > > > applied them. Also on the old domain it created the lock files also > but it > > > worked. Thanks for the quick replies. > > > > > > > > > On Friday, February 8, 2013 03:17 PM CST, Edward Ashley < > > > n...@redmo
Re: [Samba] having issues with shares
Actually it does show locks. Here is the pertinent section: Locked files: Pid UidDenyMode Access R/WOplock SharePath Name Time -- 2752 1149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0027.gdbtable Fri Feb 8 15:24:47 2013 2752 1149 DENY_WRITE 0x3019f RDWR EXCLUSIVE+BATCH /samba/gis MARIS608/Archaeological_Data.gdb/Site_Poly.SEARCHROOM3.3480.3228.sr.lock Fri Feb 8 15:24:46 2013 2752 1149 DENY_WRITE 0x3019f RDWR EXCLUSIVE+BATCH /samba/gis MARIS608/Archaeological_Data.gdb/Survey_Poly.SEARCHROOM3.3480.3228.sr.lock Fri Feb 8 15:24:46 2013 2752 1149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0028.gdbtablx Fri Feb 8 15:24:46 2013 2752 1149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0028.gdbtable Fri Feb 8 15:24:46 2013 2752 1149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0027.spx Fri Feb 8 15:25:21 2013 2752 1149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0029.gdbtable Fri Feb 8 15:24:46 2013 2752 1149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0029.gdbtablx Fri Feb 8 15:24:46 2013 2752 1149 DENY_WRITE 0x3019f RDWR EXCLUSIVE+BATCH /samba/gis MARIS608/Archaeological_Data.gdb/Survey_Line.SEARCHROOM3.3480.3228.sr.lock Fri Feb 8 15:24:46 2013 2752 1149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a002a.spx Fri Feb 8 15:26:55 2013 2752 1149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0026.gdbtable Fri Feb 8 15:24:47 2013 2752 1149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0026.spx Fri Feb 8 15:27:05 2013 2752 1149 DENY_WRITE 0x3019f RDWR EXCLUSIVE+BATCH /samba/gis MARIS608/Archaeological_Data.gdb/Site_Point.SEARCHROOM3.3480.3228.sr.lock Fri Feb 8 15:24:46 2013 2752 1149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0027.gdbtablx Fri Feb 8 15:24:47 2013 2752 1149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0026.gdbtablx Fri Feb 8 15:24:47 2013 2752 1149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a002a.gdbtablx Fri Feb 8 15:24:46 2013 2752 1149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0028.spx Fri Feb 8 15:27:05 2013 2752 1149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a002a.gdbtable Fri Feb 8 15:24:46 2013 2752 1149 DENY_WRITE 0x3019f RDWR EXCLUSIVE+BATCH /samba/gis MARIS608/Archaeological_Data.gdb/Survey_Point.SEARCHROOM3.3480.3228.sr.lock Fri Feb 8 15:24:46 2013 2752 1149 DENY_NONE 0x20089 RDONLY NONE /samba/gis MARIS608/Archaeological_Data.gdb/a0029.spx Fri Feb 8 15:27:09 2013 2752 1149 DENY_NONE 0x2019f RDWR NONE /samba/gis MARIS608/Archaeological_Data.gdb/timestamps Fri Feb 8 15:24:15 2013 2752 1149 DENY_WRITE 0x3019f RDWR EXCLUSIVE+BATCH /samba/gis MARIS608/Archaeological_Data.gdb/_gdb.SEARCHROOM3.3480.3228.sr.lock Fri Feb 8 15:24:15 2013 On Friday, February 8, 2013 06:31 PM CST, Edward Ashley wrote: > What does smbstatus give you when you have a user using their GIS software? > Any locks? > > > On 8 February 2013 21:40, Donny Brooks wrote: > > > Everything oplocks related has been disabled. Still the same issue. There > > have been no updates to the software as the GIS guy or I would have had to > > applied them. Also on the old domain it created the lock files also but it > > worked. Thanks for the quick replies. > > > > > > On Friday, February 8, 2013 03:17 PM CST, Edward Ashley < > > n...@redmonkeysoftware.com> wrote: > > > > > I second disabling oplocks however I would check whether they have had > > any > > > software updates or anything to change their GIS software as I'm not too > > > sure that an oplock would create a .lock file, and it sounds like it > > maybe > > > the GIS software doing that. > > > >
Re: [Samba] having issues with shares
What does smbstatus give you when you have a user using their GIS software? Any locks? On 8 February 2013 21:40, Donny Brooks wrote: > Everything oplocks related has been disabled. Still the same issue. There > have been no updates to the software as the GIS guy or I would have had to > applied them. Also on the old domain it created the lock files also but it > worked. Thanks for the quick replies. > > > On Friday, February 8, 2013 03:17 PM CST, Edward Ashley < > n...@redmonkeysoftware.com> wrote: > > > I second disabling oplocks however I would check whether they have had > any > > software updates or anything to change their GIS software as I'm not too > > sure that an oplock would create a .lock file, and it sounds like it > maybe > > the GIS software doing that. > > > > > > On 8 February 2013 20:56, Donny Brooks wrote: > > > > > We recently migrated our install from an ancient fedora 11 install of > > > samba and openldap to a centos 6.3 setup with its openldap and samba. > The > > > domain has been totally recreated from scratch as the person that did > the > > > previous setup has not been employed here in many years. After fighting > > > with shares for a while we mostly got them fixed and working. However > the > > > biggest issue now is when our GIS people try to connect to their samba > > > share. Previously two pople could be editing different feature classes, > > > different files, but now it will not let the second person do anything > but > > > view. Here is a brief explanation from our head GIS guy: > > > > > > We currently have 5 data sets in one feature class in the GIS. > > > > > > site_point > > > site_poly > > > survey_point > > > survey_line > > > survey_poly > > > > > > Before the conversion to the new Domain: > > > > > > User A could open up the GIS on computer 1 and begin to edit one of the > > > data set. (site_point for example) and User B could open up the GIS on > > > computer 2 and begin to edit any other data set except what User A was > > > editing (in this example site_point). As long a two people didn't try > and > > > edit the same data set it worked. > > > > > > After the Domain conversion: > > > > > > User A opens up the GIS on computer 1 and begins to edit any of our > data > > > sets. User B opens up the GIS on computer 2 and attempts to edit any > of our > > > data sets a window opens up with several errors about file locks. ( > I can > > > send up screen shots in the morning) As we saw in the samba logs it > > > appears that once User A begins editing the one data set all the other > data > > > sets in the feature class get .lock files along with the one that User > A is > > > actually editing. The only way User B can edit data is if User A > exits the > > > GIS completely. > > > > > > > > > So with that we have been trying everything we can think of to get it > > > working correctly again. When I setup the share I copied the existing > share > > > from the old domain and put it in the new one making only the domain > name > > > change to the section. > > > > > > Here is the old setup: > > > > > > [pictures] > > > comment = Shared Folder for Pictures > > > path = /samba/pictures > > > read only = No > > > create mask = 0667 > > > directory mask = 0770 > > > csc policy = disable > > > nt acl support = no > > > force security mode = 777 > > > valid users = @hpres > > > force group = @ADMIN\hpres > > > #inherit permissions = yes > > > write list = @ADMIN\hpres > > > > > > Here is the new: > > > > > > [hp-pictures] > > > comment = Shared Folder for Historic Preservation Pictures > > > path = /samba/arrowhead/hp-pictures > > > read only = No > > > create mask = 0667 > > > directory mask = 0770 > > > csc policy = disable > > > nt acl support = no > > > force security mode = 777 > > > valid users = @hpres > > > force group = @MDAH\hpres > > > write list = @MDAH\hpres > > > > > > Anyone have an idea why this could be happening? > > > > > > -- > > > > > > Donny B. > > > -- > > > To unsubscribe from this list go to the following URL and read the > > > instructions: https://lists.samba.org/mailman/options/samba > > > > > Edward Ashley > > Developer > > > > e. n...@redmonkeysoftware.com > > u. www.redmonkeysoftware.com > > t. 0845 867 3849 > > f. 0845 867 4127 > > > > Red Monkey Software | Superior Software Solutions > > > > Red Monkey Software Ltd, 24 The Layne, Elmer Sands, Bognor Regis, West > Sussex. PO22 6JL > > Registered in England and Wales no 5923420 > > Registered Office: 20 Springfield Road, Crawley, West Sussex, RH11 8AD > -- > > Donny B. > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba > Edward Ashley Developer e. n...@redmonkeysoftware.com u. www.redmonkeysoftware.com t. 0845 867 3
Re: [Samba] having issues with shares
Everything oplocks related has been disabled. Still the same issue. There have been no updates to the software as the GIS guy or I would have had to applied them. Also on the old domain it created the lock files also but it worked. Thanks for the quick replies. On Friday, February 8, 2013 03:17 PM CST, Edward Ashley wrote: > I second disabling oplocks however I would check whether they have had any > software updates or anything to change their GIS software as I'm not too > sure that an oplock would create a .lock file, and it sounds like it maybe > the GIS software doing that. > > > On 8 February 2013 20:56, Donny Brooks wrote: > > > We recently migrated our install from an ancient fedora 11 install of > > samba and openldap to a centos 6.3 setup with its openldap and samba. The > > domain has been totally recreated from scratch as the person that did the > > previous setup has not been employed here in many years. After fighting > > with shares for a while we mostly got them fixed and working. However the > > biggest issue now is when our GIS people try to connect to their samba > > share. Previously two pople could be editing different feature classes, > > different files, but now it will not let the second person do anything but > > view. Here is a brief explanation from our head GIS guy: > > > > We currently have 5 data sets in one feature class in the GIS. > > > > site_point > > site_poly > > survey_point > > survey_line > > survey_poly > > > > Before the conversion to the new Domain: > > > > User A could open up the GIS on computer 1 and begin to edit one of the > > data set. (site_point for example) and User B could open up the GIS on > > computer 2 and begin to edit any other data set except what User A was > > editing (in this example site_point). As long a two people didn't try and > > edit the same data set it worked. > > > > After the Domain conversion: > > > > User A opens up the GIS on computer 1 and begins to edit any of our data > > sets. User B opens up the GIS on computer 2 and attempts to edit any of our > > data sets a window opens up with several errors about file locks. ( I can > > send up screen shots in the morning) As we saw in the samba logs it > > appears that once User A begins editing the one data set all the other data > > sets in the feature class get .lock files along with the one that User A is > > actually editing. The only way User B can edit data is if User A exits the > > GIS completely. > > > > > > So with that we have been trying everything we can think of to get it > > working correctly again. When I setup the share I copied the existing share > > from the old domain and put it in the new one making only the domain name > > change to the section. > > > > Here is the old setup: > > > > [pictures] > > comment = Shared Folder for Pictures > > path = /samba/pictures > > read only = No > > create mask = 0667 > > directory mask = 0770 > > csc policy = disable > > nt acl support = no > > force security mode = 777 > > valid users = @hpres > > force group = @ADMIN\hpres > > #inherit permissions = yes > > write list = @ADMIN\hpres > > > > Here is the new: > > > > [hp-pictures] > > comment = Shared Folder for Historic Preservation Pictures > > path = /samba/arrowhead/hp-pictures > > read only = No > > create mask = 0667 > > directory mask = 0770 > > csc policy = disable > > nt acl support = no > > force security mode = 777 > > valid users = @hpres > > force group = @MDAH\hpres > > write list = @MDAH\hpres > > > > Anyone have an idea why this could be happening? > > > > -- > > > > Donny B. > > -- > > To unsubscribe from this list go to the following URL and read the > > instructions: https://lists.samba.org/mailman/options/samba > > > Edward Ashley > Developer > > e. n...@redmonkeysoftware.com > u. www.redmonkeysoftware.com > t. 0845 867 3849 > f. 0845 867 4127 > > Red Monkey Software | Superior Software Solutions > > Red Monkey Software Ltd, 24 The Layne, Elmer Sands, Bognor Regis, West > Sussex. PO22 6JL > Registered in England and Wales no 5923420 > Registered Office: 20 Springfield Road, Crawley, West Sussex, RH11 8AD -- Donny B. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] having issues with shares
I second disabling oplocks however I would check whether they have had any software updates or anything to change their GIS software as I'm not too sure that an oplock would create a .lock file, and it sounds like it maybe the GIS software doing that. On 8 February 2013 20:56, Donny Brooks wrote: > We recently migrated our install from an ancient fedora 11 install of > samba and openldap to a centos 6.3 setup with its openldap and samba. The > domain has been totally recreated from scratch as the person that did the > previous setup has not been employed here in many years. After fighting > with shares for a while we mostly got them fixed and working. However the > biggest issue now is when our GIS people try to connect to their samba > share. Previously two pople could be editing different feature classes, > different files, but now it will not let the second person do anything but > view. Here is a brief explanation from our head GIS guy: > > We currently have 5 data sets in one feature class in the GIS. > > site_point > site_poly > survey_point > survey_line > survey_poly > > Before the conversion to the new Domain: > > User A could open up the GIS on computer 1 and begin to edit one of the > data set. (site_point for example) and User B could open up the GIS on > computer 2 and begin to edit any other data set except what User A was > editing (in this example site_point). As long a two people didn't try and > edit the same data set it worked. > > After the Domain conversion: > > User A opens up the GIS on computer 1 and begins to edit any of our data > sets. User B opens up the GIS on computer 2 and attempts to edit any of our > data sets a window opens up with several errors about file locks. ( I can > send up screen shots in the morning) As we saw in the samba logs it > appears that once User A begins editing the one data set all the other data > sets in the feature class get .lock files along with the one that User A is > actually editing. The only way User B can edit data is if User A exits the > GIS completely. > > > So with that we have been trying everything we can think of to get it > working correctly again. When I setup the share I copied the existing share > from the old domain and put it in the new one making only the domain name > change to the section. > > Here is the old setup: > > [pictures] > comment = Shared Folder for Pictures > path = /samba/pictures > read only = No > create mask = 0667 > directory mask = 0770 > csc policy = disable > nt acl support = no > force security mode = 777 > valid users = @hpres > force group = @ADMIN\hpres > #inherit permissions = yes > write list = @ADMIN\hpres > > Here is the new: > > [hp-pictures] > comment = Shared Folder for Historic Preservation Pictures > path = /samba/arrowhead/hp-pictures > read only = No > create mask = 0667 > directory mask = 0770 > csc policy = disable > nt acl support = no > force security mode = 777 > valid users = @hpres > force group = @MDAH\hpres > write list = @MDAH\hpres > > Anyone have an idea why this could be happening? > > -- > > Donny B. > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba > Edward Ashley Developer e. n...@redmonkeysoftware.com u. www.redmonkeysoftware.com t. 0845 867 3849 f. 0845 867 4127 Red Monkey Software | Superior Software Solutions Red Monkey Software Ltd, 24 The Layne, Elmer Sands, Bognor Regis, West Sussex. PO22 6JL Registered in England and Wales no 5923420 Registered Office: 20 Springfield Road, Crawley, West Sussex, RH11 8AD -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] having issues with shares
I would start by disabling oplocks. - Original Message - From: Donny Brooks To: samba@lists.samba.org Cc: Sent: Friday, 8 February 2013, 12:56 Subject: [Samba] having issues with shares We recently migrated our install from an ancient fedora 11 install of samba and openldap to a centos 6.3 setup with its openldap and samba. The domain has been totally recreated from scratch as the person that did the previous setup has not been employed here in many years. After fighting with shares for a while we mostly got them fixed and working. However the biggest issue now is when our GIS people try to connect to their samba share. Previously two pople could be editing different feature classes, different files, but now it will not let the second person do anything but view. Here is a brief explanation from our head GIS guy: We currently have 5 data sets in one feature class in the GIS. site_point site_poly survey_point survey_line survey_poly Before the conversion to the new Domain: User A could open up the GIS on computer 1 and begin to edit one of the data set. (site_point for example) and User B could open up the GIS on computer 2 and begin to edit any other data set except what User A was editing (in this example site_point). As long a two people didn't try and edit the same data set it worked. After the Domain conversion: User A opens up the GIS on computer 1 and begins to edit any of our data sets. User B opens up the GIS on computer 2 and attempts to edit any of our data sets a window opens up with several errors about file locks. ( I can send up screen shots in the morning) As we saw in the samba logs it appears that once User A begins editing the one data set all the other data sets in the feature class get .lock files along with the one that User A is actually editing. The only way User B can edit data is if User A exits the GIS completely. So with that we have been trying everything we can think of to get it working correctly again. When I setup the share I copied the existing share from the old domain and put it in the new one making only the domain name change to the section. Here is the old setup: [pictures] comment = Shared Folder for Pictures path = /samba/pictures read only = No create mask = 0667 directory mask = 0770 csc policy = disable nt acl support = no force security mode = 777 valid users = @hpres force group = @ADMIN\hpres #inherit permissions = yes write list = @ADMIN\hpres Here is the new: [hp-pictures] comment = Shared Folder for Historic Preservation Pictures path = /samba/arrowhead/hp-pictures read only = No create mask = 0667 directory mask = 0770 csc policy = disable nt acl support = no force security mode = 777 valid users = @hpres force group = @MDAH\hpres write list = @MDAH\hpres Anyone have an idea why this could be happening? -- Donny B. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] having issues with shares
We recently migrated our install from an ancient fedora 11 install of samba and openldap to a centos 6.3 setup with its openldap and samba. The domain has been totally recreated from scratch as the person that did the previous setup has not been employed here in many years. After fighting with shares for a while we mostly got them fixed and working. However the biggest issue now is when our GIS people try to connect to their samba share. Previously two pople could be editing different feature classes, different files, but now it will not let the second person do anything but view. Here is a brief explanation from our head GIS guy: We currently have 5 data sets in one feature class in the GIS. site_point site_poly survey_point survey_line survey_poly Before the conversion to the new Domain: User A could open up the GIS on computer 1 and begin to edit one of the data set. (site_point for example) and User B could open up the GIS on computer 2 and begin to edit any other data set except what User A was editing (in this example site_point). As long a two people didn't try and edit the same data set it worked. After the Domain conversion: User A opens up the GIS on computer 1 and begins to edit any of our data sets. User B opens up the GIS on computer 2 and attempts to edit any of our data sets a window opens up with several errors about file locks. ( I can send up screen shots in the morning) As we saw in the samba logs it appears that once User A begins editing the one data set all the other data sets in the feature class get .lock files along with the one that User A is actually editing. The only way User B can edit data is if User A exits the GIS completely. So with that we have been trying everything we can think of to get it working correctly again. When I setup the share I copied the existing share from the old domain and put it in the new one making only the domain name change to the section. Here is the old setup: [pictures] comment = Shared Folder for Pictures path = /samba/pictures read only = No create mask = 0667 directory mask = 0770 csc policy = disable nt acl support = no force security mode = 777 valid users = @hpres force group = @ADMIN\hpres #inherit permissions = yes write list = @ADMIN\hpres Here is the new: [hp-pictures] comment = Shared Folder for Historic Preservation Pictures path = /samba/arrowhead/hp-pictures read only = No create mask = 0667 directory mask = 0770 csc policy = disable nt acl support = no force security mode = 777 valid users = @hpres force group = @MDAH\hpres write list = @MDAH\hpres Anyone have an idea why this could be happening? -- Donny B. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
