Springe zum Inhalt

Verschiedene NAS-Systeme unterstützen kein SMB2, welches seit Windows Vista verwendet wird. Mit folgenden Befehlen kann man SMB2 abschalten, so dass nur noch SMB1 verwendet wird (auszuführen in einer Eingabeaufforderung, die als Administrator ausgeführt wird):

sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc config mrxsmb20 start= disabled

Zu beachten ist die etwas ungewöhnliche Parameterangabe. Nach dem Gleichheitszeichen muss ein Leerzeichen folgen. "bowser" ist ebenfalls kein Schreibfehler.

Mit dem ersten Befehl wird festgelegt, dass der Arbeitsstationsdienst (lanmanworkstation) von den Diensten Bowser, MRxSmb10 und NSI abhängt. Mit dem zweiten Befehl wird der Dienst MRxSmb20 abgeschaltet. Anschließend ist ein Rechnerneustart erforderlich.

Um SMB2 wieder einzuschalten fügt man MRxSmb20 zu den Abhängigkeiten des Arbeitsstationsdienstes hinzu:

sc config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc config mrxsmb20 start= auto

Nach dieser Änderung ist wiederum ein Rechnerneustart erforderlich.

Ich zähle zu den Verückten, die das T-Online E-Mail-Paket nutzen. Ausschlaggebend für die Nutzung war, dass beim Versand eine X-beliebige Abenderadresse eingestellt werden kann. "Normale" Kunden können das auch, aber die Absenderadresse wird von T-Online beim Versand mit der T-Online E-Mail-Adresse des Kunden ersetzt. Nicht so beim E-Mail-Paket, da bleibt die vom Versender vorgegebene Absenderadresse erhalten. Soweit, so gut.

Seit kurzem fiel mir auf, dass ich E-Mails erhalte, die an meine T-Online-Adresse gerichtet waren. Wie, was, wo? Die habe ich doch niemandem herausgegeben. Ich versende immer mit einer Absenderadresse einer auf mich registrierten Domain. Und habe das E-Mail-Paket. Ein kurzer Check in den eingegangenen E-Mails brachte die Katastrophe dann ans Tageslicht. Das ging seit ca. einem Jahr schon so...

Was nun? Ok. 1. Leistungsbeschreibung von T-Online für das E-Mail-Paket checken. Punkt 1.4: Simple Mail Transfer Protocol (=SMTP) - Relayserver
Der SMTP-Relayserver ermöglicht dem Kunden E-Mails mit seiner eigenen Domain als Absenderadresse zu versenden (Beispiel: name@meine-Internetadresse.de).
. Ok. Die Leistung gibt es also noch. Ich habe keine AGB-Änderung übersehen. 2. Test-E-Mail an externe Adresse verschicken. Kommt mit T-Online-Absenderadresse an... Hm... 3. Hilfeseiten bei T-Online. Dort findet man dann bei Fragen und Antworten zum E-Mail Paket unter dem Titel Wie kann ich meine E-Mails über ein E-Mail-Programm empfangen und senden? die zum E-Mail-Versand einzustellenden SMTP-Server. Da ich ein sicherheitsbewusster Netzbürger bin, habe ich den SMTP-Server mit SSL-Verschlüsselung gewählt: securesmtp.t-online.de. Alles nochmal kontrolliert. Postfix-Transports-Tabelle genau gecheckt und mail.log angesehen. Die E-Mails werden über den richtigen Server verschickt. Hm, habe ich jetzt jahrelang für eine Leistung bezahlt, die gar nicht funktioniert? Blieb 5. nur der Griff zum Telefon, da auf der Kontaktseite bei T-Online leider keinerlei E-Mail-Adresse angegeben ist.

Es ist ca. 21:30 Uhr und von der Störungsstelle ist noch jemand da. Klasse. Ich schildere mein Problem. E-Mail-Paket wurde verstanden. Die Möglichkeit, eine eigene Absenderadresse einzustellen, die dann auch erhalten bleibt, war unbekannt. Grml. Ich las den oben genannten Punkt der Leistungsbeschreibung vor. Erstaunen am anderen Ende. Die Dame vom Support schaffte es aber blitzschnell, mich selbst in Erstaunen zu versetzen: Haben Sie denn ein Stichwort, unter dem ich in unserer Datenbank suchen könnte?. Mir fiel in dem Moment nichts besseres als SMTP-Relay ein (wobei ich Relay auch noch buchstabieren musste). Es fand sich ein Eintrag in der Datenbank: eine Anleitung für Outlook und dergleichen. Ich hörte den Ausführungen brav zu, und, was war das? Ein anderer SMTP-Servername: smtprelay.t-online.de. Ich wurde gefragt, ob ich das denn kurz ausprobieren könnte. Na, warum nicht. Meine Frage nach zwei Minuten Zeit zum Postfix einstellen waren kein Problem. Und welch Wunder. Eine Test-E-Mail behielt den eingestellten Absender. Wow, Freude auf beiden Seiten. Die Dame wollte sich auch ein "Lesezeichen" auf diesen Artikel in ihrer Datenbank setzten ;)

Später fand ich auf der gleichen Hilfeseite zum E-Mail-Paket dann noch eine Antwort auf die Frage: Welche Einstellungen sind notwendig, um SMTP-Relayserver nutzen zu können?. Dort wurde auch der richtige zu verwendende SMTP-Server angegeben. Verwunderlich ist nur, warum das in der ersten Antwort nicht so drin steht, da damit ja offensichtlich nicht alle Funktionen des E-Mail-Pakets nutzbar sind.

Also noch mal kurz und knapp: für Nutzer des E-Mail-Paketes von T-Online muss, damit die angegebene Absenderadresse von T-Online nicht umgeschrieben wird, der Postausgangssserver smtprelay.t-online.de angegeben werden.

Und die Moral von der Geschicht: auch T-Online-Support-Mitarbeiter bekommen heraus, wo der Hase im Pfeffer liegt.

Nach stundenlanger Konfiguration von Windows-Diensten oder anderen Anwendungen ist es manchmal wünschenswert, die Eventlogs von Windows zu leeren und in einen sauberen Anfangszustand zu versetzen. Unter Windows 7, Windows 2008 R2 und Windows Vista steht dazu der Befehl wevtutil zur Verfügung. Um nun nicht per Hand jedes einzelne Eventlog aus der schier unüberschaubaren Anzahl der Eventlogs der genannten Betriebssystem eingeben zu müssen, wird ein komplettes Leeren aller Eventlogs mit folgendem Befehl erreicht:

for /f "usebackq delims=" %l in (`wevtutil el`) do wevtutil cl "%l"

Informationen zu wevtutil findet man ebenfalls im Technet: Clear an Event Log. Dort wird auch folgendes Monstrum beschrieben:

wevtutil sl Application /ca:O:BAG:SYD:(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)(A;;0x3;;;S-1-5-33)(A;;0x1;;;S-1-5-32-573)(A;;0x4;;;BO)

Alles klar? ;-)

In den Standardeinstellungen ist es normalen Benutzern nicht erlaubt, SMB-Shares unter Ubuntu einzuhängen. Eine Angabe von user in der /etc/fstab reicht nicht aus.

Die Programme mount.cifs und umount.cifs müssen als Erstes das SUID-Bit gesetzt bekommen.

chmod +s /usr/sbin/mount.cifs
chmod +s /usr/sbin/umount.cifs

Wie empfohlen werden dann die Anmeldedaten in einer extra Datei gespeichert, z.B. in /etc/cifs_credentials die folgenden Aufbau hat:

username=...
password=...
domain=...

Diese Datei sollte mit entsprechenden Rechten gegen Lesen durch jedermann gesichert werden. Nur die Benutzer, die nachher die Shares mounten sollen, müssen diese Datei lesen können. Es empfielt sich also, eine extra Gruppe für diese Benutzer anzulegen und der Gruppe Leserechte auf diese Datei zu geben.

addgroup smbmounters
adduser benutzer1 smbmounters
adduser benutzer2 smbmounters
...
chgrp smbmounters /etc/cifs_credentials
chmod g+r,o-r /etc/cifs_credentidials

Anschliessend könnte ein Eintrag in der /etc/fstab folgendermaßen aussehen:

//SERVER/Freigabe /mnt/server/freigabe cifs rw,user,noauto,suid,credentials=/etc/cifs_credentials 0 3

Zu beachten ist außerdem, dass die User zum Mounten Schreibrechte auf den Einhängepunkt (hier im Beispiel /mnt/server/freigabe) benötigen, ansonsten wird ein mount-Versuch mit der Fehlermeldung

mount error: permission denied or not superuser and mount.cifs not installed SUID

verweigert.