[Samba] Best way to get to bottom of odd failures?

Andrew Bartlett abartlet at samba.org
Wed May 4 22:49:46 UTC 2022


I agree, upgrading to a newer version and setting the panic action is
the right next step.

While I see from the reply that it has helped here, I personally
wouldn't suggest just changing configuration without understanding what
is being changed and why.  

I know that has been a practice here, but honestly if Samba segfaults
then we have a Samba issue, while the smb.conf might be 'odd' or 'to
blame' it really shouldn't segfault. 

Samba tries hard to ensure that previously working configurations keep
working.  Sometimes that isn't possible - eg our November security
release - but even then we still go back again and again to try to
mitigate the impacts further.

Andrew Bartlett

On Wed, 2022-05-04 at 15:41 +0200, L.P.H. van Belle via samba wrote:
> If this still happens after the suggested changes from Rowland. 
> 
> Then I suggest to try the 4.15.7 packages of my repo. 
> I seen this also but some time ago. 
> 
> I think this was something with locking..
> 
> greetz, 
> 
> Louis
> 
> 
> > -----Oorspronkelijk bericht-----
> > Van: samba Namens Rowland Penny via samba
> > Verzonden: woensdag 4 mei 2022 15:22
> > Aan: samba at lists.samba.org
> > CC: Rowland Penny <rpenny at samba.org>
> > Onderwerp: Re: [Samba] Best way to get to bottom of odd failures?
> > 
> > On Wed, 2022-05-04 at 09:30 -0300, frank picabia via samba wrote:
> > > I have a Debian 11.3, all up to date, running Samba to provide
> > > shares.
> > > It authenticates against Windows AD using security=ADS
> > > smbd -V reports 4.13.13-Debian
> > > 
> > > The problems with our shares vary.
> > > 
> > > With one user, mounting the share to their Windows system
> > > produces segfaults on smbd.  They can do small
> > > transfers, but larger ones, say over 200MB, would fail.
> > > It seems those transfer failures align with segfaults on smbd.
> > > 
> > > I see emails from root with tread debugging info for segfaults in
> > > smbd.
> > > 
> > > With myself, the mount works better.  I can transfer the Debian
> > > ISO
> > > back and forth over it.  However, the progress meter goes to 100%
> > > then says "an unspecified network error has occurred".  If I
> > > click
> > > Try Again
> > > the transfer is redone, the file is over written and the second
> > > attempt is
> > > perfect.
> > > 
> > > If I use smbclient on another Linux system, I see no errors at
> > > all.
> > > 
> > > I'm thinking, if I submitted a bug report, this isn't going to be
> > > reproducible.
> > > Also in many bug reports, people pick apart the config file and
> > > say there was something wrong with it.  So maybe I should begin
> > > there?
> > > 
> > > The system in question was upgraded from Debian 9 to 10 to 11 and
> > > we
> > > had no issues with the older versions, while using a similar
> > > configuration.
> > > 
> > > Here is what we have from testparam output.  I have replaced our
> > > domain name
> > > as "example" or "EXAMPLE".
> > 
> > Try the '[global]' section like this:
> > [global]
> >         workgroup = EXAMPLE
> >         realm = AD.EXAMPLE.NET
> >         security = ADS
> >         server string = %h server
> > 
> >         bind interfaces only = Yes
> >         interfaces = eth0
> >         hosts allow = 111.222.
> >         dns proxy = No
> > 
> >         winbind use default domain = yes
> >         winbind expand groups = 2
> >         winbind refresh tickets = Yes
> > 
> >         idmap config * : backend = tdb
> >         idmap config * : range = 69998-69999
> >         idmap config example : backend = rid
> >         idmap config example : range = 70000-9999999999
> >         template shell = /bin/bash
> > 
> >         # user Administrator workaround, without it you are unable
> > to
> > set privileges
> >         username map = /etc/samba/user.map
> > 
> >         vfs objects = acl_xattr
> >         map acl inherit = Yes
> > 
> >         # Comment the following 4 lines to act as a print server
> >         printcap name = /dev/null
> >         load printers = no
> >         disable spoolss = yes
> >         printing = bsd
> > 
> >         # logging
> >         log file = /var/log/samba/%m.log
> >         logging = file
> >         max log size = 100
> > 
> >         panic action = /usr/share/samba/panic-action %d
> > 
> > Create /etc/samba/user.map containing this:
> > 
> > !root = EXAMPLE\Administrator
> > 
> > Change the shares to this:
> > 
> > [series]
> >         path = /usr/local/series
> >         read only = No
> > 
> > [cms]
> >         path = /usr/local/www/cms
> >         read only = No
> > 
> > Then set the permissions from Windows or with setfacl (preferably
> > Windows), see here for more info:
> > 
> > https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_A
> > CLs
> > https://wiki.samba.org/index.php/Setting_up_a_Share_Using_POSIX_ACLs
> > 
> > While Samba shouldn't segfault, this may be a Windows problem.
> > 
> > Rowland
> > 
> > 
> > 
> > --
> > To unsubscribe from this list go to the following URL and read the
> > instructions:  https://lists.samba.org/mailman/options/samba
> 
> 
-- 
Andrew Bartlett (he/him)       https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba

Samba Development and Support, Catalyst IT - Expert Open Source
Solutions




More information about the samba mailing list