Hallo,
ich habe einen UCS 4.1 von 4.1-2 errata191 auf 4.1.2 errata 220 aktualisiert und habe danach mit der Mailstore Archivierung das Problem, dass der vorher genutzte “master-user” sich zwar am dovecot IMAP-Server ohne Fehler anmelden kann (dass Passwort habe ich kontrolliert), aber danach hat er in den einzelnen Mailboxen keine Rechte. Daher kann der Archivjob auch nichts mehr archivieren. Dies hat monatelang einwandfrei funktioniert.
Ich habe jetzt in /etc/dovecot/conf.d nach verdächtigen Änderungen gesucht und werde nicht fündig.
Was kann ich tun?
Das Debuggen von Dovecot-Problemen ist zum Glück gut konfigurierbar. Auskunft bekommen Sie mit:
ucr search --verbose mail/dovecot/logging/
Ich schlage vor:
ucr set mail/dovecot/logging/auth_debug=yes mail/dovecot/logging/auth_verbose=yes mail/dovecot/logging/mail_debug=yes
invoke-rc.d dovecot restart
Das Logfile mit den Debug-Informationen ist: /var/log/dovecot.log
Um zu sehen was der der master-user als User eingeloggt sieht, können Sie diesen einfach in einem E-Mail-Client benutzen (zB Thunderbird).
Username "daniel@univention.de*dovecotadmin"
Passwort: Das was in /etc/dovecot/master-users zwischen {PLAIN} und :::::: steht.
Angehängt ist ein kleines Test-Skript, dass Sie mit einem Mail-Account als Argument ausführen können:
Hallo Herr Tröder,
ich kann mich am IMAP-Dienst per IMAP-SSL offenbar erfoglreich anmelden als Benutzer username@domainname.de, bis auf “Posteingang” sind aber alle kursiv gesetzt.
Beim Zugriff auf die einzelnen Folder erhalte ich die Fehlermeldung “[SERVERBUG] internal sever error. Refer to server log for more information.”
Wo muss ich jetzt auf dem Server nachsehen?
Gruß, Philipp Rusch
P.S.: Ich bestehe nicht darauf, dass das Ganze mit dem jüngsten Update zusammenhängt, der Kunde hat das vermutet. Es kann durchaus sein, dass das Archiv schon länger nicht mehr “versorgt” wird, weil der dovecotadmin nicht so funktioniert, wie er soll.
Logging gesetzt, wie vorgeschlagen.
Der dovecot meckert über /var/spool/dovecot/private/domainname.de/username/Maildir/dovecot-acl not found
Kann das sein, dass die ACLs in den Verzeichnissen nicht (mehr) stimmen?
[quote=“prusch”]Der dovecot meckert über /var/spool/dovecot/private/domainname.de/username/Maildir/dovecot-acl not found
Kann das sein, dass die ACLs in den Verzeichnissen nicht (mehr) stimmen?[/quote]
Das ist i.O. Dovecot meckert über alles was er nicht findet, auch wenn es kein Fehler ist. Im Logfile sollte die Meldung als “Debug:” gekennzeichnet sein.
Thunderbird zeigt die Ordner kursiv an, weil sie ihm leer erscheinen. Wenn die Mailbox auf dem Server tatsächlich Mails enthält, könnte es sein, dass sie die falschen Dateiberechtigungen haben. Alle Dateien und Verzeichnisse sollte User dovemail und Gruppe dovemail gehören.
Das klingt nach einem Problem. Die entsprechende Nachricht sollte mit “Error” gekennzeichnet sein, und daher auch in /var/log/dovecot.warn auftauchen (auch in .log, aber dort ist sie schwieriger zu finden).
in den verschiedenen dovecot.warn Dateien finde ich immer wieder bei allen Usern:
Aug 4 08:16:18 mail dovecot: imap(username@domainname.de): Error: Failed to autocreate mailbox INBOX: Permission denied
Das Maildir-Verzeichnis gehört dovemail/dovemail.
Kurioserweise funktioniert der OpenXchange “obendrauf” problemlos.
Das mit dem Backup-Ziel verstehe ich nicht.
Zur Situation: der UCS befindet sich in einer VM auf einem VMware ESXi 5.5 Cluster.
Das Backup machen wir mit VMware Dataprotection, indem wir die gesamte VM und die beiden virtuellen Platten sichern.
Ändern sich dabei die Rechte der Verzeichnisse? Das glaube ich ehrlich gesagt nicht!
Die Rechte sind wie folgt auf
Die einzelnen Benutzer haben dann:
/var/spool/dovecot/private/domainname.de/username : 42700 dovemail/dovemail
und ich glaube, das ist das Problem: dann müssten ja alle Mail-Benutzer Mitglieder dieser Gruppe sein, um Schreibrechte zu besitzen.
Die Userkonten kommen bei diesem Kunden aber aus der ADS und werden auf der UCS nicht mit der Hand angelegt.
Die Gruppe dovemail ist aber leer. jetzt bin ich mit meinem Latein am Ende.
Achso, das mit den Backup-Ziel bezog sich auf den Archivierungsjob ?!?
Nein, das kann nicht sein, die Meldung erhalte ich ja auch schon beim Zugriff mit dem Thunderbird.
[quote=“prusch”]und ich glaube, das ist das Problem: dann müssten ja alle Mail-Benutzer Mitglieder dieser Gruppe sein, um Schreibrechte zu besitzen.
Die Userkonten kommen bei diesem Kunden aber aus der ADS und werden auf der UCS nicht mit der Hand angelegt.
Die Gruppe dovemail ist aber leer. jetzt bin ich mit meinem Latein am Ende.[/quote]Dovecot ist für “virtual users” konfiguriert. Der Dovecot server läuft mit den als dovemail/dovemail und regelt die Berechtigungen für die Benutzer selbst (nicht das Dateisystem).
[quote=“prusch”]Achso, das mit den Backup-Ziel bezog sich auf den Archivierungsjob ?!?
Nein, das kann nicht sein, die Meldung erhalte ich ja auch schon beim Zugriff mit dem Thunderbird.[/quote]Ach so OK.
Es ist nicht unüblich einen Backup-Job mit dsync o.ä. zu machen, bei dem die Mails per IMAP von den Konten abgerufen und zu einem entfernten IMAP-Server übertragen werden. Der könnte theoretisch auch “lokal” sein, mit einer remote-Platte. Deswegen fragte ich nach dem Backup-Ziel
Bei mir funktioniert das Login als ein anderer User mit dem dovecotadmin und ich sehe dann auch Mails. Wenn bei Ihnen das Login klappt, aber danach das Sehen der Mails nicht, stattdessen die INBOX angelegt werden soll, ist etwas seltsam.
Im Logfile steht welche Pfade Dovecot liest.
Sind die korrekt?
Gibt es Unterschiede zu den Pfaden die beim Login des Users (ohne dovecotadmin) gelesen werden?
Wenn eh die ganze Platte gesichert wird - wozu wird sich per IMAP eingeloggt?
Also nochmal von vorne:
Wir setzen eine Archivierungs-Software für Emails ein: Mailstore. Dies ist kein Backup, sondern ein Archivserver mit einer eigenen Datenbank, in die die User jederzeit mit einem Outlook-Plugin online zugreifen können.
Der Mailstore-Server liest die Daten aus den Mailboxen mit dem Dovecot Master-User aus, damit er nicht von jeder einzelnen Mailbox das Passwort benötigt (das wir auch gar nicht kennen).
Dies hat monatelang einwandfrei funktioniert. Irgendwann brachen die Archivjobs in der Nacht mit Fehlern ab. Wir haben auf dem Mailstore-Server nichts geändert, wohl aber in der Zwischenzeit den UCS von 4.0 auf 4.1 gezogen und weitere Updates gefahren, wann immer von Univention welche anstanden. Das Passwort des Dovecot “master-user” habe ich überprüft, es ist korrekt. Wenn ich es auf dem Mailstore ändere, dann kann ich gar nicht auf den IMAP-Dienst zugreifen. (Fehlermeldung sinngemäß “Login fehlgeschlagen”). Ich suche jetzt also nach dem Fehler, der mir den weiteren Zugang auf die Inhalte der einzelnen Benutzer-Postfächer verhindert.
Hallo,
ich bräuchte da schon noch weitere Hilfe, weil ich mit dem dovecot nicht weiterkomme.
Die Fehlermeldungen kommen in ALLEN Benutzerkonten, die Pfade sind effektiv vorhanden.
OX 7.8.1 ist offenbar mit den Rechten zufrieden, Thunderbird und Mailstore dagegen nicht.
Der OXtender2 für die Outlook Clients läuft aber einwandfrei.
Die Archivsoftware kann dies auf jeden Fall noch nicht mit UCS 4.0 gemacht haben, denn da gab es noch kein Dovecot.
Zur genaueren Analyse könnten Sie im Mailarchiv (Logs / letzte kopierte Mails) nachschauen, ab wann das Problem genau auftrat und dann im UCS in /var/log/univention/updater.log schauen welche Pakete an diesem und den vorherigen Tag geupdaten wurden und in /var/log/univention/replog (oder so ähnlich) welche UCRs.
Ich habe mit den vorhandenen Informationen keine weitere Idee. Wenn Sie den Support von Univention in Anspruch nehmen, kann dieser auch direkt auf das System schauen und das Problem evtl. schneller lösen als wir hier im Forum. Wenn Sie wünschen, können Sie diesen hier kontaktieren: univention.de/produkte/supp … taktieren/
