This is weird. If I run the Console command, it says there are no configured mail accounts, but if I use the web UI, and click on ‚Fetch Mail‘, it works. If I look in the db directly, there is an entry in the mail_accounts table.

otobo@997c99e8bd0b:~/Kernel$ ~/bin/otobo.Console.pl Maint::PostMaster::MailAccountFetch

No configured mail accounts found!

This is the regular docker install, but I guess that I might have overwritten the config as I used my existing database.

I didn’t migrate the data, I simple attached the database by updating the Kernel>Config.pm

You are 100% correct, the value for the container is wrong because that was how I had it in my original deployment.  I am struggling to work out how to fix it as the field in the database is a blob. I cant find where in the System Config I can fix this.

OK, I think I worked that one out phpMyAdmin allows me to edit the blob by uploading a file.

Hmmm, that didn’t work.  It still is using localhost. I have tried rebuilding and sync’ing the config and stop and restarting the daemon.  No luck so far.

Well I don’t know what I have done but the ElasticSearch is now working, I am using the console.pl script Maint::Elasticsearch::Migration to load the history. 30% of tickets so far but looks good.

Running Maint::PostMaster::MailAccountFetch also now works. But I haven’t done anything that I am aware of that might have had an impact there.

BUT, the web interface no longer works at all.  I cant seem to find any error logs anywhere that give a clue as to what is happening. The URL just times out

Solved, our fail2ban service had put my IP address into our boundary firewall.  Haven’t worked out why yet but at least I have access again. So, mail working again, elasticsearch not generating errors – progress.  At one point I had an input field at the top of the agent screen labelled elastic search.  This has also vanished so I am now on the hist to try to work out how to get that back again.

Got that one nailed now too. Now hopefully with a functional system will see if has cured the issue with un-parsable emails.

Finally getting to the bottom of the Email Parsing issue.  There seems to be an issue with MariaDB and collation.  I get the following error;

DBD::mysql::db do failed: Incorrect string value: ‚\xF0\x9F\x98\x8A\x0A\x0A…‘ for column otobo.article_data_mime.a_body at row 1 at /opt/otobo/Kernel/System/DB.pm line 556.
ERROR: OTOBO-otobo.Console.pl-Maint::PostMaster::Read-10 Perl: 5.36.0 OS: linux Time: Mon Aug 29 23:21:07 2022

Message: Incorrect string value: ‚\xF0\x9F\x98\x8A\x0A\x0A…‘ for column otobo.article_data_mime.a_body at row 1, SQL: ‚
INSERT INTO article_data_mime (
article_id, a_from, a_reply_to, a_to, a_cc, a_bcc, a_subject, a_message_id,
a_message_id_md5, a_in_reply_to, a_references, a_content_type, a_body,
incoming_time, content_path, create_time, create_by, change_time, change_by)
VALUES (
?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ‚2022-08-29 23:21:07‘, ?, ‚2022-08-29 23:21:07‘, ?
)

But the collation appears to be correct – it is currently utf8-general-ci, maybe its supposed to be mtf8mb4

Yep, finally got there.  The DB and all the tables need to be utf8mb4 and utf8mb4-general-ci.  So converting to the docker version was probably a waste of time but did have the benefit of learning more stuff.