[Samba] having issues with shares

Edward Ashley ned at redmonkeysoftware.com
Fri Feb 8 17:31:21 MST 2013


What does smbstatus give you when you have a user using their GIS software?
Any locks?


On 8 February 2013 21:40, Donny Brooks <dbrooks at mdah.state.ms.us> 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 <
> ned at 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 <dbrooks at mdah.state.ms.us> 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. ned at 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. ned at 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


More information about the samba mailing list