You are here
kogh - Fri, 2016/04/15 - 11:39
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
Forum:
Which appliance? Which version?
Hellosame problem hier.
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.
apt-get -f install
apt-get -f install
fileserver TurnKey GNU/Linux
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
how can i disable daily updates? i will do this manualy
Great thanks for the additional info
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.
Unfortunately, the server
Unfortunately, the server does not fix itself. Samba service doesn't work. I had to force
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?
Thanks for the update
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.
I have in my configurations
I have in my configurations such a thing. I copied it some time ago somewhere in the network on my test server.
Nothing jumps out at me
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
Same problem. It also broke samba module in Webmin. To get things goin I used:
Also had to force restart of Samba services.
SAMBA does not start (Winbind?)
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:
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?
Hi Xyon - is this the Domain Controller appliance?
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