ubuntuusers.de

Hallo,

ich habe ein sehr merkwürdiges Problem mit vsftpd. Der Server ist so eingerichtet das sich lokale User mit Usernamen und Passwort anmelden können. Wenn Dateien via FTP zum Server geschickt werden funktioniert das einwandfrei. Die Dateien sind unbeschädigt. Werden diese Daten jedoch heruntergeladen, so sind sie unbrauchbar. Die Dateigröße stimmt zwar mit dem Original überein, sie lassen sich aber nicht öffnen. Das betrifft alle Binärdateien (Videos und auch pdf's und Programme. Ich habe verschiedenen FTP Clients unter Windows und Linux ausprobiert und als Übertragungsformat sowohl Auto als auch Binär eingestellt, aber ein Download mit brauchbaren Dateien gelingt mir nicht. Hat da jemand eine Idee?

Das - mit Verlaub - ist ein höchst merkwürdiger Fehler. 😕

Ẃie sieht denn der Datenschrott aus? D.h. lässt sich eine Regelmäßigkeit in der Verhunzung feststellen?

Ich habe mal die Datei auf dem ftp Server und die heruntergeladenen Datei in einem Hex Editor geöffnet, es handelt sich um eine .mov Video Datei.

Hier der Screenschot mit der funktionierenden Datei auf dem FTP Server:

Hier der Screenschot mit der verhunzten Datei vom Client:

Ich konnte noch keine Regelmäßigkeit feststellen oder ein Schema nach dem die Daten beim Download verändert werden

Zumindest in diesem Beispiel sind bis Byte 0x41 Daten am Anfang hinzugefügt worden. Jetzt ist die Frage: ist das immer so? Handelt es sich immer um die selbe Sequenz?

Falls ja: ein Verdächtiger könnte in der /etc/vsftpd.conf die Variable ftpd_banner sein. Kommentiere diese mal aus.

Hallo pepre,

bin etwas spät mit meiner Antwort, wegen des 10.10 Releases war das Forum nicht erreichbar, und dann war ich längere Zeit unterwegs.

Es ist in der Tat so das bei jeder Datei die Bytes am Anfang hinzugefügt wurden. Im weiteren Verlauf habe ich festgestellt das sich dass alle 2098 Bytes wiederholt. Da sich aber die Dateigröße nicht ändert werden auch Bytes weggelassen. Wenn ich mit kleinere Dateien hantiere (< 2kB) tritt der Fehler nicht auf.

Hallo zusammen,

bei mir ist das gleiche Problem aufgetreten. Wenn ich Daten auf den FTP-Server hochlade, dann bleiben die Daten intakt. Beim Herunterladen der Dateien wird wie bei dwvm3 der Dateiinhalt abgeändert. Im Anhang befindet sich mal als Beispiel eine Bilddatei (links das Original und rechts die defekte Datei). Die "falsche" Zeichenfolge ist mehrmals in der Datei auffindbar. Die Größen beider Dateien sind jedoch gleich.

Greife ich direkt vom Server über die lokale IP zu, treten keine Fehler auf. Von extern (über einen DynDNS-Anbieter, sowie von einem netzwerkinternen PC mittels lokaler IP) funktioniert es schon nicht mehr. Die Übertragung schaltet laut FTP-Programm (FireFTP-Plugin) automatisch auf binär um. Wie schon gesagt funktioniert es bei kleinen Testdateien problemlos.

Ich habe einen vsftpd Server unter Ubuntu 10.04 laufen. Die Config-Datei von vsftpd hab ich mit in den Anhang geladen. Der Fehler ist erst vor einiger Zeit aufgetreten. Davor hat es definitiv funktioniert. Könnte es am Router liegen (Port 21 TCP freigegeben)? Es läuft parallel dazu auch noch ein Samba-Server, welcher problemlos funktioniert. Mir ist auch aufgefallen, dass beim Zugriff auf den FTP-Server mittels Windows- oder Internet-Explorer das Loginfenster nicht mehr erscheint. Es kann nur mit direkter Eingabe der Benutzerkennung in der Adresszeile zugegriffen werden. Kann das damit zusammenhängen?

Langsam bin ich echt ratlos. Ich bin über jede Hilfe dankbar.

Beste Grüße Robbi

RobbiM schrieb:

Die Übertragung schaltet laut FTP-Programm (FireFTP-Plugin) automatisch auf binär um. Wie schon gesagt funktioniert es bei kleinen Testdateien problemlos.

Versuch mal mit Filezilla im binär-Modus.

Hallo,

das habe ich soeben probiert. Leider gleiches Ergebnis. Der Log in Filezilla sagt alles ok, aber Datei ist fehlerhaft.

RobbiM schrieb:

Der Fehler ist erst vor einiger Zeit aufgetreten. Davor hat es definitiv funktioniert.

Welche Version des vsftpd benutzt Du? Hast Du ein update gemacht oder an der Konfiguration des vsftpd etwas geändert?

Ich benutze laut der Synaptic Paketverwaltung die Version 2.2.2-3ubuntu6. Ich führe immer wieder die vorgeschlagenen Updates mit Freigabe für die Langzeitunterstützung aus, kann aber nicht sagen, wann es den vsftpd mal aktualisiert hat. An der Konfiguration habe ich nichts verändert.

Versuch mal einen Download der großen Bilddatei, mit einem nichtgraphischen ftp-Client (im Terminal), z. B. wget im binär-Modus.

Das habe ich gerade getestet, allerdings das gleiche Ergebnis. Hier die Ausgabe:

svradm@server:/media/speicher$ wget ftp://[***]/image.jpg --ftp-user=[***] --ftp-password=[***]
--2011-03-20 13:42:12--  ftp://[***]/image.jpg
           => »image.jpg«
Auflösen des Hostnamen [***]... *.*.*.*
Verbindungsaufbau zu [***]|*.*.*.*|:21... verbunden.
Anmelden als robbi ... Angemeldet!
==> SYST ... fertig.    ==> PWD ... fertig.
==> TYPE I ... fertig.  ==> CWD nicht notwendig.
==> SIZE image.jpg ... 496183
==> PASV ... fertig.    ==> RETR image.jpg ... fertig.
Länge: 496183 (485K) (unmaßgeblich)

100%[===================================================================================================================>] 496.183     1,52M/s   in 0,3s    

2011-03-20 13:42:12 (1,52 MB/s) - »image.jpg« gespeichert [496183]

Könnte dieses Problem auch mit der Hardware zusammenhängen? Ich habe vor einiger Zeit das System umgebaut und nutze jetzt das Onboard Gigabit LAN (Atheros AR8131) von einem Asus M4A78LT-M LE (Chipsatz: AMD 760G). Ich habe Ubuntu Alternate neu aufgespielt und kann nicht sagen, ob das Problem direkt nach dem Umbau schon bestand, da der FTP-Server im Download sehr selten genutzt wird. Das Herunterladen vom localen FTP-Server (über die IP-Adresse) direkt vom Server aus, funktioniert. Sobald die Übertragung über das Netzwerk läuft, funktioniert es nicht mehr (auch direkt vom Server aus über DynDNS nicht).

So ... Problem geklärt. Es lag am Netzwerkkartentreiber (Atheros AR8131). Ich habe die neueste Version vom Hersteller kompiliert. Und siehe da, der FTP-Upload funktioniert wieder. 👍

Vielen Dank für Eure Bemühungen.