on my server with SLES 11 SP4 with kernel 3.0.101-71-default I tried to compile and use
the latest samba software with version 4.4.3. Compiling was not a problem, but using
the software leads to an unstable system, resulting in kernel messages like those:
I saw some discussions concerning this problem where most people say this is a kernel
bug which can be triggered by samba, and Volker Lendecke from SerNet recommends downgrading
Samba to 4.2 and waiting for the next kernel where the issue is fixed, see:
on my server with SLES 11 SP4 with kernel 3.0.101-71-default I tried to
compile and use
the latest samba software with version 4.4.3. Compiling was not a
problem, but using
the software leads to an unstable system, resulting in kernel messages
like those:
I saw some discussions concerning this problem where most people say
this is a kernel
bug which can be triggered by samba, and Volker Lendecke from SerNet
recommends downgrading
Samba to 4.2 and waiting for the next kernel where the issue is fixed,
see:
My questions is, if kernel 3.0.101-71-default in SLES 11 SP4 also
suffers from this bug
and if so, when it will be fixed.
Thanks for any answers,[/color]
Can I ask why you want Samba 4.4.3 on SLES11 SP4? Is it for a particular
security fix or feature?
The latest supported version of Samba available from SUSE for SLES11 SP4
is 3.6.3. Given that SLES is SUSE Linux Enterprise Server installing
your own compiled version of Samba would be unsupported by SUSE.
If you want Samba 4.x then I suggest you look at SLES12 SP1 as the
latest supported version of Samba there is 4.2.4.
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
the reason is that after the last samba update to version 3.6.3-76.1-3640-SUSE-CODE11-x86_64
(badlock patches) I got some problems with the functionality of samba.
One of the problems is that wbinfo -c is not working any more and that the automatic al password
change on the Microsoft AD which is triggered by samba usually every 7 days is broken. In the
samba log files this leads to messages like
I asked SLES about this problem, but unfortunately at our University we only have a low level
subscription where support is not included so that I can not open a call at SUSE. Nevertheless
I got friendly answer from Kirk Penrose kpenrose@suse.com who opened bug 976657 for me, but
until now I got no solution.
Further more I saw that there are three additional patches addressing regressions in the samba 3.6
backports introduced by the last security releases. As far as I can see one of them should solve
the password change problem I guess. The related information can be found in
and I also sent this information to Kirk, but still I have no answer.
So if you ask me why I want Samba 4.4.3 this is the reason. Indeed I would highly appreciate using
the on board samba version of SLES 11 SP4 if the fixes mentioned above can be included. Otherwise
it’s a bit problematic to deal with a software with known limitations.
Concerning the usage of newer samba 4 releases which are compiled by my own it is obvious that
those releases will not be supported by SUSE. On the other hand, if it is possible to run software
which triggers a kernel bug causing the system to die slowly, the kernel bug should be fixed because
you can not expect that every software is written in a way to bypass this kernel problem.
the reason is that after the last samba update to version
3.6.3-76.1-3640-SUSE-CODE11-x86_64
(badlock patches) I got some problems with the functionality of samba.
One of the problems is that wbinfo -c is not working any more and that
the automatic al password
change on the Microsoft AD which is triggered by samba usually every 7
days is broken. In the
samba log files this leads to messages like
I asked SLES about this problem, but unfortunately at our University we
only have a low level
subscription where support is not included so that I can not open a call
at SUSE. Nevertheless
I got friendly answer from Kirk Penrose kpenrose@suse.com who opened
bug 976657 for me, but
until now I got no solution.
Further more I saw that there are three additional patches addressing
regressions in the samba 3.6
backports introduced by the last security releases. As far as I can see
one of them should solve
the password change problem I guess. The related information can be
found in
and I also sent this information to Kirk, but still I have no answer.
So if you ask me why I want Samba 4.4.3 this is the reason. Indeed I
would highly appreciate using
the on board samba version of SLES 11 SP4 if the fixes mentioned above
can be included. Otherwise
it’s a bit problematic to deal with a software with known limitations.
Concerning the usage of newer samba 4 releases which are compiled by my
own it is obvious that
those releases will not be supported by SUSE. On the other hand, if it
is possible to run software
which triggers a kernel bug causing the system to die slowly, the kernel
bug should be fixed because
you can not expect that every software is written in a way to bypass
this kernel problem.[/color]
for another issue with this newest patch level version of samba for SLES11 SP4 (3.6.3-76.1) support gave us access to a PTF (program temporary fix) version:
Version 3.6.3-76.1.10865.1.PTF.978898-3660-SUSE-CODE11-x86_64
Maybe you could request this version, and see if it adresses your issue, too.
for another issue with this newest patch level version of samba for
SLES11 SP4 (3.6.3-76.1) support gave us access to a PTF (program
temporary fix) version:
Version 3.6.3-76.1.10865.1.PTF.978898-3660-SUSE-CODE11-x86_64[/color]
Could you possibly send me your SR and/or bug (if you know it) number
via private message?
[color=blue]
Maybe you could request this version, and see if it adresses your issue,
too.[/color]
Except Klaus isn’t able to create a support ticket …
Thanks.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
Thank you for your suggestions. Because the file server I am talking about
is in productive use I will not be able to do tests if a special samba version
will work like expected or not.
To be honest, stability was one of the main reasons why we decided to use
Suse Linux Enterprise Server in our department and I was really upset when
I made the experience that a samba patch from SLES caused annoying
problems - and still there is no “official” solution.
For now I am using samba 4.2. which seems to run stable. Maybe I will
update the server to SLES 12 in the future to solve the problem definitely,
but this is an other topic.
For those who are interested in the question I had at the beginning of the threat
if a specific kernel bug will be fixed thus allowing the use of more up to date
samba releases like the 4.4 series the kernel update kernel-default-3.0.101-77.1
seems to fix the problem:
The following non-security bugs were fixed:
…
af_unix: Guard against other == sk in unix_dgram_sendmsg (bsc#973570).
…
Hopefully my samba problems are sorted out for now.
To be honest, stability was one of the main reasons why we decided to
use
Suse Linux Enterprise Server in our department and I was really upset
when
I made the experience that a samba patch from SLES caused annoying
problems - and still there is no “official” solution.
For now I am using samba 4.2. which seems to run stable. Maybe I will
update the server to SLES 12 in the future to solve the problem
definitely,
but this is an other topic.[/color]
So you’re now using Samba 4.2.x on SLES11 SP4? To be supported I’d
definitely look at upgrading the server to SLES12 SP1 with official
Samba 4.2.x packages.
[color=blue]
For those who are interested in the question I had at the beginning of
the threat
if a specific kernel bug will be fixed thus allowing the use of more up
to date
samba releases like the 4.4 series the kernel update
kernel-default-3.0.101-77.1
seems to fix the problem:
The following non-security bugs were fixed:
…
af_unix: Guard against other == sk in unix_dgram_sendmsg
(bsc#973570).
…[/color]
Thanks for the report back.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.