FS#68025 - [samba] Not starting after update to 4.13.0-1
Attached to Project:
Arch Linux
Opened by Andi (And1G) - Monday, 28 September 2020, 10:27 GMT
Last edited by Tobias Powalowski (tpowa) - Sunday, 07 February 2021, 09:34 GMT
Opened by Andi (And1G) - Monday, 28 September 2020, 10:27 GMT
Last edited by Tobias Powalowski (tpowa) - Sunday, 07 February 2021, 09:34 GMT
|
Details
After updating Samba to version 4.13.0-1 it fails to start
via the systemd service:
systemd[1]: Starting Samba AD Daemon... samba[538]: [2020/09/28 11:55:37.470984, 0] ../../source4/smbd/server.c:629(binary_smbd_main) samba[538]: samba version 4.13.0 started. samba[538]: Copyright Andrew Tridgell and the Samba Team 1992-2020 samba[538]: [2020/09/28 11:55:37.574484, 0] ../../source4/smbd/server.c:872(binary_smbd_main) samba[538]: binary_smbd_main: samba: using 'prefork' process model systemd[1]: samba.service: Got notification message from PID 545, but reception only permitted for main PID 538 systemd[1]: samba.service: Got notification message from PID 578, but reception only permitted for main PID 538 systemd[1]: samba.service: Got notification message from PID 545, but reception only permitted for main PID 538 smbd[545]: [2020/09/28 11:55:37.834527, 0] ../../lib/util/become_daemon.c:135(daemon_ready) smbd[545]: daemon_ready: daemon 'smbd' finished starting up and ready to serve connections winbindd[578]: [2020/09/28 11:55:37.908453, 0] ../../source3/winbindd/winbindd_cache.c:3203(initialize_winbindd_cache) winbindd[578]: initialize_winbindd_cache: clearing cache and re-creating with version number 2 winbindd[578]: [2020/09/28 11:55:37.915283, 0] ../../lib/util/become_daemon.c:135(daemon_ready) systemd[1]: samba.service: Got notification message from PID 578, but reception only permitted for main PID 538 winbindd[578]: daemon_ready: daemon 'winbindd' finished starting up and ready to serve connections samba[580]: [2020/09/28 11:55:38.301170, 0] ../../lib/util/util_runcmd.c:352(samba_runcmd_io_handler) samba[580]: /usr/bin/samba_dnsupdate: /usr/bin/samba_dnsupdate:274: DeprecationWarning: please use dns.resolver.Resolver.resolve() instead samba[580]: [2020/09/28 11:55:38.301711, 0] ../../lib/util/util_runcmd.c:352(samba_runcmd_io_handler) samba[580]: /usr/bin/samba_dnsupdate: return resolver.query(name, name_type) systemd[1]: samba.service: start operation timed out. Terminating. winbindd[578]: [2020/09/28 11:57:06.184993, 0] ../../source3/winbindd/winbindd.c:247(winbindd_sig_term_handler) winbindd[578]: Got sig[15] terminate (is_parent=1) systemd[1]: samba.service: Main process exited, code=exited, status=127/n/a systemd[1]: samba.service: Failed with result 'timeout'. systemd[1]: Failed to start Samba AD Daemon. |
This task depends upon
Closed by Tobias Powalowski (tpowa)
Sunday, 07 February 2021, 09:34 GMT
Reason for closing: Fixed
Additional comments about closing: 4.13.2-1
Sunday, 07 February 2021, 09:34 GMT
Reason for closing: Fixed
Additional comments about closing: 4.13.2-1
[Service]
NotifyAccess=all
But this might just cure the symptoms, not the problem. As this might also be related to systemd, it is version 246.6-1.
In fact samba starts after adding NotifyAccess=all to the service, but ... (I'm running samba as a DC) ... as soon as the first Windows client connects, the service crashes.
My first thought was, we had this several weeks before when samba was compiled with the MIT kerberos option. But I double checked this - no MIT krb.
At the moment I have no idea ... so I switched back 4.12.6-1.
Somehow that entry (NotifyAccess=all) had gone from my samba.service ...
I added it once more and now can confirm that it resolves (or covers) the problem.
To tpowa or jelly, this is a one line fix for a bug that should have had a high severity (complete loss of functionality). Can we get a -2 with only this change to samba.service file?
Thanks
--DJ
[1] https://gitlab.com/samba-team/samba/-/commit/d1740fb3d5a72cb49e30b330bb0b01e7ef3e09cc
The correct fix is here as loqs mentioned, but whether that is a security fix (worth backporting) is certainly up for debate (low in my opinion, but done none the less):
https://gitlab.com/samba-team/samba/-/commit/c4938561a97e55efd624694ea55ef7c1a46a350a.diff
Works for AD, not tested for smbd/nmbd/winbindd standalone.
All three methods get end users past the breakage.