Hallo Zusammen,
- PC-Server
- Ubuntu Server 24.04 LTS
- Nextcloud-Version: 31.0.9.1
- PHP-Version: 8.3
- MariaDB 11.4.8
- Nginx 1.29.2
Auf unseren Nextcloud-Server wird die nextcloud.log geflutet mit:
"message":"Could not fetch stats of mailbox: Trash","userAgent":"--","version":"31.0.9.1","data":{"app":"mail"}
Wo bei “Trash” für eine der über 500 Mailboxes (IMAP-Verzeichnisse) steht. Alle 5 Minuten kommt ein Account dran mit den Meldungen und zusätzlich, wenn jemand auf die Mail-App zugreift.
Das Ganze tritt auf, nach dem allmorgentlichen Updates.
Nur verstehe ich den Zusammenhang nicht. Apt hat ein paar Teile von systemd ersetzt. Aber es gab keine Updates von Nextcloud Apps.
Und scheinbar läuft ja auch alles.
Ich habe stundenlang erfolglos gesucht und komme mir gerade vor wie ein ahnungsloser Anfänger. Keine Ahnung, was da passiert und warum.
Eigentlich müsste es ja ganz vielen anderen auch so gehen. Doch ich habe bis jetzt keine Meldung dazu im Internet gefunden.
Hat jemand eine Idee?
Liebe Grüße
Jason
Und wir sind ahnungslose Leser, die nix verstehen von dem, was Du im Kopf hast und nicht geschrieben hast.
Hä?
Was steht im Maillog?
Wie ist die Mail-App wo angebunden?
Wir haben ein wundervolles Support Template, das Dir aufzeigt, wo Du nachschauen solltest und wir einen Überblick über Dein System erhalten.
So ganz verstehe ich die Frage nicht. Die Benutzer haben einen oder mehrere Mail-Accounts bei verschiedenen Providern. Und die Mail-App spricht per IMAP bzw. SMPT mit diesen.
Der Mail-Verkehr der Mail-App läuft ja nicht zentral über den Account, der in den Admin-Einstellungen eingetragen ist. Also gibt es auch nicht die Maillog …
Es scheint auch alle Provider zu betreffen.
Die Meldungen in der nextcloud.log begannen direkt nach den Updates und die betrafen heute Morgen nur einige systemd-Komponenten. Allerdings wurde dabei systemd und daher einige Dienste neugestartet. Allerdings ist das eigentlich nichts Besonderes.
Das waren 66% der Fragen beatwortet - fehlt noch die Antwort auf “Hä?” mit dem Zitat darüber.
Jetzt weißt Du wenigstens, warum es wichtig ist, die relevanten Informationen im Startbeitrag aufzuführen.
Bei 500 Mailboxes sollte man eigentlich davon ausgehen können, dass ein eigener Mailserver oder bei einem Provider gehostet wird, auf dessen Logs man auch Zugriff hat.
Ja, ein eigener Mail-Server wäre schön. Er würde uns an vielen Stellen das Leben erleichtern. Aber es gibt noch ganz andere Dinge, die ich gerne davor hätte: Glasfaser statt DSL und endlich eine statische IP-Adresse. Dazu Router die wenigstens aus diesem Jahrtausend stammen. Und dann endlich ein vernünftiges DNS-Management (mit Split-Brain). Und die Zeit das alles auch noch umzusetzen … 
Langer Rede kurzer Sinn: Ich habe zu diesen Fällen kein Mail-Log.
Zu den weiteren 34%: Jeden Morgen lasse ich auf allen Servern Updates laufen (die Updates über apt und die Nextcloud-Apps). Diese Prozesse beobachte ich genau und lasse mir dann diverse Log-Files anzeigen. So bekomme ich sofort mit, wenn etwas anders ist als sonst oder evtl. nicht läuft.
Je nach zu installierenden Updates wird vermutlich auch die LAN-Verbindung getrennt, z.B. um neue LAN-Pakete zu installieren. Fragt dann Nextcloud Mail die Mailboxen zu diesem Zeitpunkt ab, kann es zu diesem “cannot stat…” Fehler kommen.
Naja, aber dann würden die Meldungen ja nur für sehr kurze Zeit auftauchen.
Ich habe mir mal den Quelltext angesehen: Die Meldung kommt aus:
mail/lib/IMAP/FolderMapper.php(138): getFoldersStatusAsObject
Dort wird der Status des Folders über die Horde-Bibliothek abgefragt. Und er ist leer.
Aber wohlgemerkt: Die Mail-App scheint noch normal zu funktionieren.
Das Problem bleibt: Spätestens alle 5 Minuten kommt ein Schwall neuer Einträge ins nextcloud.log.