Wenn eine Datei aus dem Windows-Explorer verschwindet, ZimaOS das Laufwerk jedoch weiterhin als voll meldet, lautet die erste Frage nicht: „Ist es SMB nicht gelungen, sie zu löschen?“ Die Datei wurde möglicherweise in den Papierkorb-Workflow von ZimaOS verschoben, in einem versteckten Papierkorbverzeichnis behalten oder ist von einem versionsabhängigen Fehler bei der Papierkorb-Indexierung bzw. -Anzeige betroffen.
Der ursprüngliche Thread selbst führte zu keiner bestätigten Lösung. Ein Community-Mitglied erklärte, dies sei normales Samba-Verhalten, und verwies auf versteckte Ordner wie .recycle, .Trash oder .Trash-1000. Dieser Hinweis war für ZimaOS zu allgemein. Bei der späteren Fehlerbehebung für Version 1.5.4 wurde der eigene versteckte Papierkorbordner von ZimaOS unter /var/lib/casaos_data/.media/.../.trash identifiziert, während die aktuelle Dateien-App über einen eigenen Papierkorb verfügt.
Die Dateien-App von ZimaOS verfügt über einen offiziellen Papierkorb
IceWhale hat in ZimaOS 1.3.1 einen visuellen Papierkorb in der Dateien-App hinzugefügt. Laut den Versionshinweisen können gelöschte Elemente wiederhergestellt werden; außerdem werden sie nach 30 Tagen automatisch gelöscht.
Lesen Sie die offizielle Funktion des ZimaOS-Papierkorbs, bevor Sie versteckte Verzeichnisse manuell löschen.
Das „normale Samba-Verhalten“ aus der Quelle wurde nicht bestätigt
Der ursprüngliche Verfasser fragte, ob für jede Löschung eine Bereinigung über die Befehlszeile erforderlich sei. Es gab jedoch keine spätere Antwort, die bestätigte, welches versteckte Verzeichnis den Speicherplatz belegte oder ob das Löschen aus Windows in dieser Version über den ZimaOS-Papierkorb geleitet wurde.
Daher sollte die Quelle als erste Vermutung und nicht als bestätigte Diagnose betrachtet werden.
ZimaOS 1.5.4 hatte später einen dokumentierten Anzeige-/Synchronisierungsfehler mit .trash
In einem separaten Community-Thread vom Februar 2026 wurde festgestellt, dass sich gelöschte Dateien unter folgendem Pfad ansammelten:
/var/lib/casaos_data/.media/Mounted-Drive-Label/.trashwährend die Papierkorbanzeige der Dateien-App diese nicht korrekt darstellte. Die vorgeschlagene Zwischenlösung bestand darin, Dateien-App und SMB zu stoppen, den betroffenen versteckten Papierkorbordner zu entfernen, die Dienste neu zu starten und Schreibvorgänge zu synchronisieren. Der Verfasser berichtete später jedoch, dass das Problem nach Neustarts wieder auftrat.
Das ist eine versionsabhängige Lösung aus der Community und keine sichere, allgemeingültige Anleitung zum Löschen.
Prüfen Sie zuerst Dateien → Papierkorb
Öffnen Sie als Erstes den Papierkorb der Dateien-App und prüfen Sie, welche Elemente dort aufbewahrt werden. Wenn die gelöschten Elemente sichtbar sind, leeren Sie den Papierkorb über die Benutzeroberfläche, anstatt interne Metadatenpfade über die Shell zu entfernen.
Die automatische Aufbewahrung erklärt, warum der Speicherplatz möglicherweise nicht sofort wieder frei wird
Wenn gelöschte Dateien zur Wiederherstellung absichtlich aufbewahrt werden, kann die Speichernutzung hoch bleiben, bis der Papierkorb geleert wird oder der Aufbewahrungszeitraum abläuft. Dieses Verhalten schützt vor versehentlichem Löschen, kann jedoch überraschen, wenn über SMB Hunderte Gigabyte gelöscht werden.
Ermitteln Sie den tatsächlichen Speicherverbraucher, bevor Sie versteckte Ordner löschen
Wenn der Papierkorb der Dateien-App leer aussieht, der Speicherplatz jedoch weiterhin belegt ist, prüfen Sie:
- versteckte Papierkorbdaten;
- Aufbewahrung von Backups und Versionen;
- gegebenenfalls verwendete Btrfs-Snapshots;
- Dateien, die unterhalb eines nicht vorhandenen Einhängepunkts geschrieben wurden;
- geöffnete, aber gelöschte Dateien, die von einem laufenden Prozess gehalten werden;
- Anwendungscaches oder Docker-Daten.
Gehen Sie nicht davon aus, dass jedes unerklärte Gigabyte zum Papierkorb gehört.
Das Löschen über den Explorer sollte nicht jedes Mal eine manuelle SSH-Bereinigung erfordern
In einer aktuellen, funktionierenden Einrichtung sollten normale SMB-/Datei-Workflows das Löschen übernehmen, ohne dass der Benutzer wiederholt interne Papierkorbordner entfernen muss. Wenn für jedes Löschen im Explorer eine manuelle Bereinigung erforderlich ist, betrachten Sie dies als aktuelles Problem des Dateien-/SMB-Verhaltens und notieren Sie die ZimaOS-Version.
Löschen Sie interne .media-Pfade nicht unbedacht
Pfade unter /var/lib/casaos_data/.media sind Bestandteil des internen Einhänge- und Papierkorbmodells des Dateidienstes von ZimaOS. Das Entfernen des falschen Verzeichnisses bei aktiven Diensten kann die Indexierung oder den eingebundenen Speicher beeinträchtigen.
Verwenden Sie zuerst die Benutzeroberfläche und wenden Sie sich an den Support, bevor Sie eine ältere Shell-Lösung für Version 1.5.4 auf das aktuelle ZimaOS anwenden.
Testen Sie das aktuelle ZimaOS erneut, bevor Sie einen Papierkorbfehler aus dem Jahr 2025 bzw. aus Version 1.5.4 reproduzieren
Das aktuelle ZimaOS ist Version 1.7.1 und wurde weiterhin mit Korrekturen für Dateidienste, Speicher, Ausschneiden/Verschieben und Sicherheit aktualisiert. Die Quelle ist nützlich, um die Papierkorbschicht zu verstehen, beweist jedoch nicht, dass derselbe Fehler heute noch besteht.
FAQ zum Löschen über SMB und zum Papierkorb
Können gelöschte Dateien weiterhin Speicherplatz belegen, weil sie sich im Papierkorb befinden?
Ja. Die Dateien-App von ZimaOS verfügt über einen offiziellen Papierkorb und eine Aufbewahrungsfunktion.
Wurde die Diagnose mit dem versteckten Ordner aus dem ursprünglichen Thread von 2025 vom Benutzer bestätigt?
Nein. Der Thread endete, bevor der Benutzer eine erfolgreiche Bereinigung meldete.
Sollten aktuelle Benutzer /var/lib/casaos_data/.media/.../.trash manuell löschen?
Nicht als ersten Schritt. Dieser Pfad stammt aus einer späteren Lösung der Community für Version 1.5.4 und sollte nur auf Grundlage versionsspezifischer Hinweise und mit entsprechender Vorsicht verwendet werden.
