Manuell alle Indexe neu erstellen:
rm -rf /var/lib/grommunio-web/sqlite-index/*
/usr/sbin/grommunio-index-run.shDauert aber je nach Mailbox Größen einige Zeit, am besten in einem Screen laufen lassen.
grommunio-web korrumpiert Anzeige von Plaintextmails nach kopano-Import
- Edited
Ich reihe mich mal hier ein. Nach dem LDAP geht habe ich Konten im Testsystem von Kopano importiert. Wie hier schon beschreiben habe ich viele Mails die so aussehen:
Ich habe mit Kopano immer nur das Webinterface genutzt und Mails gelangen auf die Server nur per SMTP. Die Kopano Version ist 8.7.20.
Schaue ich mir die Mails per IMAP an passt alles. Nur im Webinterface sind Sie kaputt. Outlook werde ich nicht verwenden ...
Die Mail hier im Screenshot kommt übrigens von einem Gromox-Server. Hier mal noch die relevanten Daten:
X-Mailer: gromox-oxcmail 2.0.0.9a01c75
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0005_AD282F70.D942857"
This is a multi-part message in MIME format.
------=_NextPart_000_0005_AD282F70.D942857
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset="utf-8"Auch wenn ich mir per Webmail die Mail als EML herunterlade passt alles. IMHO ein Bug in der Webmail.
Beim Kopano Update auf 8.7.0.0. musste man diese diese Befehle ausführen:
service kopano-server stop
kopano-dbadm usmp
service kopano-server restartBeim Kopano Update 8.7.1.0 diese Befehle:
kopano-dbadm kc-1444
kopano-admin --clear-cache=0x0020wurde as gemacht?
- Edited
WalterH
Keine Ahnung, das Setup ist alt. Zumindest in der Shell-History finde ich das nicht. Was das UCS Update implizit macht weiss ich ebenfalls nicht.
Was ist da der Kontext, nur damit ich das verstehen kann. Warum passt alles per IMAP und das EML ist auch OK? Aus meiner Sicht ein reiner Darstellungsfehler 
Was mir gerade noch auffällt. Wenn man ganz frisch in die Webmail kommt und noch kein Mailinhalt angezeigt wird und klickt dann eine Mail die die nicht richtig dargestellt wird, dann wird die Mail erst ganz ganz kurz korrekt angezeigt und um dann kaput angezeigt zu werden.
Es gibt ja noch /var/lib/gromox/user/X/eml/* nebst dem eigentlichen MAPI-Store. Aus /eml/ wird auch wieder opportunistisch gelesen, wenn vorhanden. Ich tippe also drauf, dass bei einem Import via IMAP-Protokoll (IMAP APPEND o.ä.) der Transfer zu /eml/ ok war, der zum MAPI-Store hingegen nicht. Das ließ sich aber diesseits bisher nicht reproduzieren.
mahescho Ich empfehle eine SSH/Anydesk/Teamviewer-Sitzung. (support@grommunio.com mit Verweis auf den Thread.)
- Edited
Falls die mit mir sprechen wollen - und ich häng halt jetzt wieder 2 Tage
Noch Ideen? So kann ich nicht produktiv gehen ...
Wenn schon Jan sagt das man auf das System muss, hilft nichts anderes.
Hi Walther,
neues Indizieren hat geholfen.
Suchergebnisse kommen jetzt.. Danke für den Befehl.. den richtigen Gedanken hatte ich schon mal :-)
Leider ist die Anzeige der Mails unverändert.. So als Info, da ja offensichtlich Weiteres im Gange ist dem Thread zu folge.
Wenn DAV wieder geht, dann komme ich mit Thunderbird und IMAP erstmal zurecht.
Tolles Forum und tolle Community hier :-)
Grüsse,
Christian
Was hat Jan dazu gesagt?
Trigger: Mails, die Plaintext-only sind, und non-ASCII beinhalten.
Was passiert: Die on-the-fly-Konversion zu HTML produziert windows-1252 statt UTF-8. Man könnte jetzt "h� was?" erwarten, aber wie im Screenshot zu sehen hat g-web andere Pläne.
Short option: Überhaupt ist das Default 1252 sinnfrei, da g-web/zcore ohnehin in UTF-8 arbeiten. Also gibt's jetzt nen Workaround in gromox-2.0-73-ge673ff387 .
Long option: g-web wird noch weiter untersucht.