I have the 10.0.10 (stable) installed on a hosted server and everything runs fine.
Yesterday I realized, that the deleted items are stored since the installation (12/2018).
The system cron is running every 15 min. and in the config.php I included
‘trashbin_retention_obligation’ => ‘auto,30’,
Now I’m helpless. Which setting is missing, so that the deleted objects are removed automatically after x days?
Hello,
it’s indeed weird because according to the documentation it should delete your files after 30 days no matter what:
auto, D delete all files in the trash bin that are older than D days automatically, delete other files anytime if space needed
Nevertheless the documentation for trashbin_retention_obligation has that note:
note: files may not be deleted if space is not needed
So maybe you have to configure trashbin_purge_limit to force it even though 30 days have passed.
I’m assuming it’s some kind of security to avoid erasing files when not needed.
Can you run the following SQL query on your ownCloud database and paste the output here?
select * from oc_jobs;
It should look something like this:
MariaDB [owncloud]> select * from oc_jobs;
+----+----------------------------------------------------+----------+------------+--------------+-------------+--------------------+
| id | class | argument | last_run | last_checked | reserved_at | execution_duration |
+----+----------------------------------------------------+----------+------------+--------------+-------------+--------------------+
| 1 | OCA\Files\BackgroundJob\ScanFiles | null | 1562579101 | 1562579102 | 0 | 0 |
| 2 | OCA\Files\BackgroundJob\DeleteOrphanedItems | null | 1562578202 | 1562579101 | 0 | 0 |
| 3 | OCA\Files\BackgroundJob\CleanupFileLocks | null | 1562579101 | 1562579101 | 0 | 0 |
| 4 | OCA\Files\BackgroundJob\CleanupPersistentFileLocks | null | 1562578202 | 1562579101 | 0 | 0 |
| 5 | OCA\DAV\CardDAV\SyncJob | null | 1562573703 | 1562579101 | 0 | 0 |
| 6 | OCA\DAV\BackgroundJob\CleanProperties | null | 1562573703 | 1562579101 | 0 | 0 |
| 7 | OCA\Federation\SyncJob | null | 1562573703 | 1562579101 | 0 | 0 |
| 8 | OCA\Files_Sharing\DeleteOrphanedSharesJob | null | 1562579101 | 1562579101 | 0 | 0 |
| 9 | OCA\Files_Sharing\ExpireSharesJob | null | 1562573703 | 1562579101 | 0 | 0 |
| 10 | OCA\Files_Trashbin\BackgroundJob\ExpireTrash | null | 1562579101 | 1562579101 | 0 | 0 |
| 11 | OCA\Files_Versions\BackgroundJob\ExpireVersions | null | 1562579101 | 1562579101 | 0 | 0 |
| 12 | OCA\Market\CheckUpdateBackgroundJob | null | 1562573703 | 1562579101 | 0 | 1 |
| 13 | OCA\UpdateNotification\Notification\BackgroundJob | null | 1562573704 | 1562579102 | 0 | 1 |
| 14 | \OC\Authentication\Token\DefaultTokenCleanupJob | null | 1562579102 | 1562579102 | 0 | 0 |
+----+----------------------------------------------------+----------+------------+--------------+-------------+--------------------+
14 rows in set (0.00 sec)
Important is the row
| 10 | OCA\Files_Trashbin\BackgroundJob\ExpireTrash | null | 1562579101 | 1562579101 | 0 | 0 |
With date +%s you should be able to print the current epoch time and compare it with the value in the DB.
Or alternatively convert the epoch time to something more human readable like this:
date -d @1562579101 +"%d-%m-%Y %T %z"
I suspect that you trashbin just got too big at some point for the cronjob to clean it up. So you might need to run the expiry job manually. Can you try:
occ trashbin:expire
Did you check the last execution of the cron on the admin settings page?
Hallo Erik,
vielen Dank daß Du Dich der Sache annimmst!
Ich sehe Du kommst aus Nürnberg so wie ich 
und wir können die Unterhaltung ja in deutsch weiterführen.
Das Statement hab ich abgesetzt, bekomme hier aber leider einen Fehler:
" #1146 - Tabelle 'd025cf1f.oc_jobs' existiert nicht"
ich finde nur eine iR4un_jobs
Im Backend sehe ich daß der CronJob regelmäßig läuft:
Hi,
Ja klar gerne.
Ich weiß nicht ob du root Zugriff hast, aber wenn ja, könntest du den Cronjob manuell auf der CLI ausführen? Das müsste ungefähr so aussehen:
sudo -u www-data env php /var/www/owncloud/cron.php
Wenn man dein date epoch Zeitstempel umwandelt bekommt man folgendes:
date -d @1490623861 +"%d-%m-%Y %T %z"
27-03-2017 14:11:01 +0000
Stimmt denn deine Zeit auf dem System? Einfach mal date ausführen und überprüfen.
Kannst du außerdem deine Crontab mal posten? Vielleicht ist ja da schon ein offensichtlicher Fehler.
(am Ende der Crontab muss immer eine neue Zeile sein, nicht vergessen)
root Zugriff habe ich nicht, da es ein gehostetes System ist.
Mittlerweile habe ich aber herausgefunden, daß meine Tabellen mit EXXp5 beginnen (config.php: ‘dbtableprefix’ => ‘EXXp5_’,)
Aber auch hier sind die Einträge sehr alt - 12/2018 entspricht der Zeit als ich OC in Betrieb genommen habe:
Bei date kommt leider ein Fehler:
und was genau meinst Du mit Crontab? - ist damit die cron.php aus dem OC-Rootverzeichnis gemeint?
Viele Grüße
Jörg
Laut deinem Screenshot ist cron auf dem System konfiguriert. Die crontab datei bestimmt wann deine automatische Befehlsausführung stattfinden soll und welcher Befehl ausgeführt werden soll.
Bei manchen gehosteten Systemen gibt es hierfür eine Weboberfläche bei der diese Parameter eingestellt werden können. Im Hintergrund wird allerdings immer in eine sogenannte crontab geschrieben, oft in den Verzeichnissen ‘/etc/cron*’ oder ‘/var/spool/cron’ anzufinden
Um zu testen dass dies einwandfrei funktioniert lohnt es sich manchmal einfach einen Dummycron zu installieren der seinen Output in ein Logfile schreibt, zB so:
* * * * * env > /pfad/zur/datei
# Pfad muss für deinen Benutzer schreibbar sein
# Leerzeile am Ende der Datei nicht vergessen (Windows Editoren schneiden diese gerne ab)
Die Befehle (occ/date/…) , die ich beschrieben habe, kann man nur auf der CLI des Linux-Systems ausführen. Normalerweise hat man hierauf via SSH Zugriff, dies ist allerdings nicht in allen ‘Shared-Hosting’-Umgebungen gegeben.
Als Workaround könnte man versuchen cron für die Ausführung der Befehle zu benutzen, da diese sogar als der richtige Benutzer laufen müssen. Wäre allerdings ne Menge Trail & Error…
Ah ok das ist damit gemeint
Ich hab das nur zum testen mal auf 5min. eingestellt
Man bräuchte jetzt quasi eine php Datei die irgendwas in eine Textdatei schreibt,
um zu testen ob der Job tatsächlich ausgeführt wird…
Dann werde ich mich daran mal versuchen
EDIT: eben probiert: funktioniert einwandfrei
Hi
Das Cron-Interface ist ein Webcron-Interface und führt daher kein Program direkt in deinem System aus, sondern macht z.B. ein curl auf die angegebene Webseite.
Allerdings wenn cron so ausgeführt wird greifen die PHP-Konfiguration-Zeitlimits für die Ausführung von PHP. Wenn dies z.B. auf 60 Sekunden gesetzt ist wird die Ausführung nach 60 Sekunden abgebrochen. Und damit werden auch alle Jobs die länger als das brauchen abgebrochen.
Ich denke es sollte möglich sein den cron job lokal auf der Kommando-Zeile auszuführen indem man das Protokoll ändert. Ansonsten würde ich empfehlen den Support deines Webhosters zu fragen wie das geht.
Standardmäßig wird soweit ich das weiß in diesen shared-hosting Umgebungen der cron bereits als der richtige Benutzer ausgeführt. Von daher musst du folgenden Eintrag aus der Doku verwenden (kein sudo…):
* * * * * /usr/bin/php -f /path/to/your/owncloud/cron.php
Generell ist davon abzuraten ownCloud in einer shared-Hosting-Umgebung laufen zu lassen, wenn man keinen SSH-Zugriff auf diese hat und Befehle nicht als Webserver-Benutzer absetzen kann. Dies ist in diesen Umgebungen oft NUR mit cron möglich.
Ich verstehe nicht, weshalb anscheinend keiner der Jobs ausgeführt wird (siehe “last check”, “last run”), obwohl das Backend anzeigt, daß der cronjob regelmäßig läuft.
Ich habe doch keine vom Standard abweichende Konfiguration…?
Hier unter Punkt 4 ist noch beschrieben wie man ein Script einbinden kann:
https://all-inkl.com/wichtig/anleitungen/kas/tools/cronjobs/einrichtung_479.html
Aber dazu bräuchte ich auch Unterstützung.
Da ich den Papierkorb gestern manuell geleert habe, ist die Brisanz nun nicht mehr ganz so hoch, allerdings habe ich gesehen, daß der Ordner “files_versions” auch viel zu groß ist 
Dafür müßte ja der Job “OCA\Files_Versions\BackgroundJob\ExpireVersions” zuständig sein.
Wie bekommt man den, bzw. auch alle anderen jetzt zum Laufen?
Also die Dokumentation des Hosters zeigt ganz klar, dass es NICHT möglich ist direkt Shell-Skripte auszuführen. Da diese immer nur über ein PHP-Skript aufgerufen werden, wird die Ausführung nach Timeouts abgebrochen. Wenn nun die cron.php-Ausführung zu lange dauert (weil zB tausende von Dateien gelöscht werden müssen) wird diese einfach mittendrin abgebrochen und die automatische Löschung funktioniert nicht.
Von der Nutzung solcher Hosting-Umgebungen für ownCloud würde ich stark abraten, da keine Möglichkeit besteht Befehle auf der CLI auszuführen. Sowas ist höchstens für eine statische Webseite gut genug. Und man bekommt für den gleichen Preis heutzutage auch nen kleinen Root-Server, braucht allerdings ein bisschen mehr Know-How…
Mein Webhoster konnte mir weiterhelfen.
Der nette Supporter hat eine Scriptdatei erstellt, die die OC cron.php aufruft und im Webcron Interface zu konfigurieren ist.
Trotzdem vielen Dank für Deine Hilfsbereitschaft!