Nextcloud zeigt keine Bilder mehr: Wie ein CIFS-Stall das ext4-Journal killte

Das Problem

Du öffnest deine Nextcloud auf cloud.deathstar.lan und die Foto-Galerie ist… leer. Keine Thumbnails, nur graue Kacheln. Die Dateien sind laut Dateiliste noch da, aber Vorschaubilder werden keine mehr generiert. Uploads schlagen fehl oder hängen.

Erster Reflex: Platte voll. Du loggst dich ein:

df -h /mnt/nextcloud

Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0      393G  364G   9.8G  98% /mnt/nextcloud

98% voll. Da ist es ja. Schnell aufräumen und gut.

Falsch. Das ist die Fehlspur, die dich zwei Stunden kostet.

Die Diagnose

Bevor du blind Versionen löschst: Prüf erstmal, ob das Dateisystem überhaupt noch schreiben kann.

1. Ist das FS read-only?

mount | grep /mnt/nextcloud

Bad Output (Problem):

/dev/loop0 on /mnt/nextcloud type ext4 (ro,relatime)

Da steht ro. Read-only. Nextcloud kann keine Thumbnails schreiben, keine Uploads ablegen, keine Datenbank-Locks setzen. Das „keine Bilder"-Symptom ist nur die Spitze.

2. Stimmt die Platte wirklich?

Vergleich mal du gegen df:

du -sh /mnt/nextcloud
df -h /mnt/nextcloud

70G     /mnt/nextcloud      # du sagt 70G
...393G  364G  98%           # df sagt 364G belegt

70G real, aber df meldet 364G? Das ist kein echter Speicherverbrauch — das ist ein Artefakt eines abgestürzten Loop-Devices. du überspringt Verzeichnisse, die I/O-Errors werfen, und zählt sie nicht mit. Die 98% sind eine Lüge des sterbenden Dateisystems.

3. Was sagt der Kernel?

Hier liegt die Wahrheit. Auf dem Host (nicht im Container):

dmesg | grep -iE 'loop0|EXT4|CIFS|I/O error' | tail -20

Bad Output (Problem):

CIFS: VFS: Server dc-vader.deathstar.lan has not responded in 120 seconds. Reconnecting...
blk_update_request: I/O error, dev loop0, sector 12345678
EXT4-fs (loop0): Delayed block allocation failed for inode 42 (I/O error)
EXT4-fs error (device loop0): ext4_journal_check_start: Detected aborted journal
EXT4-fs (loop0): Remounting filesystem read-only

Da ist die komplette Kausalkette in fünf Zeilen:

Der CIFS-Server antwortet nicht (Netzwerk-Stall)
Das Loop-Device verliert sein Backing → I/O-Error
Die ext4-Journal-Buchhaltung bricht ab
ext4 macht das einzig Sichere: remount read-only

Nicht die Platte ist voll. Das Netzwerk hat gehustet, und die Storage-Architektur hat es mit einem read-only-Dateisystem quittiert.

Die Architektur (und warum sie fragil ist)

So sah der Storage-Stack aus — ein typisches „ich häng die Nextcloud-Daten an eine günstige Storage Box"-Setup:

Hetzner Storage Box
   └── CIFS-Mount auf dem Proxmox-Host (dc-vader)
        /mnt/storagebox   (soft, vers=3.0, retrans=1)
        └── vm-66-disk-0.raw   (400G RAW-Image)
             └── als loop0 gemappt
                  └── ext4
                       └── in den Container gereicht → /mnt/nextcloud

Vier Schichten Storage-Indirektion, und alle hängen an einer einzigen Netzwerkverbindung. Das Problem steckt in den Mount-Optionen:

soft,vers=3.0,retrans=1

Das perfide

soft und retrans=1 sind zusammen ein Selbstmord-Pakt für dein Dateisystem.

soft bedeutet: Wenn der Server nicht antwortet, gibt der Mount nach kurzer Zeit einen I/O-Error an die aufrufende Schicht zurück (statt ewig zu warten).
retrans=1 bedeutet: genau ein Wiederholungsversuch, dann Fehler.

Klingt vernünftig — „lieber ein Fehler als ein Hänger". Aber darüber liegt ein Loop-Device mit ext4. Und ext4 interpretiert einen I/O-Error von unten als „meine Platte ist kaputt" und schaltet in den read-only-Notmodus. Ein 2-Sekunden-Netzwerk-Schluckauf zur Storage Box reicht, um ein gesundes Dateisystem lahmzulegen.

Das Verhalten ist:

✅ Dokumentiert (die mount.cifs-Manpage sagt es klar)
❌ Aber nicht intuitiv (ein Netzwerk-Timeout wird zu „Festplatte read-only")
❌ Schwer zu debuggen, weil df dich zur falschen Ursache (volle Platte) lockt

Die Lösung

Sofort: Wieder beschreibbar werden (ohne Datenverlust)

Nicht einfach mount -o remount,rw. Erst sauber runterfahren, sonst fsck’t du über ein instabiles CIFS. Reihenfolge:

# 1. Nextcloud in den Wartungsmodus (DB-Flag, geht trotz ro-FS)
docker compose exec -u www-data app php occ maintenance:mode --on

# 2. Container/Dienst stoppen
docker compose stop

# 3. Auf dem HOST: den Container stoppen, damit loop0 sauber gelöst wird
pct stop 66

# 4. CIFS neu mounten — diesmal HART
umount /mnt/storagebox
mount -t cifs //dc-vader.deathstar.lan/backup /mnt/storagebox \
  -o hard,vers=3.0,credentials=/etc/cifs-creds

# 5. Dateisystem im RAW-Image prüfen (erst read-only für den Schadensbericht)
losetup -fP vm-66-disk-0.raw
e2fsck -fn /dev/loop0        # -n = nur anschauen, nichts ändern

Wenn der Schaden — wie meistens in diesem Szenario — nur Journal-Buchhaltung ist (keine kaputten Daten-Inodes), dann:

# 6. Sicherheits-Anker ziehen (Metadaten-Snapshot), dann reparieren
e2image /dev/loop0 /root/nc-meta-anker.e2i
e2fsck -fy /dev/loop0        # -y = Reparatur bestätigen

# 7. Hochfahren
pct start 66
docker compose start
docker compose exec -u www-data app php occ maintenance:mode --off

Bilder sind wieder da, kein Datenverlust — der „Schaden" war nur die abgebrochene Journal-Transaktion.

Dauerhaft: `hard` statt `soft`

Die eigentliche Lehre. Wenn ein Dateisystem-Image auf einem Netzwerk-Share liegt, gehört der Mount hart:

# /etc/fstab — vorher (fragil):
//dc-vader/backup /mnt/storagebox cifs soft,vers=3.0,retrans=1,credentials=/etc/cifs-creds 0 0

# nachher (robust):
//dc-vader/backup /mnt/storagebox cifs hard,vers=3.0,credentials=/etc/cifs-creds 0 0

Mit hard wartet der Mount bei einem Netzwerk-Stall, statt einen I/O-Error nach oben zu reichen. Die Schreiboperation hängt kurz — und läuft weiter, sobald das Netz zurück ist. ext4 sieht nie einen Fehler, bleibt beschreibbar. Ein hängender Upload ist ärgerlich; ein read-only remountetes Dateisystem ist ein Incident.

Noch besser: die Indirektion loswerden

Ehrlich: ext4-RAW-Image auf CIFS als Loop ist strukturell fragil, egal wie du mountest. Wenn du kannst, eliminier den CIFS-Hop — lokale Platte für die Live-Daten, Storage Box nur als Backup-Ziel (dafür ist sie gebaut, siehe unten).

Der Chunking-Zusammenhang: warum große Dateien es verschlimmern

Warum kippte das FS ausgerechnet unter Upload-Last? Weil große Uploads die Storage-Schicht am härtesten treffen — und Nextcloud sie besonders schreibt.

Nextcloud lädt große Dateien nicht in einem Rutsch hoch, sondern chunked: Der Client zerlegt die Datei in Häppchen (Standard clientseitig konfigurierbar), lädt sie einzeln in ein temporäres Verzeichnis auf dem Server, und am Ende setzt ein MOVE die Chunks server-seitig zur finalen Datei zusammen.

Der Knackpunkt: Dieses finale Zusammensetzen schreibt die komplette Datei am Stück auf die Storage — genau der Moment, in dem ein wackliger CIFS-Mount am ehesten stolpert. Eine 5-GB-Datei = ein langer, ununterbrochener Schreibvorgang durch alle vier Schichten. Ein Netzwerk-Schluckauf mittendrin, und soft,retrans=1 reicht den Fehler bis ins ext4-Journal durch.

Wenn du große Dateien fährst, gehören zwei Baustellen sauber konfiguriert:

1. Reverse Proxy — Body-Limit hoch genug:

# nginx: sonst bricht das finale MOVE / große PUTs mit 413 ab
server {
    server_name cloud.deathstar.lan;
    client_max_body_size 10G;      # an deine größten Dateien anpassen
    client_body_timeout 300s;
}

2. PHP — Limits für den Nicht-Chunked-Pfad (WebDAV/App-Clients):

; php.ini bzw. im Container gesetzt
upload_max_filesize = 10G
post_max_size = 10G
max_input_time = 3600
max_execution_time = 3600
memory_limit = 1G

Merksatz: Chunking rettet dich vor PHP-Upload-Limits — aber nicht vor einer fragilen Storage-Schicht. Das MOVE am Ende ist der Lasttest, den ein soft-Mount verliert.

Bonus-Incident: „bad record mac" — der Sync-Client dreht durch

Passt thematisch dazu, weil es auch bei großen Uploads unter Last zuschlägt. Symptom: Der Desktop-Sync-Client (Linux, Laptop c3po) wirft im Loop:

error:0A0003FC:SSL routines::sslv3 alert bad record mac

Ein einziger PUT-Fehler reißt den ganzen Sync-Lauf ab → sofortiger Retry → Client-Crash → Endlosschleife, die in Minuten GB-weise Logs produziert.

Die Diagnose: Server ist sauber (openssl s_client + curl gegen cloud.deathstar.lan fehlerfrei). Die betroffene Datei wechselt nie — es ist immer die erste in der Queue. Das ist ein Client-Artefakt, kein Server-Problem.

Die Ursache: Ein bekannter Bug in der Kombination Nextcloud-Client + OpenSSL 3.0 — HTTP/2-Multiplexing korrumpiert unter Upload-Last (hier: ständig wachsende Log-Dateien von parallelen Prozessen) die TLS-Records.

Der Fix — nimmt nichts weg, kein Bandbreitenlimit nötig, einfach HTTP/2 im Client abschalten:

# Persistent für den Desktop-Client (Linux)
mkdir -p ~/.config/environment.d
echo 'OWNCLOUD_HTTP2_ENABLED=0' > ~/.config/environment.d/10-nextcloud-http2.conf

# Und im Autostart-Eintrag:
# Exec=env OWNCLOUD_HTTP2_ENABLED=0 nextcloud

Nach Neustart: SyncEngine finished without problem, null bad record mac. Der Client fällt auf HTTP/1.1 zurück — den stabilen WebDAV-Pfad.

Lessons Learned

df lügt bei einem toten Loop-Device — 98% „voll" war ein Artefakt, du vs df deckt es auf
ro im mount-Output zuerst prüfen — „keine Bilder" heißt oft „read-only", nicht „Platte voll"
soft,retrans=1 + Loop-Image = Zeitbombe — ein Netzwerk-Stall wird zu read-only remount. Für FS-Images auf Netzwerk-Shares: immer hard
Der Kernel hat die Wahrheit — dmesg zeigt die Kausalkette (CIFS → I/O-Error → Journal-Abort), die df verschleiert
Chunking schützt vor PHP-Limits, nicht vor fragiler Storage — das finale MOVE ist der Lasttest
„bad record mac" beim Sync = Client + HTTP/2 + OpenSSL 3.0 — nicht der Server; Fix ist OWNCLOUD_HTTP2_ENABLED=0

Checkliste: Nextcloud zeigt keine Bilder / Uploads hängen

mount | grep nextcloud → steht da ro? → read-only, nicht Platte
du -sh vs df -h → weichen sie stark ab? → totes Loop-Device
dmesg | grep -iE 'CIFS|I/O error|EXT4' → Kausalkette lesen
Recovery: maintenance on → stop → hard-Remount → e2fsck -fn → -fy → start
fstab: soft,retrans=1 → auf hard umstellen
Große Dateien: client_max_body_size (nginx) + PHP-Limits prüfen
Sync-Loop mit „bad record mac"? → OWNCLOUD_HTTP2_ENABLED=0

🛒 Empfohlene Hardware & Services

Wenn du deine Nextcloud-Daten nicht durch vier Storage-Schichten quälen willst, sind das die zwei sauberen Wege — lokal betreiben oder gehostet:

Lokal (Daten auf eigener Platte, Storage Box nur fürs Backup):

🖥️ Mini-PC N100 Beelink S12 Pro — Nextcloud-Host, leise, 24/7
💾 Synology DS224+ — 2-Bay-NAS für die Daten, RAID1 statt Loop-Image-Bastelei
💾 WD Red Plus 4TB — NAS-Platten, pro Schacht eine
🔌 APC Back-UPS 650VA — sauberes Herunterfahren statt korruptem ext4

In der Cloud (wenn du keine Hardware daheim willst):

Nextcloud läuft bei Hetzner als 1-Klick-App auf einem normalen Cloud-Server — volle Kontrolle, du administrierst selbst:

→ Hetzner Cloud Server starten

Und als Backup-Ziel (dafür ist sie gebaut, nicht als Live-Storage-Hop wie im Incident oben):

→ Hetzner Storage Box — günstiger Offsite-Speicher mit SSH/SFTP/CIFS

Ehrliche Empfehlung ohne Provision: Wenn du Nextcloud gar nicht selbst administrieren willst, gibt es Hetzner Storage Share — ein voll gemanagtes Nextcloud (Updates, Backups, alles inklusive), gebucht über konsoleH. Daran verdiene ich nichts, aber für „ich will einfach eine Cloud, kein Homelab" ist es die ehrlichste Antwort.

Einige Links auf dieser Seite sind Affiliate-Links. Wenn du über diese Links einkaufst, erhalte ich eine kleine Provision — für dich ändert sich am Preis nichts. So unterstützt du diesen Blog und ermöglichst weitere kostenlose Tutorials. Danke! 🙏

Zuletzt aktualisiert: Juli 2026 | Nextcloud 30.x | Debian/Proxmox VE 8.x

Das Problem#

Die Diagnose#

1. Ist das FS read-only?#

2. Stimmt die Platte wirklich?#

3. Was sagt der Kernel?#

Die Architektur (und warum sie fragil ist)#

Das perfide#

Die Lösung#

Sofort: Wieder beschreibbar werden (ohne Datenverlust)#

Dauerhaft: hard statt soft#

Noch besser: die Indirektion loswerden#

Der Chunking-Zusammenhang: warum große Dateien es verschlimmern#

Bonus-Incident: „bad record mac" — der Sync-Client dreht durch#

Lessons Learned#

Checkliste: Nextcloud zeigt keine Bilder / Uploads hängen#

🛒 Empfohlene Hardware & Services#

Kommentare