kogh's picture

As part of the topic I have a problem with samba. does not start. After /ect/init.d/samba restart I get the message:
[Ok] Restarting nmbd (via systemctl): nmbd.service.
[....] Restarting smbd (via systemctl): smbd.serviceJob for smbd.service failed. See 'systemctl status smbd.service' and 'journalctl -xn' for details.

I think it would come after system update.

"journalctl -xn" says:

-- Unit smbd.service has begun starting up.
Apr 15 10:25:13 fileserver smbd[4644]: Starting SMB/CIFS daemon: smbd/usr/sbin/smbd: error while loading shared libraries: libsmbd-base.so.0: cannot open shared object file: No such file or directory
Apr 15 10:25:13 fileserver smbd[4644]: failed!
Apr 15 10:25:13 fileserver systemd[1]: smbd.service: control process exited, code=exited status=1
Apr 15 10:25:13 fileserver systemd[1]: Failed to start LSB: start Samba SMB/CIFS daemon (smbd).
-- Subject: Unit smbd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Unit smbd.service has failed.
-- The result is failed.
Apr 15 10:25:13 fileserver systemd[1]: Unit smbd.service entered failed state



Jeremy Davis's picture

What appliance? Which version? Has it been working and recently stopped? Or have you just downloaded it and it's broken OOTB? Or did you install Samba yourself in one of the other appliances? The more info the easier it is to help you...
ukla's picture


same problem here. Fileserver Appliance (14). Samba does not start. There seems to be a problem with an update:

Package        : samba
Debian Bug     : 820947

The upgrade to Samba 4.2 issued as DSA-3548-1 introduced a packaging
regression causing an additional dependency on the samba binary package
for the samba-libs, samba-common-bin, python-samba and samba-vfs-modules
binary packages. Updated packages are now available to address this

For the stable distribution (jessie), this problem has been fixed in
version 2:4.2.10+dfsg-0+deb8u2.

When I try to run security updates (turnkey-install-security-updates), I get

The following packages have unmet dependencies:
 libpam-smbpass : Depends: samba-libs (= 2:4.2.10+dfsg-0+deb8u2) but 2:4.2.10+dfsg-0+deb8u1 is installed
 libsmbclient : Depends: samba-libs (= 2:4.2.10+dfsg-0+deb8u2) but 2:4.2.10+dfsg-0+deb8u1 is installed
 python-samba : Depends: samba-libs (= 2:4.2.10+dfsg-0+deb8u2) but 2:4.2.10+dfsg-0+deb8u1 is installed
 samba : Depends: samba-libs (= 2:4.2.10+dfsg-0+deb8u2) but 2:4.2.10+dfsg-0+deb8u1 is installed
 samba-common-bin : Depends: samba-libs (= 2:4.2.10+dfsg-0+deb8u2) but 2:4.2.10+dfsg-0+deb8u1 is installed
 samba-dsdb-modules : Depends: samba-libs (= 2:4.2.10+dfsg-0+deb8u2) but 2:4.2.10+dfsg-0+deb8u1 is installed
 samba-libs : Depends: samba (= 2:4.2.10+dfsg-0+deb8u1) but 2:4.2.10+dfsg-0+deb8u2 is installed
E: Unmet dependencies. Try using -f.


Can anyone advise how to fix?

Thanks, ukla.






kogh's picture

apt-get -f install

kogh's picture


TurnKey GNU/Linux 14.0 / Debian 8.1 Jessie

yes, recently stopped - prabobly in night

no it was orginal install from appliance


kogh's picture

how can i disable daily updates? i will do this manualy

Jeremy Davis's picture

So it appears that it was a bug in a security update then... FTR here's the bug link: https://lists.debian.org/debian-security-announce/2016/msg00124.html

I just double checked and it looks like all the dependencies have been moved to the Debian security repo so your appliance should have fixed itself last time auto sec updates ran... Although apt-get update && apt-get install -f should also manually fix it.

Can any of your guys confirm that a broken server has fixed itself? Perhaps it also requires a manual intervention to restart Samba?

FWIW I'm pretty sure that that's only the third serious bug in a security update in the 8 years that we've been auto installing them in appliances, so pretty good on average. And this one appears to fix itself...

If you would like to disable security updates (personally I wouldn't; but OTOH I can understand why you might want to) then you just need to remove the cron-apt cron daily job. IIRC making the cron job non-executable (chmod -x /etc/cron.d/cron-apt) should do the trick; although deleteing it would definitely work... See the auto security update docs for the full rundown on auto security updates.

kogh's picture

Unfortunately, the server does not fix itself. Samba service doesn't work. I had to force

-f install

There is one strange thing - in my old configuration (smb.conf) smbd service does not start (the nmbd is ok) - when I changed my conf to the default configuration both servers starts corectly. I have not had time to check what setting causes. Maby someone knows what can make this issue?

Jeremy Davis's picture

Although it's unfortunate that it didn't fix itself...

Do you still have your old config handy? TBH I'm no Samba whiz but perhaps if you post it we can have a look and see if there is anything obvious.

kogh's picture

I have in my configurations such a thing. I copied it some time ago somewhere in the network on my test server.


    os level = 20
    passdb backend = tdbsam
    default = global
    passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
    delete group script = /usr/sbin/groupdel '%g'
    unix password sync = yes
    add user script = /usr/sbin/useradd -m '%u' -g users -G users
    winbind trusted domains only = yes
    syslog = 0
    add group script = /usr/sbin/groupadd '%g'
    admin users = root
      guest account = gostek
      map to guest = Bad User
    wins support = true
    add user to group script = /usr/sbin/usermod -G '%g' '%u'
    max log size = 1000
    panic action = /usr/share/samba/panic-action %d
    encrypt passwords = true
    workgroup = test
    security = share
    delete user script = /usr/sbin/userdel -r '%u'
    netbios name = FILESERVER
    passwd program = /usr/bin/passwd %u
    obey pam restrictions = yes
    server string = FileServer
    winbind use default domain = yes
    pam password change = yes
    socket options = TCP_NODELAY
    null passwords = yes
    dns proxy = no
    log file = /var/log/samba/samba.log
Jeremy Davis's picture

Nothing jumps out at me but as I said, I'm no Samba expert...

Perhaps you could compare the 2 conf files (your original but not working vs the default and working) and see what difference there are? It does seem strange though that it was working, then a security update broke it and it now no longer works. Especially when others have reported that just doing the force update and restart works ok for them.

Perhaps there was some other regression on the latest update that only effects specific use cases?

Same problem. It also broke samba module in Webmin. To get things goin I used:

$sudo apt-get --reinstall install samba-libs

Also had to force restart of Samba services.

Xyon's picture

I found that, with an appliance downloaded and set up today, I had to additionally apt-get install winbind to get samba to start. Otherwise, samba mysteriously refused to start; the verbose log (eventually) showed:

dreplsrv_notify_schedule(5) scheduled for: Tue May 30 13:39:05 2017 UTC
/usr/sbin/winbindd: Failed to exec child - No such file or directory
winbindd daemon exited normally

Though it looked like it was happy with it, it actually caused Samba to exit abnormally, before attaching to any listeners. Installing winbind directly results in normal behaviour; is this something that should be installed into the appliance?

Jeremy Davis's picture

Assuming this is the Domain Controller appliance, then yes it's a known issue. Winbind will be installed by default in the next release (which I'm currently working on). In a perfect world we would have re-released it ages ago, however, we have a serious labour bottleneck so we have a ton of competing priorities.

FWIW it was a Samba security update that introduced the winbind dependency. In Debian (what TurnKey is under the hood) generally all security patches are backported to the version included with a particular release. Debian Jessie shipped with Samba 4.1 (which worked fine without winbind). However, a security bug that occurred mid last year was too complex to patch reliably. So they bumped the Samba version (to v4.2). And that's what introduced the new dependency.

Unfortunately the winbind package isn't in the security repo though, so when our secupdates script runs, it updates Samba, but doesn't auto install the new dependency.

Add new comment