Samba läuft, lässt sich aber nicht neustarten [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : Samba läuft, lässt sich aber nicht neustarten

FormA

16.08.04, 09:35

Hallo zusammen,

in den letzten Tagen hab ich mich verstärkt mit Debian auseinander gesetzt und habe nach und nach alle Funktionen von meinem Windows Server auf Debian übertragen. Bisher habe ich es immer so gehandhabt, dass ich bei einem Problem nach der entsprechenden Fehlermeldung (logs)gegooglet habe und auch immer fündig geworden bin. Ansonsten habe ich mich immer an einschlägigen Howtos entlanggehangelt. Seit ein paar Stunden habe ich aber ein Problem, mit dem ich nicht alleine fertig werde...

Und zwar habe ich mehrfach Anpassungen an der smb.conf durchgeführt und hatte nie ein Problem. Plötzlich bekomme ich bei jedem Samba Restart folgende Meldung :

root@server:/# /etc/init.d/samba restart
Restarting Samba daemons: nmbd/etc/init.d/samba: start-stop-daemon: command not found
/etc/init.d/samba: start-stop-daemon: command not found
smbd/etc/init.d/samba: start-stop-daemon: command not found
/etc/init.d/samba: start-stop-daemon: command not found

Samba funktioniert zwar, ich kann ihn aber zu keinem Neustart bewegen (kein stop, reload, restart oder force-reload). Ich muss den Server schon komplett neustarten um Samba neustarten zu können. Ich finde in keiner Log Datei (/var/log/samba) eine entsprechende oder andere Fehlermeldung. Mit google komme ich auch nich weiter weil ich nur 1 oder 2 matches gefunden habe, die mich aber auch nicht weitergebracht haben.

Auch auffällig ist - die befehle reboot und shutdown werden seit neustem nicht mehr angenommen - command not found.

Klingt alles etwas mysteriös, ich weiß aber ich hoffe, dass ihr mir helfen könnt ! Ansonsten weiß ich im Moment nicht mehr weiter. Danke !

FormA

muell200

16.08.04, 11:09

Auch auffällig ist - die befehle reboot und shutdown werden seit neustem nicht mehr angenommen - command not found.

hallo

so wie es aussieht würde deine pfad-variabele falsch gesetzt
( also keine samba problem )

was sagt:
echo $PATH

ich denke mind. der pfad /sbin/ fehlt
wenn das so ist, muss du den pfad wieder hinzufügen

Linux-N00b

16.08.04, 12:43

Hatte das Problem auch mal. Es hat sich aber erledigt, nachdem ich die Suchfunktion eingesetzt hatte, das Thema gab es schon mal so ähnlich.
Hier nochmal das, was du ändern mußt:

In die Konsole

echo $PATHeingeben.

Wenn da Pfadangaben mit */sbin fehlen, dann liegt es daran.

Gehe nun in die .profile (man achte auf den Punkt davor) und änder die Zeile so wie hier

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin/:/sbin:/bin:/usr/bin/X11
Vermutlich fehlen, wie bei mir mal, die Pfade zu dem Ordner sbin, deshalb funktioniert einiges nicht. ;)

FormA

16.08.04, 14:32

Also wenn ich "echo $PATH" eingebe bekomme ich folgendes:

/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

In der .profiles steht:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin/:/sbin:/bin:/usr/bin/X11

Anscheinend übernimmt er die sbin paths nicht aber alle anderen schon ?!?! Wenn ich in der console manuell "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin/:/sbin:/bin:/usr/bin/X11" eingebe dann nimmt er es an ...... das verstehe wer will :confused:

Trotzdem danke, das war DER entscheidente Gedanke !!

FormA

carnil

16.08.04, 14:52

Hi

Nun, es kommt ja auf die Reihenfolge an, wie die entsprechenden Dateien ausgelesen wird (wo man die PATH-Variable setzen könnte):

PATH wird durch die folgenden Konfigurationsdateien in der Reihenfolge

/etc/login.defs - bevor die Shell PATH setzt
/etc/profile (startet eventuell /etc/bash.bashrc)
~/.bash_profile (startet eventuell ~/.bashrc)

gesetzt.
http://www.debian.org/doc/manuals/reference/ch-install.de.html

Vielleicht wäre das ein Ansatz, wo nach dem "Fehler" zu suchen ist?

MfG carnil

FormA

16.08.04, 15:32

Hi

Nun, es kommt ja auf die Reihenfolge an, wie die entsprechenden Dateien ausgelesen wird (wo man die PATH-Variable setzen könnte):

http://www.debian.org/doc/manuals/reference/ch-install.de.html

Vielleicht wäre das ein Ansatz, wo nach dem "Fehler" zu suchen ist?

MfG carnil

In der Tat, das wars!

Ich musste den PATH bei /etc/profiles eintragen dann gings. Frage mich nur warum das auf einmal rumgezickt hat und davor mehrere Tage ohne Probleme lief .... :confused:

Auf jeden Fall danke an alle !!!!!!

FormA

carnil

16.08.04, 15:40

Blackhawk

16.08.04, 15:56

noch ein Tipp: beim pfaderweitern immer PATH=$PATH:trallala machen...

FormA

16.08.04, 18:06

Hi

Hmm, ich sehe gerade, das ist vielleicht (ok bin nicht so experte darin, soll mich bitte jemand bestätigen, falls es stimmt) nicht so klug das in /etc/profile anzupassen ... denn dann können ja doch alle User Programme aus /sbin ausführen, was man ja nicht unbedingt möchte, im Allgemeinen?

Besser also die .profile von root richtig anzupassen?
Steht bei dir in der .profile von root folgendes?

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
export PATH

Eventuell fehlt bei dir export PATH?

Hmm, nochmals sorry für den wohl eher schlechten Tipp.

MfG carnil

if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
export PATH

mesg n

Das ist meine gesamte .profile Datei. Mit deiner Befürchtung, dass nun alle user Befehle aus /sbin ausführen können, könntest du recht haben. Zumindest die Dateiberechtigungen sprechen da mal nicht dagegen. Aber is eigentlich egal, an den Rechner kommt sowieso keiner von außen ran .... :)

Aber wenn du ne Alternative hast, die sicherer ist wäre ich auch dankbar ;)

Danke für den Tipp

FormA

carnil

16.08.04, 19:21

if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
export PATH

mesg n

Meine sieht genauso aus ...

Das ist meine gesamte .profile Datei. Mit deiner Befürchtung, dass nun alle user Befehle aus /sbin ausführen können, könntest du recht haben. Zumindest die Dateiberechtigungen sprechen da mal nicht dagegen. Aber is eigentlich egal, an den Rechner kommt sowieso keiner von außen ran .... :)

Huch sorry, irgendwie hatte ich einen Kurzschluss im Gehirn :ugly: also ob's die anderen User ja ausführen können oder nicht hängt ja von den Berechtigungen an, natürlich nicht von der PATH-Variable. Das was ich meinte ist aber einfach, dass dann "normale User" durch simple eingabe von ifconfig /sbin/ifconfig ausführen können ... also ob ob's ausführbar ist hängt natürlich von den Dateirechten ab ... sorry für die Verwirrungstiftung :)
Als Strafe stelle ich mich jetzt in die Ecke :ugly:

Aber wenn du ne Alternative hast, die sicherer ist wäre ich auch dankbar ;)
Nein, habe ich nicht direkt, aber vielleicht stimmt ja was mit den Dateiatributen von /root/.profile nicht, und deshalb wird sie nicht ausgelesen? Meine sehen so aus:

-rw-r--r-- 1 root root 202 Dec 21 1999 /root/.profile

Hmm, naja es klappt ja jetzt ...

MfG carnil

marce

17.08.04, 09:32

was auch noch sein könnte:

wie bist Du denn root geworden?

mit "su" oder mit "su -"

weil, nur mit su übernimmt er die Umgebungsvariablen von root nicht und behält die von dem ursprünglichen user... Und da fehlt /usr/sbin meist...

[so ist's zumindest bei den SuSEs hier...]

FormA

17.09.04, 15:21

Ok, ich habe herausgefunden was das Problem mit PATH verursacht. Bzw ich habe eigentlich nur herausgefunden, wie ich das Problem reproduzieren kann, die Ursache ist mir total schleierhaft.

Und zwar tritt das Problem dann auf wenn ich den SSH Port ändere und danach den Rechner neustarte. Ich weiß, dass ich den Rechner wegen SSH Port ändern nicht neustarten brauche, das Problem tritt halt immer dann auf.

Versteht das jemand ??????

FormA