Ever since successfully upgrading to v0.41, I’ve received the following error when I attempt to search large mailboxes, or across all mailboxes:
An error occurred!
Server Error: Failed to send UID SEARCH command
I’ve searched the forums and github, but have been unable to find anything that fixes it.
Is there anything I should change to fix this? I tend to search my mail quite a bit, so this is rather frustrating.
Can you give the output in the logs around that line? it will give better context.
There does not appear to be a lot of context. There is nothing relevant in /var/log/roundcubemail/errors, and the only thing that coincides and seems relevant is in /var/log/mail.log:
Jul 10 08:16:41 imap(user@domain): Info: Connection closed (UID SORT running for 16.093 + waiting input for 0.001 secs, 0.001 in locks, 35 B in + 0 B out, state=wait-external) in=106 out=1546
The error itself, which I quoted in my original post, appears in the GUI, not the logs.
Additional info: When searching for the error with respect to roundcubemail, I found the following: default_socket_timeout needs to be increased in php.ini to reduce/eliminate the error. I’ve attempted to do this (changing the value from 60 to 180 in /etc/php/7.2/cli and fpm), with no success. I tried increasing it to 360, but the error still occurs.
After changing the value in php.ini (for FPM) you must restart the FPM service:
systemctl restart php-fpm (or php7.2-fpm) It’s been awhile since I’ve ran MIAB so package names might have changed.
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 https://forums.cpanel.net/threads/error-in-imap-command-uid-search-unknown-argument.653875/ 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/config.inc.php , 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:
/usr/local/lib/roundcubemail/config/config.inc.php
/etc/php/7.2/fpm/php.ini
/etc/php/7.2/cli/php.ini
And that was done with the following change:
/etc/nginx/nginx.conf
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. 
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. 
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: domain.com, 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: “domain.com”, referrer: “https://domain.com/mail/?_task=mail&_mbox=INBOX”
==> 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 “https://domain.com/mail/?_task=mail&_mbox=INBOX” “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.