staging.inyokaproject.org

kein Datei-Upload mehr möglich

Status: Gelöst | Ubuntu-Version: Kein Ubuntu
Antworten |

Brilonese

Anmeldungsdatum:
30. März 2023

Beiträge: 9

Guten Abend,

ich verwende mehrere PHP-Skripte, u.a. ein Dokumentenmanagement-System. Bei allen Skripten können keine Dateien mehr mit Drag_and_Drop oder auch durch Auswahl vom Dateiexplorer hochgeladen werden. Ich erhalte im DMS die Fehlermeldung: "Das Hochladen einer Datei ist fehlgeschlagen. Bitte überprüfen Sie die maximale Dateigröße für Uploads.". Bei dokuwiki lediglich "Upload failed". Vorausgeschickt sollte ich mitteilen, dass der Server seit gut 10 Jahren läuft und permanent geupdated wurde. Daher läuft auf dem Server derzeit PHP 8.4 und natürlich wurde vor gut 10 Jahren die php.ini angepackt und dort upload_max_filesize und post_max_size auf 256M (256 MB) gesetzt. Auch wenn ich das ganze prüfe:

1
2
grep -r upload_max_filesize /etc/php/8.2/apache2
/etc/php/8.2/apache2/php.ini:upload_max_filesize = 256M

passt das. Eine Veränderung hatte ich auch nicht vorgenommen. Gestern musste der Server jedoch aufgrund eines geplanten Stromausfalls heruntergefahren werden und wurde im Anschluss wieder neu gestartet. Das funktionierte wunderbar, jedoch können heute keine Dateien mehr upgeloaded werden. Auf der Platte ist noch mindestens 1 TB Platz - daran liegt´s auch nicht. auch php.info zeigt 256 MB als upload_max_filesize In den Log-Dateien kann ich keine errors ersehen ... Kann mir jemand weiterhelfen?

Moderiert von schwarzheit:

Dem Spamfilter entrissen.

Brilonese

(Themenstarter)

Anmeldungsdatum:
30. März 2023

Beiträge: 9

Nach nunmehr einer Weile bin ich dem Problem auf die Spur gekommen. Zum Dateiupload wird freier Speicherplatz auf einem temporären Verzeichnis im Stammverzeichnis benötigt. Nur dort ist der freie Speicherplatz gleich 0 Byte. Die Überprüfung des Speicherplatzes zeigt

du -h --max=1 -x / 2>/dev/null | sort -h

an, dass nur etwa 4 GB der Festplatte belegt ist (ist auch so zutreffend).

Jedoch zeigt

df -h

an, dass die gesamte Platte voll ist:

Filesystem      Size  Used Avail Use% Mounted on
udev            1.6G     0  1.6G   0% /dev
tmpfs           760M   11M  749M   2% /run
/dev/mmcblk0p2   29G   28G     0 100% /
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           5.0M   16K  5.0M   1% /run/lock
/dev/mmcblk0p1  510M   66M  445M  13% /boot/firmware
/dev/sda1        57G   31G   23G  58% /home/www-data
/dev/sdb1       232G   47G  174G  22% /home/backup
tmpfs           380M     0  380M   0% /run/user/1000

Wer kann mir weiterhelfen, wie ich den Speicher wieder frei kriege.

schwarzheit Team-Icon

Supporter
Avatar von schwarzheit

Anmeldungsdatum:
31. Dezember 2007

Beiträge: 5329

Systempflege

Kann aber sein das es dafür schon zu spät ist.

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 9837

Brilonese schrieb:

[…]

Filesystem      Size  Used Avail Use% Mounted on
[…]
/dev/mmcblk0p2   29G   28G     0 100% /

Root ist voll. Du musst in ein Wartungssystem booten und offline etwas im kranken Root-Dateisystem löschen. Möglicherweise geht es auch im Single-User-Mode.

Brilonese

(Themenstarter)

Anmeldungsdatum:
30. März 2023

Beiträge: 9

Vielen Dank für die Rückmeldung.

Ich konnte nunmehr erkennen, dass ein eingebundener Datenträger offenbar "kopiert" wurde. Wenn der Datenträger abgesteckt wurde, waren die Daten "immernoch" im Verzeichnis.

Kreuzschnabel

Anmeldungsdatum:
12. Dezember 2011

Beiträge: 1768

Brilonese schrieb:

Ich konnte nunmehr erkennen, dass ein eingebundener Datenträger offenbar "kopiert" wurde. Wenn der Datenträger abgesteckt wurde, waren die Daten "immernoch" im Verzeichnis.

Dann hattest du ihn nicht gemountet, und die Daten wurden in den Mountpunkt geschrieben. Ist mir auch schon passiert ☺

Das müsste sich ja unter /media/<user>/ finden und löschen lassen.

--ks

Antworten |