Bug 14720 - logging causes segmentation fault when serving requests (Docker on raspberry pi)
Summary: logging causes segmentation fault when serving requests (Docker on raspberry pi)
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.13.8
Hardware: Other Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-26 22:58 UTC by mpeter.68m0y
Modified: 2025-06-07 01:13 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mpeter.68m0y 2021-05-26 22:58:30 UTC
If global logging is set to a level higher than 1 (see example below), segmentation faults will follow while serving requests, and the requests will not get served.

Configuration example of smb.conf:
...
[global]
   log level = 2
...

Example of one such error being logged:

smb      | 2021-05-26T21:44:10.089721974Z ===============================================================
smb      | 2021-05-26T21:44:10.089765622Z INTERNAL ERROR: Signal 11: Segmentation fault in pid 2766 (4.13.8)
smb      | 2021-05-26T21:44:10.089785955Z If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting
smb      | 2021-05-26T21:44:10.089806547Z ===============================================================
smb      | 2021-05-26T21:44:10.089825991Z PANIC (pid 2766): Signal 11: Segmentation fault in 4.13.8
smb      | 2021-05-26T21:44:10.089844639Z unable to produce a stack trace on this platform
smb      | 2021-05-26T21:44:10.089864194Z dumping core in /var/log/samba/cores/smbd
smb      | 2021-05-26T21:44:10.115081870Z Registered MSG_REQ_POOL_USAGE
smb      | 2021-05-26T21:44:10.122442859Z check_ntlm_password:  Authentication for user [MY_USERNAME] -> [MY_USERNAME] FAILED with error NT_STATUS_NO_SUCH_USER, authoritative=1

MY_USERNAME in the above excerpt is the username of the Windows user account from which I sent requests to the SMB server.

Such errors occur only when the log level is higher than 1, but in this case it's enough to open Windows's built-in file manager (assuming a share is connected from the SMB server), because the error is triggered by every request that needs to be responded.
When such errors happen, no file shares are served.

notes:
- selected the file services component, because I only use that part, but can't confirm it only affects that component.
- hardware is 32 bit ARM (Raspberry Pi 4 with 2 GB RAM)
Comment 1 Andrew Bartlett 2021-06-25 08:33:30 UTC
Did you ever get a GDB backtrace of this?
Comment 2 mpeter.68m0y 2021-08-15 15:37:00 UTC
Haven't forgot about the issue, actually I see this every few days because the issue's browser tab is near my email account's tab, but it seems it might take some more time to find out how to make the backtrace.
Comment 3 Douglas Bagnall 2025-06-05 04:39:55 UTC
Does this still happen?

We really need more information to know what is going on.
Comment 4 mpeter.68m0y 2025-06-06 03:14:47 UTC
It does not anymore. But I should also note that possibly I was using a very outdated version even when I reported the issue, as I was using a relatively common docker image which has been unmaintained for years: https://github.com/dperson/samba

It may be off topic, but I think you should consider releasing some kind of announcement about this situation, considering that (in my understanding) those the use that Docker image are running highly exploitable software with high privileges.
The dockerhub page does not give too much statistics, but the (all time) 50 million download suggests to me that it is very popular: https://hub.docker.com/r/dperson/samba/tags
Comment 5 Douglas Bagnall 2025-06-07 01:13:28 UTC
(In reply to mpeter.68m0y from comment #4)
> It may be off topic, but I think you should consider releasing some kind of announcement about this situation, considering that (in my understanding) those the use that Docker image are running highly exploitable software with high privileges.

Yes, this problem is generally outside our awareness and control. 

My reading of https://github.com/dperson/samba/blob/master/Dockerfile

 RUN apk --no-cache --no-progress upgrade && \
     apk --no-cache --no-progress add bash samba shadow tini tzdata && \

is that you'll end up with the version of Samba that Alpine Linux has at the time the Dockerfile is run, so if you build from there it is maybe OK. But the Dockerhub files have not kept up.

Commenters on https://github.com/dperson/samba/issues/459 suggests these alternatives:

https://github.com/dockur/samba
https://github.com/ServerContainers/samba

I am removing the restriction to Samba developers, because it is not useful for embargo knowledge that there was once a crash on 4.13 in a container on 32 bit arm.