Error when searching large mailboxes

Yep. I issued a sudo service php7.2-fpm restart after increasing default_socket_timeout. It did not help.

I saw somewhere else (a cPanel forum, I believe) where similar UID SEARCH errors – but not this exact error – were due to corrupted user prefs in the database, and clearing them may help. Unfortunately, I do not know where to look or what command to run to do so with MIAB. See for that thread.

Also increase execution_time in php.ini like you did the other option.

Unfortunately, that didn’t help either. I also tried increasing max_input_time.

Is there anything in /var/log/nginx/error?

a few ActiveSync timeouts.

Anyone? Being unable to search my mailboxes is a show-stopper for me. I keep all sorts of things in my email archives. I’ve had to resort to grepping through the mailboxes from the shell, and that’s not a viable long-term solution.

Actually, I think I just fixed it. After some more digging, I found that mailinabox is setting roundcube’s imap_timeout to 15 seconds. I increased this (in my case, to 360 seconds, which may be overkill) by editing /usr/local/lib/roundcubemail/config/ , and now my searches work!

Keep in mind that when you update, that file may or may not be overwritten.

I just discovered I have this problem as @mcl has had, but doing everything here didn’t solve my problem.

Background: both my wife and I have mailboxes that are over 9GB each. We would get the same error as described by the OP both in the UI and in the logs.

System description: v0.44 on a 4 x vCPU VM with 4GB vRAM configured on a 544GB vDisk.

However, I did finally manage to solve the problem doing this one extra step to what @mcl did. This includes modifying timeouts for the files:


And that was done with the following change:

        #keepalive_timeout 65;
        keepalive_timeout 180; 

Now the error has stopped and full text searching the entire mailbox or sub-folders all seem to work as expected. :slight_smile:

So I thought I had fixed this… at least it worked for a day or so, but now it’s back. It times out with this error right at 60 seconds. The changes I mentioned above in various config files are still there, so don’t understand why it’s timing out after 60 seconds. Watching the VM performence indicators show that disk activity starts thrashing upon execution of the search & CPU activity ramps up as well, and continues for up to 2-3 minutes after the server produces this error (at 60 seconds in) on the Webclient.

So it would seem that the search is still continuing on the server, but the web client is timing out too early at 60 seconds.

Any one have any thoughts or suggestions of where to look to resolve this?

Thanks in advance


Check your /etc/nginx/nginx.conf file. I bet that your change was reverted by MiaB during daily maintenance.

Nope, it hasn’t changed, still is the same. This is what I have in there now.

sendfile on;
tcp_nopush on;
tcp_nodelay on;
#keepalive_timeout 65;
keepalive_timeout 300;
types_hash_max_size 2048;
# server_tokens off;

Here’s some more reasons why I think it’s a forced timeout issue from the Webclient perspective.

If I narrow down a full text search to “Unread” messages, then I have success with the search. I get 173 returned emails, but those are only Unread messages containing that search keyword. (BTW, I only have Body defined for the search, nothing else.). This takes about 40-50 seconds… just before the 60 second timeout error is produced on larger searches.

Of course, what I’m looking for is in a Read message, so this doesn’t help me. So if I revert it back to “ALL” messages to be searched, it reverts back to “Server Error! (Error)” or “Server Error! (Gateway Timeout)” error states in the Web client. This error comes up right at 60 seconds after starting any search. Always.

This is frustrating more for my wife, as she can’t use her old El Captain based Email client due to the TLS issue. I got her over to using the WebClient instead until she can afford to buy a new Mac (major purchases are on hold until Corona times are over). But she immediately ran into this issue trying to search her emails for some personal business info.

It’s like MailintheBox / Roundcube isn’t honouring that change to nginix.conf timeout properly.

And the crazy thing is I know we never had these problems with previous versions of MailintheBox - as I’ve been using the Webclient for all my email for more than a year, and have used the full text search to successfully search bodies of emails before (and my Email mailbox is bigger than hers at 13GB), so I feel a recent upgrade has introduced this bug. :frowning:

BTW, these are the only log outputs (via nginx access and error logs in /usr/log/nginx) that I see:

==> error.log <==

2020/05/24 15:44:35 [error] 1648#1648: *7429 upstream timed out (110: Connection timed out) while reading response header from upstream, client: [Client IP Addy Redacted], server:, request: “GET /mail/?_task=mail&_action=search&_interval=&_q=[Keyword redacted]&_headers=body&_layout=widescreen&_filter=ALL&_scope=base&_mbox=INBOX&_remote=1&unlock=loading1590327814408&=1590326452908 HTTP/2.0”, upstream: “fastcgi://unix:/var/run/php/php7.2-fpm.sock”, host: “”, referrer: “

==> access.log <==

[Client IP Addy Redacted] - - [24/May/2020:15:44:35 +0200] “GET /mail/?_task=mail&_action=search&_interval=&_q=[Keyword redacted]&_headers=body&_layout=widescreen&_filter=ALL&_scope=base&_mbox=INBOX&_remote=1&unlock=loading1590327814408&=1590326452908 HTTP/2.0” 504 176 “” “Browser version blah blah redacted”

I actually had this thought initially before you were making changes to nginx.conf … problem is that I am not good on the back end. I think that you may get some better traction opening this as an issue on the project’s git hub page.

1 Like

Thanks. I’ll try that. :slight_smile:

Thanks @alento.

In fact, it has been filed already. And from the pull-request I found what seems to have made it finally work again as expected.

In short manually adding the “fastcgi_read_timeout 300;” statement to my nginx.conf file made all the difference. Searches now can sail past the 60 second timeout value and return full results.

Also note, I reverted a lot of the other changes to timeouts (in /etc/php/7.2/cli and fpm) made as testing has proven these are not necessary. They are now back at their defaults.

Only two changes are needed to realise the fix to the problem.

The first is to change the IMAP timeout in:
$config[‘imap_timeout’] = 300;

and the second change is to add “fastcgi_read_timeout 300;” to

    http {
            # Basic Settings
            sendfile on;
            tcp_nopush on;
            tcp_nodelay on;
            keepalive_timeout 65;
            types_hash_max_size 2048;
            # server_tokens off;
            fastcgi_read_timeout 300;
            # server_names_hash_bucket_size 64;
            server_names_hash_bucket_size 128;
            # server_name_in_redirect off;

            include /etc/nginx/mime.types;
            default_type application/octet-stream;

            # SSL Settings

Here is the source pull request where I found those fixes.

I just searched 60,000+ emails for the word “the” (thinking that would be most abusive) and it works perfectly now. :smiley:

@mcl I would be curious if this fixes your same / similar problem.

I hope it helps you like it helped me. I can now close my wife’s trouble ticket. :smiley:

1 Like

Well…that fixed it… but wait, there’s more. :rofl:

I was able to do some searches (by placing the server under some other load) that need more than 3 minutes to complete, but right at 3 minutes, I now consistently get this error:

I’ve been scouring the configuration files, trying to find a timeout of 180 seconds / 3 minutes specified somewhere, but cannot seem to find them.

I did a:
tail -f /var/log/mail.log /var/log/syslog /var/log/nginx/access.log /var/log/nginx/error.log

as I was doing the searches, and besides connection notifications, there’s no information in the logs that reveals why the Request Timed Out. But clearly I’m hitting a barrier somewhere.

This is an example of the type of search I’m attempting to perform…just choose an arbitrary name that I knew would be in my email box to test with. If I narrow the scope to just current Inbox or folder, than it will work in under 3 minutes successfully. But would be nice to have the full search scope option working as well.

My Mailinabox is running on a VM which resides on a i5 2.7-3.1Ghz CPU, with 4 cores dedicated to the VM and 4GB of RAM. The vDisk resides on a fast Samsung SSD. My mail file has 60,000 email messages. So I could imagine anyone with a machine less specs may also come up against this barrier as well.

Will continue to plunder ahead and try to find out the cause, but if anyone has an idea or guess they could suggest where I should look, it would be appreciated.

Hi @cowboy

I had one last MiaB install still running on Ubuntu 14.04 - I know, I know…

Anyways, it is now running mostly well on Ubuntu 18.04 with v 0.48.



The fix you proposed in 22 is not seeming to work for me. :frowning: Do you have any other info at this point??


Have you been able to find a way to fix this. I also have the same problem. I cannot do search I’m getting the UID error.