Probleme nach der Migration von Microsoft Exchange

kcizmesija

Hallo zusammen,

Etwa eine Woche nach der Migration ist das Postfach eines Benutzers beschädigt worden.
Wir konnten das Problem zunächst durch eine Reparatur der exchange.sqlite3 beheben, sodass das Postfach wieder funktionierte.

Allerdings ist derselbe Fehler nun erneut aufgetreten.

Aktuell haben wir jedoch ein Problem mit einem Benutzer, genauer gesagt mit einem freigegebenen Postfach.

Folgende Fehlermeldung erscheint im gromox-zcore:

get_store_properties /var/lib/gromox/user/domain.de/info₁: failed

Ich wäre Ihnen sehr dankbar, wenn sich zeitnah jemand melden könnte, um uns bei der Analyse bzw. Behebung des Problems zu unterstützen.

Ich habe bereits den Grommunio-Support kontaktiert, wollte aber auch hier noch einmal nachfragen.

Mit freundlichen Grüßen,
Karlo Cizmesija

WalterH

Mailbox Reparatur durchführen, hilft das?
gromox-mbck -p /var/lib/gromox/user/domain.de/info/exmdb/exchange.sqlite3

kcizmesija

WalterH Ich habe den Check auch ohne den Parameter -p ausgeführt, dabei werden 0 Issues gemeldet:

mail:~ # gromox-mbck /var/lib/gromox/user/domain.de/info~1/exmdb/exchange.sqlite3 == /var/lib/gromox/user/domain.de/info~1/exmdb/exchange.sqlite3 == ck_allocated_eids: [0 issues] ck_indices_present:

Das eigentliche Problem ist, dass die komplette Ordnerstruktur fehlt.
Die Verzeichnisse EML, EXT und CID enthalten jedoch alle Daten.

Merkwürdig ist, dass dieses Postfach bis heute einwandfrei funktioniert hat.
Ich kann mir aktuell nicht erklären, wie so ein Zustand entstehen kann.

DVCon

Gibt es im gromox-http Log eventuell noch interessante Meldungen?

kcizmesija

DVCon Ich habe mir gerade systemctl status gromox-http angezeigt.
Da kommen folgende Fehlermeldungen:
Jan 28 22:35:57 mail gromox-http[17347]: sqlite3_step(/var/lib/gromox/user/domain.de/info₁/exmdb/exchange.sqlite3) "SELECT config_value FROM configurations WHERE config_id=1": file is not a database (26)

DVCon

Willkommen im Club.
https://community.grommunio.com/d/2322-gromox-30/8

Starte gromox-htttp mit systemctl restart gromox-http einmal neu und schaue, ob das Postfach dann wieder funktioniert.
Mails, die in der Zwischenzeit für das Postfach eingegangen sind, liegen in /var/lib/gromox/queue/save.

kcizmesija

DVCon Vielen Dank für den Tipp, das Postfach ist wieder funktionsfähig.

Gibt es eine Möglichkeit, die E-Mails aus der Queue wieder in das Postfach zuzustellen?

Wissen Sie eventuell, wodurch ein solches Problem entstehen kann?

DVCon

Es gibt in der Doku einen Abschnitt für das Requeueing
https://docs.grommunio.com/admin/operations.html#mail-requeueing

Ich hatte damit aber bisher keinen Erfolg und habe die Mails per Hand mit gromox-eml2mt message.eml | gromox-mt2exm -u recipient@domain.tld -B inbox in den Posteingang importiert.

Leider steht die Lösung für das Problem noch aus.

kcizmesija

Das mit dem Info Postfach, hat alles wunderbar funktioniert und nochmal danke.

Aber ich habe jetzt paar andere Sachen aus gromox http Log rausgeholt.

Folgendes:
sqlite3_step(/var/lib/gromox/user/domain.de/username/exmdb/exchange.sqlite3)` "REPLACE INTO folder_properties VALUES (341, 1709375746, x'1612000000a5187b6fbcdcea1ed03c5657000000003ae7')": FOREIGN KEY constraint failed (19)

sqlite_busy on /var/lib/gromox/user/domain.de/username/exmdb/exchange.sqlite3: held by unknown, take from exch/exmdb/table.cpp:198

sqlite3_exec(/var/lib/gromox/user/domain.de/username/exmdb/exchange.sqlite3) "BEGIN": cannot start a transaction within a transaction (1) at [<libgromox_common.so.0(ZN6gromox11gx_sql_execEP7sqlite3PKcj+0xa0) [0x7ff5424fc05d]><libgromox_common.so.0(ZN6gromox13gx_sql_begin3ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEP7sqlite3NS_8txn_modeE+0x67) [0x7ff5424fc709]><libgxs_exmdb_provider.so.0(+0x9a7a7) [0x7ff54219c7a7]><libgxs_exmdb_provider.so.0(+0x5bef9) [0x7ff54215def9]><libgromox_emsmdb.so.0(+0x4ee97) [0x7ff54225ce97]><libgromox_emsmdb.so.0(+0x60787) [0x7ff54226e787]><libgromox_emsmdb.so.0(+0x76b2a) [0x7ff542284b2a]><libgromox_emsmdb.so.0(+0x774e5) [0x7ff5422854e5]><libgromox_emsmdb.so.0(+0x2d031) [0x7ff54223b031]><libgromox_mh_emsmdb.so.0(+0x2fb3) [0x7ff5422f5fb3]><libgromox_mh_emsmdb.so.0(+0x3a9e) [0x7ff5422f6a9e]><libgromox_mh_emsmdb.so.0(+0x66d2) [0x7ff5422f96d2]><libgromox_mh_emsmdb.so.0(+0x674c) [0x7ff5422f974c]><http() [0x412440]><http() [0x416154]><http() [0x416373]><http() [0x41758e]><http() [0x41b7fd]><libgromox_epoll.so.0(+0x37c9) [0x7ff5424d77c9]><libc.so.6(+0xa6f6c) [0x7ff540ea6f6c]><libc.so.6(+0x12e388) [0x7ff540f2e388]>]

W-1580: "username@domain.de" has reached the limit exchange_emsmdb.cfg:emsmdb_max_cxh_per_user (100)

Kann mir vielleicht da noch jemand helfen?

WalterH

kcizmesija exchange.sqlite3: held by unknown,

Da gibt es einen anderen Thread dazu. Die derzeit einzige Abhilfe ist den gromox-http täglich zu restarten, bis die Entwickler das gefixt haben.

DVCon

W-1580 ist wohl ein Sitzungs-Limit
https://docs.grommunio.com/man/exchange_emsmdb.4gx.html
Die anderen Meldungen sehe ich auch, weiß aber leider nicht, was sie bedeuten.

Seit der gromox cleaner aktiviert ist, kam hier gehäuft auch noch das dazu
E-5310: link /var/lib/gromox/user/domain.tld/username/eml/1762324757.l667.localhost -> /var/lib/gromox/user/domain.tld/username/eml/R-17/687c7ba603334849abb303780eb40517: No such file or directory
Meine Frage, ob das gefährlich ist oder nicht, verhallte im Ticketsystem.

Stefan_S

DVCon

Den Fehler E-5310 habe wir auch seit einiger Zeit im HTTP-Log.
Bei uns wird der Fehler ausgelöst, wenn ein User eine Mail in einen Unterorder verschiebt (Outlook).
Ich konnte bisher aber keine Problem (außer der Meldung im Log) feststellen.

kcizmesija

WalterH Danke für die Antwort und wir hoffen, dass es dann bald behoben wird.

DVCon

Stefan_S
Danke für den Hinweis. Ich hab's gerade getestet. Ja, eine Mail vom Posteingang in einen anderen Ordner verschieben generiert die Meldung.
Es fiel bei mir zeitlich in die Aktivierung des Cleaners. Deswegen hatte ich es irgendwie damit in Zusammenhang gebracht.
Der eml-Ordner war meines Wissens ja für den Fall erforderlich, wenn POP3/IMAP genutzt wird. Da das bei meinen Installationen so gut wie nicht verwendet wird, hatte ich auch noch keine Auswirkungen bemerkt.