Server 10.4.8 Logfile füllt Platte komplett

Hallo zusammen
Ich habe hier einen Server vor mir, der seit einer Woche die log.smbd des Samba - Serverdienstes aufbläht, bis die Systemplatte komplett belegt ist. Also bis auf das letzt Byte gefüllt ist und der Rechner dann hängt.
Nach einem Neustart manifestiert sich dann die Datei als log.smbd.old in einer Grösse von 105 GB !!!!
Anschauen kann man die Datei dann nicht mehr Konsole streicht die Segel.
Da hilft nur noch löschen das log zu löschen.
Bedenklich ist ja, dass der Server überhaupt solche Dateien aufbaut bis er absteht.
Wie kriege ich das nun weg? Kann man die Grösse der Protokolldatei irgendwie beschränken?

Danke für eure Rückmeldung
smartfiles

 

Ich habe auf meinen OSX Servern keine Möglichkeit gefunden, diese Logdatei in einer Grafischen Oberfläche von der Größe her einzustellen.

Entweder du gehst ins Terminal...

Oder du löscht die datei mit den voreinstellungen - beim nächsten Start sollte es dann wieder klappen.

 

hallo, smartfiles,


ich kenne smb nur von linux, nicht vom Mac, aber in der smb.conf findet man ähnliches; versuch es doch mal mit dem setzen des parameters "max log size" in der smb.conf:

Code:

       max log size (G)

              This option (an integer in kilobytes) specifies the max size the log file should grow to. Samba periodically checks the size and if it is exceeded it will rename the file, adding a .ol
d extension.

              A size of 0 means no limit.

              Default: max log size = 5000

              Default: max log size = 1000

hth

.

 

In Server Admin kann man über Einstellungen die Protokollgrösse festlegen. Die ist dort auf Standart 10000 Bytes eingestellt.
Ich habe zwischenzeitlich mal das Combo 10.4.8 drüber gebügelt. Seither hat sich die Sache wieder beruhigt. Bin aber gespannt, wie die Sache wieder in einer Woche aussieht.

Gruss smartfiles

 

Schlechte Nachrichten
Der Server hat sich wieder über Weihnachten bis auf das letzte Byte auf der Systemplatte mit dem Logfile log.smbd zugemüllt.
Leider konnte ich den Tip von lasseboo nicht umsetzen, da ich das Unix - Einstellungsfile nicht gefunden habe.
Ich hatte eine Zeitlang ruhe, als ich die Verbindungsanzahl für Windows auf 10 Verbindungen gesetzt hatte. Leider konnten sich dann nach 3 Tagen die zwei User nicht mehr anmelden. Habe dann die Beschränkung wieder auf unbegrenzt gesetzt.

Ich habe nun den Verbindungsanzahl wieder begrenzt. Diesmal auf 500
Weiter für der Server jede Samstagnacht einen Neustart durch.

Wenn sich die Sache nicht beruhigt, werde ich um ein neues Aufsetzen des Rechners nicht drum rum kommen.

Hat noch jemand Tips zu den überlaufenden Log-Files?

Danke für eure Antworten
Gruss smartfiles

 

et voila:

Code:

intel-mac-2:~/scripte lars$ sudo find /private -name smb.conf
/private/etc/smb.conf

und dann z.b. per

Code:

pico smb.conf

öffnen und bearbeiten; viel erfolg!


.

 

.


andererseits - wenn ich nochmal nachlese, was du anfänglich schriebst: *warum* baut das ding überhaupt solch aufgeblähte logfiles ... ?

versuche doch mal, die log.smbd zu öffnen, solange es noch geht. was steht dann drin?


.

 

Bis ich da am Server bin ist es meist zu spät, da ich diesen nur aus 100 km Entfernung betreue. Die Log ist dann mit 105 Gb zu gross um sie noch laden zu können, da auch der Plattenplatz bis auf das letzte Byte belegt ist.
Unter Tages laufen da ziemlich viele Loginversuche rein, obwohl Port 139 geschlossen ist für die Anmeldung von aussen.
Nach Rücksprache mit dem Lieferanten des Servers hat mir dieser geraten den Server frisch aufzusetzen, da der Passwortmanager vermutlich einen Schuss hat und diese Probleme mit dem ausufernden Logs verursacht.
Werde aber mal deinen Rat übers Terminal versuchen.

Gruss smartfiles

 

.

aha? noch nie gehört bis jetzt ...

neu aufsetzen schadet sicher nie, man wird dadurch aber nicht unbedingt schlauer ...

du könntest vielleicht noch nach löschen der log-datei mal für eine zeit folgendes versuchen:

Code:

 tail -f /private/var/log/samba/log.smbd 

und ein tcpdump auf deine netzwerkschnittstelle wäre vielleicht auch mal interessant, und ganz allgemein ein mitschnitt der system-messages.

139 allein nützt nichts, du musst auch 137:138 sowie 445 überwachen bzw. blocken.

klingt ausser nach einem Bug auch nach einem hack-problem, und gehackt werden kann man auch aus dem LAN ;-)

.

 

Hier mal ein kleiner Ausschnitt aus dem log.smbd von gerade vorhin:
(habe nun auch die Ports 137 und 445 nach aussen geschlossen. Intern sind sie noch offen. 138 war schon zu)

 

.

ok; wieso hast du probleme mit dem account "ADMIN"?

wer nutzt den?


gib doch mal folgendes hier an:

smbtree

smbstatus

schau doch mal, ob du dies hier reproduzieren kannst:

Code:

intel-mac-2:~/scripte lars$ sudo smbpasswd admin
New SMB password:
Retype new SMB password:
odssam_getsampwnam: [0]get_sam_record_attributes dsRecTypeStandard:Users no account for 'admin'!
Failed to find entry for user admin.
Failed to modify password entry for user admin

das alles im Terminal, as usual ... ;-)

.

 

Hallo lasseboo
Danke dass du dich hier so reinhängst. Werde das mit den Terminalbefehlen heute mal austesten. Bin gestern nicht mehr dazugekommen.
Den ADMIN gibts nicht für den Server. Wie auch nicht ADMINISTRATOR mit dem der Hacker von aussen versucht in den Rechner zu kommen.

Wie es auch scheint, kennst du dich mit den Tiefen des Unix auf den Servern aus. Ich dagegen komme eher von der Anwenderseite und habe da weniger Erfahrung vom Terminal.

Noch so zur Info: Der Server der hier unter Beschuss ist, steht in einer Arbeitsgruppe mit 4 Personen als File-Server und stellt die Verbindung ins Internet für das Büro her. Er bildet das NAT / DHCP sowie die Firewall für das interne LAN an der zweiten Netzwerkschnittstelle. Die DNS wird über den ISP bezogen.

Sobald jemand da wieder im Büro ist, werde ich mal per VNC auf den Rechner zugreifen. ;-)

Gruss smartfiles