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
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Jelle van der Waa (jelly)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

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
Comment by Andi (And1G) - Monday, 28 September 2020, 10:37 GMT
As a hotfix I created a systemd drop in for samba.service with the following contents:
[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.
Comment by loqs (loqs) - Monday, 28 September 2020, 16:40 GMT Comment by Richard Vine (viner) - Saturday, 03 October 2020, 09:03 GMT
I'm getting the same issue. And1G's workaround has resolved this for me seemingly without any issues. I briefly tried NotifyAccess=main as the samba article suggests this is the implicit default, which perhaps isn't the case in my version of systemd (also 246.6-1), but this made no difference and NotifyAccess=all was required.
Comment by Klaus (klaeuser) - Tuesday, 13 October 2020, 18:54 GMT
unfortunately NotifyAccess=all does *not* help.
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.
Comment by Andi (And1G) - Tuesday, 13 October 2020, 19:22 GMT
That's interesting, because my Samba AD DC does not crash. What exactly do you mean by "connect"? I can log in with the domain account into Windows machines and browse the shares of the DC, no crash here.
Comment by Klaus (klaeuser) - Wednesday, 14 October 2020, 06:57 GMT
excuse me - that was my fault!

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.
Comment by DJ Lucas (DJ_Lucas) - Sunday, 01 November 2020, 04:51 GMT
People posting in this thread most likely know, but for anybody that runs across this, DO NOT REPLACE DISTRO FILES. Copy the service file to /etc/systemd/system, modify that file, reload systemd, and enable the service again. When it is fixed in the distro, remove the copy in /etc/systemd/system, reload the daemon, and enable it again to replace the symlink.

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
Comment by loqs (loqs) - Sunday, 01 November 2020, 14:34 GMT
@DJ_Lucas the change you are requesting partially reverses an upstream change [1], have you discussed it with upstream?

[1] https://gitlab.com/samba-team/samba/-/commit/d1740fb3d5a72cb49e30b330bb0b01e7ef3e09cc
Comment by telsch (telsch) - Sunday, 01 November 2020, 14:57 GMT
It looks like only Samba in AD mode is affected. smb/nmb units running without problems.
Comment by DJ Lucas (DJ_Lucas) - Sunday, 01 November 2020, 18:15 GMT
Regardless, we need to be able to notify the parent. This is one of two quick fixes. Setting Type=simple works as well.

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.
Comment by telsch (telsch) - Saturday, 06 February 2021, 13:45 GMT
This bug was fixed in samba-4.13.2 upstream.

Loading...