Ohhh good !
it works like a charm !
I'll try the various functions but everything seems to be working as it should.

However, I think Roundcube should specify recommended nginx settings. I found very little about this, and all the settings were tied to older versions (from at least a few years ago).

Thanks again!

The error log shows that nginx is not spiting the path information so the issue is the nginx config not permissions.

Looking at your full config:
        root /var/www/html/public_html;
        index index.php;

        location / {
                try_files $uri $uri/ /index.php?q=$uri&$args;
        }

        location ~ ^/(README.md|INSTALL|LICENSE|CHANGELOG|UPGRADING)$ {
                deny all;
        }

        location ~ ^/(config|temp|logs|SQL|bin)/ {
                deny all;
        }

        location ~ /\. {
                deny all;
                access_log off;
                log_not_found off;
        }

        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info;
                include fastcgi_params;
        }

I think this block is capturing all the requests, lets remove it.
        location / {
                try_files $uri $uri/ /index.php?q=$uri&$args;
        }


You can remove these since the change in 1.7 they are no longer in the public directly and therefore can't be accessed anyways.
        location ~ ^/(README.md|INSTALL|LICENSE|CHANGELOG|UPGRADING)$ {
                deny all;
        }

        location ~ ^/(config|temp|logs|SQL|bin)/ {
                deny all;
        }

This block would only look at paths that end in .php, the problem is the static.php file paths don't end that way "/var/www/html/public_html/static.php/skins/elastic/deps/bootstrap.min.css" so lets replace with the block below.
        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info;
                include fastcgi_params;
        }

This block comes from alec's post and it looks for .php anywhere in the request path and I modified the fastcgi_pass to point to your unix socket. Try that and see if it works or gives you any different errors.
location ~ \.php(/.+)?$ {
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_index  index.php;
    include        fastcgi_params;
    fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
    fastcgi_param  PATH_INFO $fastcgi_path_info;
    fastcgi_pass   unix:/var/run/php/php8.2-fpm.sock;
}


See reply #1 above from JohnDoh: ask your email provider if they have a backup.

Quote from: JohnDoh on September 12, 2011, 10:55:20 AMboth roundcube and squirrelmail are just mail clients so they wont really help you. your best chance is to contact your mail provider as soon as possible and ask if they can restore the emails from backups.

Hi SKaero,

Our WAF configuration is the standard AWS set.

We have implemented the following fix which works when sending new emails:
$config['htmleditor'] = 1;
$config['dont_override'] = ['htmleditor'];

However, this is not working for saving drafts or editing as new existing emails.

Please can you advise if there is a workaround for this?

Hi All,
I have deleted the emails accidently. Is there any options are availabel to restore ? I have celared fromt he trash folders too
Your help will be much appreciated

+1

I'm no help, but came here looking for the same.

.... version 1.6.11 works perfectly.

The roundcube directory has owner www-data, upgrade to 1.7.beta done by "install-to.sh in /bin", as usual.

what about file access rights to files and folders in /var/www/html/ ?

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.