Als een bestand uit Windows Verkenner verdwijnt, maar ZimaOS nog steeds meldt dat de schijf vol is, is de eerste vraag niet: ‘Is het verwijderen via SMB mislukt?’ Het bestand kan naar de prullenbakworkflow van ZimaOS zijn verplaatst, in een verborgen prullenbakmap zijn bewaard of zijn getroffen door een versiegebonden probleem met de prullenbakindex of -weergave.
De oorspronkelijke thread zelf kwam niet tot een bevestigde oplossing. Een communitylid zei dat dit normaal Samba-gedrag was en stelde verborgen mappen voor, zoals .recycle, .Trash of .Trash-1000. Dat advies was te algemeen voor ZimaOS. Bij latere probleemoplossing voor versie 1.5.4 werd de eigen verborgen prullenbaklocatie van ZimaOS gevonden onder /var/lib/casaos_data/.media/.../.trash, terwijl Bestanden inmiddels een volwaardige prullenbak bevat.
Bestanden in ZimaOS heeft een officiële prullenbak
IceWhale voegde in ZimaOS 1.3.1 een visuele prullenbak toe aan Bestanden. In de releaseopmerkingen staat dat verwijderde items kunnen worden hersteld en na 30 dagen automatisch worden verwijderd.
Bekijk de officiële prullenbakfunctie van ZimaOS voordat je verborgen mappen handmatig verwijdert.
Het ‘normale Samba-gedrag’ uit de bron is niet geverifieerd
De oorspronkelijke poster vroeg of voor elke verwijdering opruimen via de opdrachtregel nodig zou zijn, maar geen latere reactie bevestigde welke verborgen map ruimte innam of dat verwijderen vanuit Windows in die versie via de prullenbak van ZimaOS liep.
De bron moet daarom worden gezien als een eerste hypothese, niet als een bevestigde diagnose.
ZimaOS 1.5.4 had later een gedocumenteerde weergave-/synchronisatiefout met .trash
In een afzonderlijke communitythread uit februari 2026 bleek dat verwijderde bestanden zich opstapelden onder:
/var/lib/casaos_data/.media/Mounted-Drive-Label/.trashterwijl de prullenbakinterface van Bestanden deze niet correct weergaf. De tijdelijke oplossing bestond uit het stoppen van Bestanden/SMB, het verwijderen van de betreffende verborgen prullenbakmap, het opnieuw starten van de services en het synchroniseren van schrijfbewerkingen. De auteur meldde later echter dat het probleem na herstarts terugkeerde.
Dit is een versiegebonden communityoplossing, geen veilige universele verwijderinstructie.
Controleer eerst Bestanden → Prullenbak voordat je via SSH opruimt
Open als huidige gebruiker eerst de prullenbak in Bestanden en controleer wat daar wordt bewaard. Als de verwijderde items zichtbaar zijn, maak de prullenbak dan leeg via de interface in plaats van interne metadatapaden vanuit de shell te verwijderen.
Automatische bewaartermijn verklaart waarom ruimte niet direct vrijkomt
Als verwijderde bestanden bewust worden bewaard voor herstel, kan het schijfgebruik hoog blijven totdat de prullenbak wordt geleegd of de bewaartermijn verstrijkt. Dit beschermt gebruikers tegen onbedoelde verwijdering, maar kan iemand verrassen die honderden gigabytes via SMB verwijdert.
Meet eerst wat werkelijk ruimte inneemt voordat je verborgen mappen verwijdert
Als de prullenbak in Bestanden leeg lijkt, maar het schijfgebruik hoog blijft, controleer dan:
- verborgen prullenbakgegevens;
- bewaartermijnen voor back-ups en versies;
- Btrfs-snapshots, als die worden gebruikt;
- bestanden die onder een ontbrekend koppelpunt zijn geschreven;
- geopende maar verwijderde bestanden die door een actief proces worden vastgehouden;
- applicatiecaches of Docker-gegevens.
Ga er niet van uit dat elke onverklaarde gigabyte bij de prullenbak hoort.
Verwijderen via Verkenner zou niet telkens handmatige SSH-opruiming moeten vereisen
Een gezonde, actuele configuratie hoort normale SMB-/Bestanden-workflows verwijderingen te laten afhandelen zonder dat de gebruiker steeds interne prullenbakmappen hoeft te verwijderen. Als voor elke verwijdering in Verkenner handmatige opruiming nodig is, beschouw dat dan als een actueel probleem met het gedrag van Bestanden/SMB en noteer de ZimaOS-versie.
Verwijder interne .media-paden niet blindelings
Paden onder /var/lib/casaos_data/.media maken deel uit van het interne model van ZimaOS voor bestandsservices, koppelingen en de prullenbak. De verkeerde map verwijderen terwijl services actief zijn, kan gevolgen hebben voor indexering of gekoppelde opslag.
Gebruik eerst de interface en neem contact op met support voordat je een oude shelloplossing voor versie 1.5.4 toepast op de huidige versie van ZimaOS.
Test opnieuw met de huidige ZimaOS-versie voordat je een prullenbakfout uit 2025/versie 1.5.4 probeert te reproduceren
De huidige versie van ZimaOS is 1.7.1 en ontvangt nog steeds oplossingen voor bestandsservices, geheugen, knippen/verplaatsen en beveiliging. De bron is nuttig om de prullenbaklaag te begrijpen, maar bewijst niet dat dezelfde fout vandaag nog bestaat.
Veelgestelde vragen over SMB-verwijderingen en de prullenbak
Kunnen verwijderde bestanden ruimte blijven innemen omdat ze in de prullenbak staan?
Ja. Bestanden in ZimaOS heeft een officiële prullenbak en bewaargedrag.
Is de diagnose met verborgen mappen uit de oorspronkelijke thread uit 2025 door de gebruiker bevestigd?
Nee. De thread eindigde voordat de gebruiker een geslaagde opruiming meldde.
Moeten huidige gebruikers /var/lib/casaos_data/.media/.../.trash handmatig verwijderen?
Niet als eerste stap. Dat pad kwam uit een latere communityoplossing voor versie 1.5.4 en mag alleen worden gebruikt met versiegebonden bewijs en de nodige voorzichtigheid.
