ständiger Uplad-Fehler bei filezilla

[Linuchs]

Hallo,

beim einzelnen Hochladen von Blddateien (2 - 4 MB groß) ging gestern auf einmal nichts mehr. Filezilla meldet

Status:	reput: restarting at file position 0
error while writing: failure

und versucht das Hochladen endlos weiter, Pogramm muss abgebrochen werden.

Habe geprüft, ob auf dem Server noch freier Platz vorhanden ist: 167G Available. Mit uname -a meldet der Server

Linux osmer 2.6.32-5-amd64 #1 SMP Fri May 10 08:43:19 UTC 2013 x86_64 GNU/Linux

Beim nächsten Programmstart von Filezilla und Upload-Versuch wird gefragt, ob die Datei überschrieben werden soll. Die Datei ist mit 0 Byte bereits vorhanden.

Habe die 0-Byte-Datei gelöscht, Fehler bleibt.

Habe lokal (Ubuntu) eine System-Aktualisierung veranlasst, dieses Problem bleibt aber. Synptic meint, dass filezilla mit Version 3.7.3-1ubuntu1 aktuell ist.

Das Hochladen von Dateien auf einen anderen Server funktioniert.

Was kann die Fehler-Ursache sein?

Linuchs

[TS]

Hallo zur guten Nacht,

viel wichtiger:

die Filezilla-Version und das OS, auf dem es läuft.

Ich hatte dieses Endlosladen in den letzten Tagen auch ein paar Mal. Ich musste den Task abwürgen. Kann jetzt leider nicht gucken, welche Version es ist, weil der Rechner nicht tut...

Ber es war die letzte oder vorletzte 32 Bit

Grüße
TS

[Linuchs]

Hallo zur guten Nacht,

viel wichtiger:

die Filezilla-Version und das OS, auf dem es läuft.

Ich schrieb:

"Habe lokal (Ubuntu) eine System-Aktualisierung veranlasst, dieses Problem bleibt aber. Synptic meint, dass filezilla mit Version 3.7.3-1ubuntu1 aktuell ist."

Filezilla zeigt selbst die Version 3.7.3 an, allerdings auch "Copyright (C) 2004-2013 Tim Kosse"

Seit 2 Jahren aktuell?

Auf filezilla-project.org lese ich: 2015-06-02 - FileZilla Client 3.11.0.2 released

Linchs

[Jörg Reinholz]

Moin!

• Verwendetes Protokoll?
• ggf. Logeintrag des Servers? (z.B.) /var/log/vsftp.log ; /var/log/transfer.log

167G Available

Hm. Das ist kein normaler virtueller Server. Dehalb frag ich mal: Kann es sein, dass ein quota-Limit gesetzt wurde.

Linux osmer 2.6.32-5-amd64 #1 SMP Fri May 10 08:43:19 UTC 2013 x86_64 GNU/Linux

Wieso nur macht mir das Sorgen?

Jörg Reinholz

[Linuchs]

Moin Jörg,

• Verwendetes Protokoll?

SFTP - SSH File Transfer Protocol

• ggf. Logeintrag des Servers? (z.B.) /var/log/vsftp.log ; /var/log/transfer.log

In /var/log gibt's beide Dateien nicht.

167G Available

Hm. Das ist kein normaler virtueller Server. Dehalb frag ich mal: Kann es sein, dass ein quota-Limit gesetzt wurde.

Nein, nicht virtuell, eine eigene Hardware beim Provider (50 € mtl.)

Quota-Limit? Nie gehört oder gelesen.

Linux osmer 2.6.32-5-amd64 #1 SMP Fri May 10 08:43:19 UTC 2013 x86_64 GNU/Linux

Wieso nur macht mir das Sorgen?

Jetzt sag nicht, dass die Aufräum-Aktion (mit deiner Hilfe) Unklarheiten hinterlassen hat.

Ohne Klammern hatte der vorherige Satz zunächst einen ganz anderen Sinn ;-)

Linuchs

[Jörg Reinholz]

Moin!

In /var/log gibt's beide Dateien nicht.

/var/log/syslog

(mit deiner Hilfe)

Naja... ging es da nicht um ein Ubuntu auf Deinem Laptop in einem Update-Zustand, der meine helle Begeisterung auslöste weil ich normal funktionierende Computer langweilig finde?

Jörg Reinholz

[Linuchs]

/var/log/syslog

Datei vorhanden mit Berechtigung 640, ich komme weder mit ftp noch als normaler User mit cp dran.

Musste vor Jahren das root-Passwort ändern und habe meine Notizen offenbar nicht korrigiert. Vielleicht habe ich ja noch eine Eingebung ...

Naja... ging es da nicht um ein Ubuntu auf Deinem Laptop in einem Update-Zustand, der meine helle Begeisterung auslöste weil ich normal funktionierende Computer langweilig finde?

Genau.

Linuchs

[Jörg Reinholz]

Moin!

Musste vor Jahren das root-Passwort ändern und habe meine Notizen offenbar nicht korrigiert. Vielleicht habe ich ja noch eine Eingebung ...

Soso. Root-Konto "kaputt" und keinen anderer Zugang mit den Rechten. Generalfehler.

Genau.

Jetzt geht es aber nicht um das Laptop sondern um den Server ...

By the way:

mach das folgende von Deinem Ubuntu aus und ersetze das GROSS geschriebene durch passende Werte. Sammle die Ausgaben der Konsole bzw. des Terminals und poste diese.

~$ cat DATEI | ssh -vvv USER@SERVER "cat > /DIR/DATEI"

Um das Passwort für den Root kümmere ich mich auch noch, kann aber nichts versprechen, muss suchen. Für so alte Kernel gab es wohl mal die Möglichkeit einer Rechteexpansion. (Das war aber ein Exploit). Ich hoffe, ich finde das noch. Nur muss man dafür trotzdem eine Datei übertragen können.

Jörg Reinholz

[Linuchs]

Musste vor Jahren das root-Passwort ändern ...

Als normaler Anwender komme ich ja noch rein. Und habe mail:

mail: /tmp/mail.XXXX2NAZbb: Disk quota exceeded

$ quota -v

Dateisystemquotas für user ... (uid 1001): 
    Dateisystem Blöcke   Quota   LimitGnadenfrist Dateien   Quota   LimitGnadenfrist
/dev/disk/by-uuid/d24f66cd-85a1-40f9-af39-630467230918
                1048576* 1048576 1048576            9407       0       0

Mit den Angaben kann ich nichts anfangen. Zum Vergleich:

$ df

Dateisystem          1K‐Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
/dev/sda2            188441976   4385104 174484544   3% /
tmpfs                  1030388         0   1030388   0% /lib/init/rw
udev                   1025540        96   1025444   1% /dev
tmpfs                  1030388         0   1030388   0% /dev/shm

Falls da ein Limit ist, woher kommt das? Und wie behebe ich das?

Linuchs

[Der Martin]

Hallo,

mail: /tmp/mail.XXXX2NAZbb: Disk quota exceeded

ach, schau an. Das hatte Jörg doch schon gestern abend gemutmaßt.

Dateisystemquotas für user ... (uid 1001): 
    Dateisystem Blöcke   Quota   LimitGnadenfrist Dateien   Quota   LimitGnadenfrist
/dev/disk/by-uuid/d24f66cd-85a1-40f9-af39-630467230918
                1048576* 1048576 1048576            9407       0       0

Das ist doch eine klare Aussage: Für den Nutzer mit UID 1001 ist ein Quota-Limit von 1048576 Blöcken (also 1GB) gesetzt und bis zum letzten Block ausgereizt.

Falls da ein Limit ist, woher kommt das? Und wie behebe ich das?

Da muss ich passen; ich habe mich mit Quotas noch nie befasst. Aber vielleicht hilft dir das Ubuntu-Wiki weiter.

So long,
 Martin

[dedlfix]

Tach!

Das ist doch eine klare Aussage: Für den Nutzer mit UID 1001 ist ein Quota-Limit von 1048576 Blöcken (also 1GB) gesetzt und bis zum letzten Block ausgereizt.

Falls da ein Limit ist, woher kommt das? Und wie behebe ich das?

Der BOFH hatte da eine sehr wirksame Methode. Leider hat er nicht gesagt, was er gemacht hat ... Ungefähr ab der Hälfte beginnend bei "Ich brauche mehr Speicherplatz".

dedlfix.

[Tabellenkalk]

Hallo,

Der BOFH hatte da eine sehr wirksame Methode. Leider hat er nicht gesagt, was er gemacht hat ... Ungefähr ab der Hälfte beginnend bei "Ich brauche mehr Speicherplatz".

Im Prinzip das selbe, was er auch mit seinem Backup ganz am Anfang macht.

Gruß
Kalk

[Jörg Reinholz]

Moin!

Disk quota exceeded

Ahnte ich es doch.

quota -v -s macht es lesbarer.

Die Meldung besagt, dass

• für den Benutzer user ein Dateisystemlimit besteht, welches dafür sorgt, dass dieser nur einen Teil des Speicherplatzes auf dem Server nutzen kann. Das Limit beschränkt a) die Anzahl der Dateien und b) den Speicherplatz.
• dieses Limit überschritten wurde.

Dateien zu löschen könnte kurzfristig Abhilfe schaffen.

Was ich an Deiner Stelle tun würde:

• Backup der Daten
• Server neu installieren (Kernel 2.6 ist ein wenig "asbach" und ich vermute, Updates werden ähnlich "schwierig" wie bei Deinem Laptop.)

Der Anbieter hat dazu in seinem Kundenmenü eine "Konsole" (wird nur so genannt), die ist irgendwo dort, wo Du den Server auch neu starten kannst. Womöglich kannst Du von dort aus sogar das root-Passwort setzen.

Man kann quotas dann relativ einfach deaktivieren in dem man die mount-option aus /etc/fstab entfernt. Danach als root: mount -o remount / - und das war es dann.

Man kann auch einfach den Dienst killen ... oder quota deinstallieren. Die Frage ist, wer hat das gesetzt und warum ist das gesetzt?

eigene Hardware beim Provider (50 € mtl.)

Offensichtlich wird da Geld (600 € per anno) für Ressourcen ausgegeben, die definitiv nicht genutzt werden - denn das Quota gewährt nur die Nutzung einen kleinen Teils der Kapazität.

Jörg Reinholz

[Jörg Reinholz]

Moin!

Offensichtlich wird da Geld (600 € per anno) für Ressourcen ausgegeben, die definitiv nicht genutzt werden - denn das Quota gewährt nur die Nutzung einen kleinen Teils der Kapazität.

Jahreszeitlich bedingt (im Herbst und Winter, also zwischen September und Januar, käme ich nicht mal auf die Idee, jemanden auf die Idee zu bringen) würde ich sogar empfehlen, sich kompetenter Hilfe zu versehen, wenn man einen solchen Server mit Internetanbindung betreiben will.

Jörg Reinholz

[Linuchs]

Dateien zu löschen könnte kurzfristig Abhilfe schaffen.

Ja, ich habe ein 4 MB Foto gelöscht, jetzt geht wieder was.

• Server neu installieren (Kernel 2.6 ist ein wenig "asbach" und ich vermute, Updates werden ähnlich "schwierig" wie bei Deinem Laptop.)

Ich werde einen Teufel tun. Das Ding steht nicht bei mir und ich befürchte, die Verbindung zu mir zu kappen. Wenn schon nach 3% des Plattenplatzes Schluss ist, woher soll ich dann all die anderen ungeschriebenen Regeln kennen?

Provider hat sich gemeldet:

"am einfachsten wäre es mit einem SSH-Key zu arbeiten, d.h. Sie erstellen einen SSH Key (z.B. mit Putty), den wir hinterlegen. Den können sie auch im FTP-Programm etc verwenden. siehe auch: [1]https://www.howtoforge.de/anleitung/key-basierte-ssh-logins-mit-putty/

Dann können Sie sich als root einloggen, unabhängig vom jeweiligen Passwort. Das wäre die sichere Variante. Ansonsten müssten wir ein neues Passwort setzen."

Linuchs

[Jörg Reinholz]

Moin!

Dateien zu löschen könnte kurzfristig Abhilfe schaffen.

Ja, ich habe ein 4 MB Foto gelöscht, jetzt geht wieder was.

• Server neu installieren (Kernel 2.6 ist ein wenig "asbach" und ich vermute, Updates werden ähnlich "schwierig" wie bei Deinem Laptop.)

Ich werde einen Teufel tun. Das Ding steht nicht bei mir und ich befürchte, die Verbindung zu mir zu kappen. Wenn schon nach 3% des Plattenplatzes Schluss ist, woher soll ich dann all die anderen ungeschriebenen Regeln kennen?

Es sind stets "geschriebene Regeln", denn die stehen "irgendwo". Sonst würde die auch der Server selbst nicht kennen und also nicht befolgen.

Provider hat sich gemeldet:

"am einfachsten wäre es mit einem SSH-Key zu arbeiten, d.h. Sie erstellen einen SSH Key (z.B. mit Putty), den wir hinterlegen. Den können sie auch im

1.) Haben die eigentlich geschrieben, dass die nur den Pub-Key brauchen? Falls nicht: Ich hab das soeben getan.

2.) Nice. Der Provider kann sich also mit root-Rechten Zugriff auf das Dateisystem verschaffen. Hatte ich schon angedeutet - auch wenn ich dachte, der bietet für den Passwort-Wechsel des roots eine Funktion in der Serververwaltung an.

Hinweis: Mach das, aber teste den key erst mal mit Ubuntu. Und überlege Dir das mit der Update-Politik. Die Software eines Servers nicht zu aktualisieren, weil man Angst um die Verbindung zu demselben hat, kann gerade dazu führen, dass man diese verliert. Oder den ganzen Server an Typen, die lustige Sachen machen, wie ins "Parlakom" einbrechen - und rate mal wer dann beim Staatsschutz auf dem heißen Stuhl sitzt und die Nächte bestenfalls in der U-Haft-Zelle verbringt.

Jörg Reinholz

[Jörg Reinholz]

Moin!

Noch was: Das Schlüsselpaar ausdrucken und beim Chef in den Safe legen.

Jörg Reinholz

[Linuchs]

Man kann quotas dann relativ einfach deaktivieren in dem man die mount-option aus /etc/fstab entfernt. Danach als root: mount -o remount / - und das war es dann.

root-Passwort neu bekommen und geändert.

Datei fstab:

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/sda2  /  ext3  grpquota,suid,dev,usrquota,exec  0  1
# UUID=d24f66cd-85a1-40f9-af39-630467230918  /  ext3  grpquota,suid,dev,usrquota,exec  0  1
# /dev/sda5       none            swap    sw              0       0
UUID=b296f5bc-40b6-48d0-96e8-4086dd1e0c62       none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0

Was ist da zu ändern?

Linuchs

[Linuchs]

habe die quota hochgesetzt mit

edquota -u [username]

und dann

mount -a

Problem gelöst, es lassn sich weitere Bilder hochladen.

Danke für deine Hilfe.

Linuchs

[Jörg Reinholz]

Moin!

/dev/sda2 / ext3 grpquota ,suid,dev, usrquota ,exec 0 1

Du wolltest die quota loswerden. Was wird man da wohl machen? Vor allem unter dem Aspekt, dass diese beiden Einträge in der Options-Spalte von fstab stehen müssen, damit die quota für das jeweilige Dateisystem aktiviert werden?

Jörg Reinholz

[Linuch]

Moin!

nach zwei, drei hochgeladenen Bildern meldet filezille wieder

Fehler:	error while writing: failure

Du wolltest die quota loswerden. Was wird man da wohl machen? Vor allem unter dem Aspekt, dass diese beiden Einträge in der Options-Spalte von fstab stehen müssen, damit die quota für das jeweilige Dateisystem aktiviert werden?

die /etc/fstab habe ich geändert auf:

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# 2015-06-23 osmer quota aufgehoben
# proc            /proc           proc    defaults        0       0
# /dev/sda2  /  ext3  grpquota,suid,dev,usrquota,exec  0  1

# UUID=d24f66cd-85a1-40f9-af39-630467230918  /  ext3  grpquota,suid,dev,usrquota,exec  0  1
# /dev/sda5       none            swap    sw              0       0
UUID=b296f5bc-40b6-48d0-96e8-4086dd1e0c62       none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0

und danach das Kommando

mount -o remount /

abgeschickt. Doch der filezilla Fehler bleibt.

Linuchs

[Der Martin]

Hallo,

nach zwei, drei hochgeladenen Bildern meldet filezille wieder

Fehler:	error while writing: failure

naja, ich weiß ja nicht, um wieviel du das Quota-Limit hochgesetzt hast.

die /etc/fstab habe ich geändert auf:

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# 2015-06-23 osmer quota aufgehoben
# proc            /proc           proc    defaults        0       0
# /dev/sda2  /  ext3  grpquota,suid,dev,usrquota,exec  0  1

# UUID=d24f66cd-85a1-40f9-af39-630467230918  /  ext3  grpquota,suid,dev,usrquota,exec  0  1
# /dev/sda5       none            swap    sw              0       0
UUID=b296f5bc-40b6-48d0-96e8-4086dd1e0c62       none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0

Ist das dein Ernst? Du hast jetzt nicht etwa den mount-Eintrag für /dev/sda2, dein root-Filesystem, komplett auskommentiert?! Wundert mich, dass dein System überhaupt noch läuft. Wolltest du nicht einfach nur die quota-Flags aus den mount-Optionen entfernen?

So long,
 Martin