Systemfehler 53 kehrt immer wieder zurück

bitmuncher

Senior-Nerd
Gegeben ist ein Netzwerk bestehend aus Windows-XP-Clients und einem Fileserver. Einige der Clients haben immer wieder den berühmten Systemfehler 53, wenn sie ein Netzlaufwerk des Fileservers einhängen wollen. Abhilfe schafft in einigen Fällen ein Socket-Reset:

Code:
netsh int ip reset c:\resetlog.txt
netsh winsock reset catalog

Die Laufwerke selbst werden mittels

Code:
net use z: \\fileserver\freigabename passwort /user:benutzer

eingehängt. Diese Befehle liegen in einer bat-Datei, die die User im Autostart haben. Bei einigen Clients hilft der Socket-Reset aber nur temporär und schon beim nächsten Reboot ist der Systemfehler 53 wieder da. Bei anderen Clients reicht es den Socket-Reset einmalig auszuführen und wiederum andere haben das Problem überhaupt nicht. Hat jemand eine Idee, wie man den dauerhaft beseitigt bekommt?
 
Ich hatte heute das Problem, dass ein Netzlaufwerk erst verzögert eingebunden werden konnte, weil Windows mit seinem Netzwerk noch nicht so weit war (generelle Verfügbarkeit, DNS, Verhandlung mit Workgroup-Master oder DHCP).
Eventuell hilft ein kurzer Loop im Script um sicherzugehen, dass der Fremdrechner z. B. anpingbar ist und dann erst die Verbindung hergestellt wird.
(sehr schön z.B. über Autoit lösbar).

Der übergebene Benutzername, könnte mehrmals vorhanden sein z. B. Administrator als administrator@localhost und als administrator@domain.local und XP ist sich nicht selten unsicher, welchen Namen es in einem solchen Fall nehmen soll. Eventuell einmal die Domain bzw. den Rechnernamen für den Benutzernamen mit in die Bash-Zeile einbauen.

lG

Brabax
 
Das Netzwerk nutzt keine Domain, alles arbeitsgruppenbasiert. Der Fileserver wird über die IP angesprochen. Ein Problem mit der Namensauflösung kann also nicht vorliegen. Der Systemfehler tritt auch noch auf, wenn der Rechner bereits alles im Netz problemlos erreichen und den Fileserver auch pingen kann. Da es nach einem Winsock-Reset bis zum nächsten Reboot wieder funktioniert, würde ich das Problem auch eher dabei irgendwo vermuten, hab nur keine Idee wo genau. Es kann aber den Usern nicht zugemutet werden jeden Tag erstmal einen Winsock-Reset durchzuführen, der ja auch jedes Mal einen Reboot notwendig macht.

Edit: Da keine Systemaccounts genutzt werden (Fileserver ist eine Terastation), schliesse ich doppelte Benutzernamen auch aus.
 
wurde auf die Clients in letzter Zeit irgendwelche Software neu installiert / geupdatet, die vielleicht irgendwelche Netzwerkfunktionalitäten hat und da irgendwo etwas hart am Netzwerk rumpfuscht?

Ich hatte mal ein ähnliches Problem, nachdem ich in 'ner VM mit WinXP die 30-Tage-Trial von Adobe CS2 oder CS3 oder so installiert hatte (das hat ja auch irgendwelche sonst wie dollen Netzwerk-Features...) und seit dieser Installation haben meine dort eingerichteten Netzlaufwerke gesponnen...
Was genau da bei mir für Fehler war, kann ich nicht mehr sagen, hab die VM irgendwann wieder gelöscht, nachdem die Testzeit rum war...
 
Liegen die Clients in unterschiedlichen Netzwerkteilen?
Falls ja gibt es dort irgendwelche Bottelnecks?
 
Ich weisz zwar nicht, ob es hilft, aber schau mal folgendes:
Wir hatten neulich ein Problem beim Mappen, das dadurch entstand, dass ein gewisses Programm, den svchost zum überlaufen gebracht hat (sah erst nach einem Zufallsfehler aus) und Windows dadurch scheinbar grundlos die Laufwerke nicht mappen wollte.
Nach dem wir den svchost entlastet hatten, also die Software deinstalliert, lief alles wieder. Alle übrigen Netzwerkdienste funktionierten übrigens einwandfrei.

Ich weisz nicht genau, was beim Socket-Reset alles geschieht, aber theoretisch startet er dann auch die entsprechenden Services neu, was dieser Theorie zu Gute käme.

lG

Brabax
 
Also für einen Rechner konnte ich das Problem nun lösen. Die Firewall von AVG Antivirus hat die Verbindung geblockt. Firewall aus... Problem gelöst. Ob das auch bei den anderen Rechnern das Problem ist, wird sich morgen zeigen.
 
Zurück
Oben