We attempted to upgrade a client’s SLES 12 installation to SLES12 SP5. Everything appeared to be okay until it was discovered that Samba was not runningÂSamba was upgraded along with the rest of the system. The newly-installed Samba version, as reported by smbd -V is 4.10.5-git.165.126b152c2383.6.2-SUSE-SLE_12-x86_64. The output from log.smbd is as follows:
[2020/05/27 20:40:44.224139, 0] ../../source3/smbd/server.c:1782(main)
smbd version 4.10.5-git.165.126b152c2383.6.2-SUSE-SLE_12-x86_64 started.
Copyright Andrew Tridgell and the Samba Team 1992-2019
[2020/05/27 20:40:44.225392, 1] ../../source3/lib/messages_dgm.c:1060(messaging_dgm_init)
messaging_dgm_init: bind failed: Permission denied
The output from log.nmbd is as follows:
[2020/05/27 20:53:41.656254, 0] ../../source3/nmbd/nmbd.c:906(main)
nmbd version 4.10.5-git.165.126b152c2383.6.2-SUSE-SLE_12-x86_64 started.
Copyright Andrew Tridgell and the Samba Team 1992-2019
[2020/05/27 20:53:41.657498, 1] ../../source3/lib/messages_dgm.c:1060(messaging_dgm_init)
messaging_dgm_init: bind failed: Permission denied
We’re quite familiar with Samba, having worked with it since the days of version 2.0, but have no clue what these errors mean.
@Bill Hi, so the samba directory permissions are ok, mount point not read only for the shares? What about the status output rather than log, if you tail the journal and also try restarting the service is there more info?
journalctl -f
systemctl status smbd nmbd
systemctl restart smbd nmbd
Here’s the journal with unrelated blather removed:
-- Logs begin at Thu 2020-05-28 13:22:18 CDT, end at Thu 2020-05-28 14:35:38 CDT. --
May 28 13:22:18 lawsrv01 systemd-journald[158]: Runtime journal (/run/log/journal/) is currently using 8.0M.
Maximum allowed usage is set to 297.4M.
Leaving at least 446.2M free (of currently available 2.8G of space).
Enforced usage limit is thus 297.4M, of which 289.4M are still available.
May 28 13:22:18 lawsrv01 kernel: Linux version 4.12.14-122.20-default (geeko@buildhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP Fri
...
May 28 14:30:01 lawsrv01 systemd[1]: Started Session 7 of user root.
May 28 14:35:38 lawsrv01 systemd[1]: Starting Samba NMB Daemon...
May 28 14:35:38 lawsrv01 systemd[1]: nmb.service: Main process exited, code=exited, status=1/FAILURE
May 28 14:35:38 lawsrv01 systemd[1]: Failed to start Samba NMB Daemon.
May 28 14:35:38 lawsrv01 systemd[1]: nmb.service: Unit entered failed state.
May 28 14:35:38 lawsrv01 systemd[1]: nmb.service: Failed with result 'exit-code'.
May 28 14:35:38 lawsrv01 systemd[1]: Starting Samba SMB Daemon...
May 28 14:35:38 lawsrv01 systemd[1]: smb.service: Main process exited, code=exited, status=1/FAILURE
May 28 14:35:38 lawsrv01 systemd[1]: Failed to start Samba SMB Daemon.
May 28 14:35:38 lawsrv01 systemd[1]: smb.service: Unit entered failed state.
May 28 14:35:38 lawsrv01 systemd[1]: smb.service: Failed with result 'exit-code'.
Here’s what systemctl status smbd nmbd had to say after the above attempted start:
? smb.service - Samba SMB Daemon
Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2020-05-28 14:35:38 CDT; 11min ago
Process: 2001 ExecStart=/usr/sbin/smbd --foreground --no-process-group $SMBDOPTIONS (code=exited, status=1/FAILURE)
Process: 1996 ExecStartPre=/usr/share/samba/update-apparmor-samba-profile (code=exited, status=0/SUCCESS)
Main PID: 2001 (code=exited, status=1/FAILURE)
May 28 14:35:38 lawsrv01 systemd[1]: Starting Samba SMB Daemon...
May 28 14:35:38 lawsrv01 systemd[1]: smb.service: Main process exited, code=exited, status=1/FAILURE
May 28 14:35:38 lawsrv01 systemd[1]: Failed to start Samba SMB Daemon.
May 28 14:35:38 lawsrv01 systemd[1]: smb.service: Unit entered failed state.
May 28 14:35:38 lawsrv01 systemd[1]: smb.service: Failed with result 'exit-code'.
? nmb.service - Samba NMB Daemon
Loaded: loaded (/usr/lib/systemd/system/nmb.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2020-05-28 14:35:38 CDT; 11min ago
Process: 1990 ExecStart=/usr/sbin/nmbd --foreground --no-process-group $NMBDOPTIONS (code=exited, status=1/FAILURE)
Main PID: 1990 (code=exited, status=1/FAILURE)
May 28 14:35:38 lawsrv01 systemd[1]: Starting Samba NMB Daemon...
May 28 14:35:38 lawsrv01 systemd[1]: nmb.service: Main process exited, code=exited, status=1/FAILURE
May 28 14:35:38 lawsrv01 systemd[1]: Failed to start Samba NMB Daemon.
May 28 14:35:38 lawsrv01 systemd[1]: nmb.service: Unit entered failed state.
May 28 14:35:38 lawsrv01 systemd[1]: nmb.service: Failed with result 'exit-code'.
Nothing in the shared directory tree was changed in any way. smb.conf is as it was before the upgrade. As I said, it was a working Samba installation until the upgrade.
Incidentally, who was it that thought systemd and a binary journal was a good idea?
Thanks for any help you can offer. We reverted the installation to SLES 11 SP4 so the client would have a functioning system.
I didn’t think to check AppArmor because we do not enable it on our builds. So it could be the upgrade enabled AppArmor, which I do know from past experience will get in Samba’s way when using the SuSE Samba build. We will check it out on our next visit to the client, which likely won’t be for a few days.
Problem solved! It turns out it wasn’t AppArmor that was causing the trouble.
During the upgrade, the Ethernet adapter (eth0) bound to Samba was “magically” configured for both IPv4 and IPv6ÂIPv6 had been previously disabled, as it wasn’t needed on the LAN. I recalled from past experience that such an arrangement would confuse Samba, and the clue that that was the problem was right in front of me in the logs (...messaging_dgm_init: bind failed: Permission denied). Disabling IPv6 was all it took to get Samba up and running.
BTW, systemd sucks big time. Shame on you, SuSE, for going that route.
