Hi, ich wollte heute wieder ein update von meiner mailcow anstoßen, also wie üblich update.sh ausgeführt. Mailcow ist nach dem Update allerdings nicht mehr hochgekommen, gab nur folgende Fehlermeldung: `ERROR: Configuration for volume vmail-vol-1 specifies "device" driver_opt :/data/docker_vol/vmail-vol-1, but a volume with the same name uses a different "device" driver_opt (:/data/docker_vol/vmail-vol). If you wish to use the new configuration, please remove the existing volume "mailcowdockerized_vmail-vol-1" first: $ docker volume rm mailcowdockerized_vmail-vol-1 ` Ich habe daraufhin in die docker-compose.yml geschaut und gesehen, dass hier meine Mount-Options für vmail-vol-1 weg waren (ich habe das auf einem NFS-volume liegen). Also die Mount-options wieder eingefügt und erneut versucht zu starten. Gab allerdings immer wieder die gleiche Fehlermeldung. Somit bin ich auf die glorreiche Idee gekommen, das angemeckerte Volume aus Docker zu löschen(liegt ja eh auf NFS). Jetzt gab es folgende Fehlermeldung: `ERROR: Configuration for volume vmail-attachments-vol-1 specifies "device" driver_opt :/data/docker_vol/vmail-attachments-vol-1, but a volume with the same name uses a different "device" driver_opt (:/data/docker_vol/vmail-attachments-vol). If you wish to use the new configuration, please remove the existing volume "mailcowdockerized_vmail-attachments-vol-1" first: $ docker volume rm mailcowdockerized_vmail-attachments-vol-1` Anstatt jetzt auch nur dieses Volume (welches ebenfalls auf NFS liegt) zu entfernen, habe ich alle ungenutzen Volumes in Docker entfernt. Mailcow ist jetzt zwar hochgefahren, allerdings natürlich in einem fresh install-Status... was natürlich klar ist, wenn man alle persistenten Volumes löscht, auf denen auch die Konfiguration und Datenbanken liegen. Ich gehe mal davon aus, diese Volumes bekomme ich nicht zurück und darf mir mailcow neu konfigurieren -> Gerechte Strafe (?), weil nicht richtig nachgedacht, lessons learned. ABER: Wie bekomme ich jetzt meine alten Mails wieder sauber rein?

Kleine Ergänzung, mir ist gerade aufgefallen, dass ich mit den Mounts auch schlicht Blödsinn gemacht habe... nachdem das Uppdate-script durchgelaufen war und mailcow nicht hochgekommen ist, habe ich in der docker-compose.yml gesehen, dass die NFS-optionen weg waren. Ich habe diese dann einfach c+p aus einem alten Backup eingefügt, dabei aber nicht drauf geachtet, dass der Pfad etwas anders ist (vol-1 anstatt wie aktuell richtig nur vol). Die Frage bleibt aber dennoch: Wie bekomme ich jetzt meine alten Mails in Mailcow wieder rein?

Habe jetzt das Volume mal "normal" eingebunden, mailcow gestartet und angefangen die Domains und Mailboxen in mailcow wieder anzulegen. Mein IMAP-Client funktioniert, ich kann auch wieder mails senden und empfangen, allerdings ist mir ein Problem in SoGO aufgefallen: Alle mails werden "leer" angezeigt, sprich ich sehe weder Absender, noch inhalt noch sonstwas von den Mails, nur die Anzahl an Mails. In der Mailcow-Konfiguration sehe ich bei den Mailboxen auch eine falsche Anzahl an Mails und Mailstore-usage, an Mails werden mir dort nur die Anzahl angezeigt, welche ich als Probemails hin un her geschickt habe um zu testen, ob Mailempfang wieder funktioniert. In den Logs von dovecot finde ich jetzt folgendes: `12.10.2020, 14:50:38 err indexer-worker(pa@aXXXXXXXXXXXe): Error: Mailbox Trash: Transaction commit failed: FTS transaction commit failed: transaction context (attempted to index 1 messages (UIDs 1..1)) 12.10.2020, 14:50:38 err indexer-worker(pa@aXXXXXXXXXXXe): Error: Mailbox Trash: Mail search failed: Internal error occurred. Refer to server log for more information. [2020-10-12 14:50:38] 12.10.2020, 14:50:38 err indexer-worker(pa@aXXXXXXXXXXXe): Error: Failed to read mailbox Trash mail UID=1 stream: Mailbox Trash: UID=1: read() failed: read(/var/vmail/aXXXXXXXXXe/pa/Maildir/.Trash/cur/1589994796.M513796P2489.mail.aXXXXXXXXXXXe,S=21624,W=21996:2,S) failed: Decryption error: no private key available (read reason=fts indexing) 12.10.2020, 14:50:38 err indexer-worker(pa@aXXXXXXXXXXXe): Error: Mailbox Trash: UID=1: read() failed: read(/var/vmail/aXXXXXXXXXXXe/pa/Maildir/.Trash/cur/1589994796.M513796P2489.mail.aXXXXXXXXXXXe,S=21624,W=21996:2,S) failed: Decryption error: no private key available (read reason=fts indexing) 12.10.2020, 14:50:38 err indexer-worker(pa@aXXXXXXXXXXXe): Error: Mailbox Trash: UID=1: read() failed: read(/var/vmail/aXXXXXXXXXXXe/pa/Maildir/.Trash/cur/1589994796.M513796P2489.mail.aXXXXXXXXXXXe,S=21624,W=21996:2,S) failed: Decryption error: no private key available (read reason=prefetch)` Die Decryption-errors machen mir sorgen. Soll das heissen, alle meine Mails sind verschlüsselt mit einem Schlüssel, der jetzt weg ist?

Ich habe jetzt mehrfach versucht meine Mails zu importieren, habe dazu etwas gegoogelt und bin auf folgende Threads gestoßen: [https://github.com/mailcow/mailcow-dockerized/issues/2395](url) [https://community.mailcow.email/d/238-sogo-ladt-die-e-mail-ansicht-bei-einem-user-nicht-mehr](url) [https://github.com/mailcow/mailcow-dockerized/issues/516](url) Die dort stellenweise beschriebenen Lösungsansätze haben nicht funktioniert. Auch mit dem decrypt-script von [https://mailcow.github.io/mailcow-dockerized-docs/u_e-dovecot-mail-crypt/](url) bin ich nicht weiter gekommen, es fehlt immer der private key. Auch habe ich festgestellt, sobald ich meine alten Mails in Mailcow reinschiebe, kann ich weder Mails empfangen noch senden. Ich habe jetzt erstmal Mailcow frisch neu aufgesetzt, damit ich überhaupt wieder mails empfangen kann. Das alte Maildir habe ich noch auf meinem NFS-server und bin für jeden Tip dankbar, wie ich diese wieder reinbekommen kann.

Gibt es hier wirklich niemanden, der in der Situation war, wo er ein Maildir wiederherstellen musste, ohne die mail_crypt-keys der vorherigen Installation zu haben? Ich würde sehr ungern meine Mails der letzten 9 Jahre abschreiben...

Hi, du brauchst unbedingt den Key der "alten" Installation. Also das crypt-vol-1. Ich kann mir nicht so richtig vorstellen, dass du das gelöscht hast. Beim Update würde er das Volume nie löschen, in deiner History des Posts sehe ich auch nicht, dass du crypt-vol-1 gelöscht hättest. Hast du mal die Datei auf dem FS gesucht?

Ich habe leider ALLE volumes gelöscht, nachdem ich 2x hintereinander die o.g. Fehlermeldungen beim update bekommen habe. Zu ungeduldig gewesen, nicht nachgedacht... wenn ich Dich also richtig verstehe: Keine Keys, keine Kekse, sprich ich habe von meinen alten Mails nur noch Datenmüll... mehr als ärgerlich, aber kein Weltuntergang. Bzgl. des updates wundert es mich allerdings, warum das script meine volume-parameter verändert hatte. Das war bei den ganzen letzten Updates nie ein Problem.

Hast du denn direkt in der docker-compose.yml Dinge geändert? Oder wie empfohlen in der docker-compose.override.yml?

Ich habe direkt in der docker-compose.yml Änderungen drin gehabt, das mit der docker-compose.override.yml war mir nicht bewusst.

Oh, okay. In der override bleibt alles brav bestehen. :)

Vielleicht ein kleiner Improvement-Vorschlag: Wenn beim Update die docker-compose.yml geändert wird, kurze Warnung ausgeben "Du hast eine geänderte docker-compose.yml, die Änderungen gehen gleich verloren", als Bonbon vielleicht noch mit einem diff der Änderungen... ähnlich, wie man das von Debian-Systemen kennt. Das würde dann vielleicht Leute wie mich vor solchen Grandiosen Ideen bewahren... ;)

Update schief gegangen, wie mails wiederherstellen?

diekuh

Backups müssen nicht verschlüsselt werden. Das vmail-vol-1 Directory kann problemlos auf einem ausgelagerten Share liegen und muss auch nicht extra verschlüsselt werden. Das ist der Mehrwert, der per Standard aktiv ist und nicht ausgeschaltet wird, sorry.

Eine Edith: Mit mail_crypt_save_version = 0 ist sie aus. Verschlüsselter Altbestand kann weiterhin gelesen werden. 🙂 Zu ändern in der data/conf/dovecot/dovecot.conf.

hanswurst

diekuh liegt der Key aber nicht auch im Backup mit dabei?

« Previous Page