Jump to content

W2K3-XP: Kopieren von Dateien >27MB unmöglich


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo aus Stuttgart,

 

ich hätt da gern mal ein Problem: Ich hab gestern 4 Stunden beim Kunden gesessen und nix erreicht. Vielleicht kann mir ja hier jemand weiterhelfen?!

 

Da steht also ein W2K3 SBS SP1 mit allen Patches, die Clients sind XP und W2K mit allen Patches. Seit ein paar Wochen kann man keine Dateien die größer als ca. 27MB sind vom Share auf nen Client kopieren. Es passiert mit W2K und XP Clients, die Clienthardware ist völlig unterschiedlich, aber in der Mehrzahl sind das ältere Dellsysteme (kleine P4).

Das Ganze sieht in etwa so aus:

Das Kopieren geht los und nach einiger Zeit bleibt der Fortschrittsbalken stehen und nochmal später heißt es dann: "Der Netzwerkname ist nicht mehr verfügbar". Je nachdem wie groß die Datei ist, werden mal 30, mal 70 oder auch 150MB übertragen, aber größer als ca. 25-27MB wird eben nicht fertig. Es gibt bei den Fehlern keinerlei Eventlogeinträge, weder Client noch Serverseitig.

 

Zu dem genauen Zeitpunkt kann ich nichts sagen, die Firma dort arbeitet hauptsächlich mit Client/Server Applikationen (JuriArc, Exchange) und einer Linuxsoftware. Die haben so gut wie keine größeren Dateien zu transferieren, nur kleine Dokumentenscans, Textdateien oder DB-Exports/Imports. Deshalb gibt es auch keinen Event oder Tag, seit dem das nicht mehr geht. Mir selbst fiel es Ende August auf, als ich ein VM-Ware Image auf einen Client kopieren wollte, auf Nachfrage stellte sich raus, dass die Probleme schon mal bei einer Installation aufgetreten waren. Ich kann leider noch nicht mal sagen, wann es definitiv noch gefunzt hat, ohne dabei gleich ein dreiviertel Jahr zurückgehen zu müssen.

 

Eigentlich wurde an dem Netz nichts verändert, außer über "automatische Updates". Die Treiber aufm Server (HP ML350 G3) sind neu (vom 25.09. heute installiert) und an größeren Umkonfigurationen wurde seit Monaten nichts vorgenommen.

 

Es gibt auch noch einen Linuxserver mit Samba3, der Mitgliedsserver der Domain ist. Mit dem gibt es die Probleme unter Samba auch, es muß also am SMB Protokoll der M$ Maschinen liegen.

 

Ich hab bis jetzt folgendes gemacht (erfolglos):

- Zeitserverfunktionalität überprüft: ok

- Zugriff aus Sysvol: ok

- DNS Funktionalität überprüft: ok

- SMB Signing nach Gruppenrichtlinien.de eingestellt (also "Immer signieren" deaktiviert): GPO wird clientseitig upgedatet

- mit KillCopy rumkopiert, Bandbreite auf ein Minimum runtergesetzt, no way!

- per ftp und netio die Netzperformance überprüft: Solange man kein SMB verwendet ist alles bestens, netio macht 10,5-11MBytes/s in nem 100MBit/s Netz. Somit kann man die physikalische Netzhardware wohl ausschließen.

- mit ethereal Kopiersessions gesnifft: Irgendwann kommen einfach keine Pakete mehr vom Client, dann erfolgt ein SMB RST (Reset), das Servershare wird neu eingelesen und in dem Moment kommt obige Meldung.

- mit WinXPTCPFix.exe die TCP/IP Konfiguration an einem Client exemplarisch zurückgesetzt - kein Erfolg.

- Auf dem Server das neue HP Support Pack mit neuen Treibern eingespielt, kein Chance!

- Auf dem Server testweise sämtliche zusätzlichen Dienste disabled: Oracle, Exchange, Blackberry etc., vergiß es!

- gegoogelt wie **** und ne Menge Threads gelesen, wo entweder Sachen faul waren, die hier funzen (Kabel, Switch etc.) oder wo es keine Lösung zum Problem gab.

 

Zu guter Letzt: man kann z.B. ein 1,7GB großes Imagefile vom Client auf den Server kopieren, aber nicht umgekehrt. Dafür kann man vom Server auf den Linuxserver kopieren, problemlos. Aber vom Server aus auf einen Client geht schon nicht mehr.

 

Auf den Systemen läuft kein Virenscanner, es werden nur Emails auf dem SMTP-Gateway vorm Exchange gescannt.

 

Ich bin mit meinem Latein grad voll am Ende, hab keine Ahnung was ich noch machen kann. Einzige Idee ist einen Client-PC neu aufzusetzen und die Patches nach und nach einzuspielen, bis der Faule auftaucht.

 

Vielleicht hat ja hier noch jemand ne Idee? Jede Hilfe ist willkommen.

 

Greetz,

Tom

Link zu diesem Kommentar

Wie sieht das LAN aus ? Haben die Server zufällig eine schnellere Anbindung als die Client's ? Was für Switche ?

 

Probiere bitte vom Client zum Server "ping server -l 65500" aus. Wenn es nicht geht und der Punkt oben zutrifft, hast Du möglicherweise ein Problem mit dem Flow Control Protokoll. Da mußt Du Dir die Switche vornehmen. Das würde auch erklären, warum es vom Client zum Server geht.

 

-Zahni

Link zu diesem Kommentar

Danke für deine Antwort.

 

Das Lan ist ziemlich einfach gestrickt, zwei 100Mbit-Switches kaskadiert (3com und Dlink, beide unmanaged), wobei an einem die beiden Server und Clients hängen, an dem anderen ein paar Drucker. Ich hab das Netz so "geerbt", auch den Server nicht selber installiert (hätt auch keinen SBS genommen), aber ich hatte schonmal angeregt die Server über Gigabit anzubinden und dazu einen großen oder zwei gescheite stackable Switches einzukaufen.

Ich kann das gerne mal mit so großen Paketen versuchen, denke aber dass die Hardware okay ist. netio hat ja Pakete bis 32k durchgekriegt, mit >11MBytes/s und ftp auf den Linux geht ebenfalls mit full speed. Auch Outlook z.B. öffnet große Attachments. Es scheint ja nur bei SMB was schiefzulaufen...

 

Greetz,

Tom

Link zu diesem Kommentar

Ich hab heute testweise die Switches durch einen unserer Reserveswitches (HP) ersetzt, und siehe da: der alte DLINK "Schalter" hat das Problem verursacht. Das Netz war auch weniger zäh mit dem HP.

Hätt ich nicht gedacht, da ja die ftp und netio performance stimmte. Und die großen Pings gingen auch!

 

Naja, jetzt wird erstmal ein schöner 48 Port Switch mit GBit für die Server angeschafft, damit sollte das Problem behoben sein.

 

Danke nochmal an Zahni, dein Tip war ausschlaggebend, Respekt!

 

Greetz,

Tom

Link zu diesem Kommentar

Das Problem ist (war): Keine der anderen Protokolle nutzen die maximale TCP-Windowsize von 64K ohne ACK aus. Anders SMB: Der Sender verschickt die volle TCP-Windowsize auf einen Schlag und erwartet erst hinterher die ACK's der fragmentierten TCP-Pakete. Das dient zur Performancesteigerung. Allerdings können so auf viel eher Pakete verloren gehen, speziell wenn ein Switch damit nicht klar kommt.

 

Der große Ping kann dies recht gut testen. Zwar mit ICMP, aber mit dem selben Ergenis. Sieht man gut in Ethereal.

 

-Zahni

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...