Quote from: SKaero on November 01, 2025, 01:18:40 PMIf you changed the mail_host in the database before you logged in it shouldn't have created a new user since it looks for that match to find a user record. Turning off the "auto_create_user" if it can't find a matching username and mail host the login will fail.

that is exactly what I did and in the order I listed. BUT I found my mistake! The new host in the config file was tls://hostname.com  and I entered this the exact same way; tls://hostname.com and that incorrect entry created the new user.

As I tried it again today, entering in the config file tls://hostname.com and in the database only hostname.com everything was working fine. Addressbooks were accessible.

Just wanted to finish this up.
Thank you for your time and help. 

If you changed the mail_host in the database before you logged in it shouldn't have created a new user since it looks for that match to find a user record. Turning off the "auto_create_user" if it can't find a matching username and mail host the login will fail.

Thank you SKaero for the quick reply.
After inspecting the contacts table I noticed that each contatct has it's user_id set. Later I noticed also when scrolling down the user table, that RC had created a new user with the new mail host after login. I didn't expected that, as I had changed the mail_host in the following order:

1. changed mail_host in the config file
2. changed mail_host in db to the one in the config file
3. logged in

Never expected that a new user would be created, as the same (old) user had now already an entry matching the new mail_host.
Maybe one should disable beforehand the option in the config file (if set) to create a new user automatically. Would that prevent this behavior ?

I still have to change the mail_host, having quite a few users and the chance to accidentally delete the wrong user ......  Ok, making a backup of the RC-db is self explanatory.

Interestingly, changing the username and logging in does not create a new user entry.

In the "users" table in the database you should see a record for each user for the old mail host and one for the new mail host (value is stored in the "mail_host" column) you'll need to update the old user account records to the new mail host so the correct contacts are shown.

Hello,
using RC-1.6.0 I have to change the mail host for our users. I did this in the config file and in the database. Login was ok and all mailfolders with messages are shown. So far so good. What is missing is the addressbook. It is the build-in addressbook.  Reverting back to the "old" mail host, all contacts are there.

Anyone had this situation and know how to get the addressbook back when changing the mail host ?

Thank you.

OK, I've commented try_files sections.
The error persist, no skin.

these are the errors in log:

*****************************
2025/11/01 01:22:57 [error] 1901155#1901155: *14 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: mail.xxx.xxx, request: "GET /vendor/autoload.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php/php8.2-fpm.sock:", host: "mail.xxx.xxx"
2025/11/01 01:22:57 [error] 1901155#1901155: *14 open() "/var/www/html/public_html/favicon.ico" failed (2: No such file or directory), client: xxx.xxx.xxx.xxx, server: mail.xxx.xxx, request: "GET /favicon.ico HTTP/2.0", host: "mail.xxx.xxx", referrer: "https://mail.xxx.xxx/vendor/autoload.php"
2025/11/01 01:23:40 [error] 1901155#1901155: *14 access forbidden by rule, client: xxx.xxx.xxx.xxx, server: mail.xxx.xxx, request: "GET /config/config.inc.php HTTP/2.0", host: "mail.xxx.xxx"
2025/11/01 01:27:50 [error] 1901154#1901154: *18 open() "/var/www/html/public_html/static.php/skins/elastic/deps/bootstrap.min.css" failed (20: Not a directory), client: xxx.xxx.xxx.xxx, server: mail.xxx.xxx, request: "GET /static.php/skins/elastic/deps/bootstrap.min.css?s=1759310275 HTTP/2.0", host: "mail.xxx.xxx", referrer: "https://mail.xxx.xxx/"
2025/11/01 01:27:50 [error] 1901154#1901154: *18 open() "/var/www/html/public_html/static.php/skins/elastic/styles/styles.min.css" failed (20: Not a directory), client: xxx.xxx.xxx.xxx, server: mail.xxx.xxx, request: "GET /static.php/skins/elastic/styles/styles.min.css?s=1759310266 HTTP/2.0", host: "mail.xxx.xxx", referrer: "https://mail.xxx.xxx/"
2025/11/01 01:27:50 [error] 1901154#1901154: *18 open() "/var/www/html/public_html/static.php/plugins/jqueryui/themes/elastic/jquery-ui.min.css" failed (20: Not a directory), client: xxx.xxx.xxx.xxx, server: mail.xxx.xxx, request: "GET /static.php/plugins/jqueryui/themes/elastic/jquery-ui.min.css?s=1759310265 HTTP/2.0", host: "mail.xxx.xxx", referrer: "https://mail.xxx.xxx/"
2025/11/01 01:27:50 [error] 1901154#1901154: *18 open() "/var/www/html/public_html/static.php/program/js/jquery.min.js" failed (20: Not a directory), client: xxx.xxx.xxx.xxx, server: mail.xxx.xxx, request: "GET /static.php/program/js/jquery.min.js?s=1759310271 HTTP/2.0", host: "mail.xxx.xxx", referrer: "https://mail.xxx.xxx/"
2025/11/01 01:27:50 [error] 1901154#1901154: *18 open() "/var/www/html/public_html/static.php/program/js/common.min.js" failed (20: Not a directory), client: xxx.xxx.xxx.xxx, server: mail.xxx.xxx, request: "GET /static.php/program/js/common.min.js?s=1759310265 HTTP/2.0", host: "mail.xxx.xxx", referrer: "https://mail.xxx.xxx/"
*****************************

yes try...and what about error.log and composer ?

Chrome gives more details for SSL errors in the console but maybe Firefox doesn't, I don't have a site that has the issue to confirm.

I'm sure the issue isn't with Roundcube since Roundcube isn't responsible for the SSL encryption that is always handled by the web server.

If the error comes up only when viewing some HTML emails it most likely is due to something in the HTML in the email. Is there anyway you can send me the source of one of the emails that triggers the error?

Quote from: SKaero on October 30, 2025, 05:37:48 PMThat error shouldn't be related to the SSL error, what browser are you using?

Firefox 144.0.2

I also checked the server logs and there are no errors in the server log, only normal access log in the access log.

I believe this problem was not here for over 6 months of this year. It just started happening recently; I don't remember exactly when but I think after the last Roundcube update, but not sure.

That error shouldn't be related to the SSL error, what browser are you using?