SAMBA does not start

apt-get -f install

Hello

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
problem.

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.

fileserver

TurnKey GNU/Linux 14.0 / Debian 8.1 Jessie

yes, recently stopped - prabobly in night

no it was orginal install from appliance

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

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.

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?

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

[global]

    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

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.

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?

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.

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.

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?