- Forum
- Main Forum
- English Section
- CWP Control
- Roundcube PDF attachment upload fails at 98% with “Server Error” — CWP/Nginx fix
×
Installation and guides about a great free, plesk and cpanel alternative project
Roundcube PDF attachment upload fails at 98% with “Server Error” — CWP/Nginx fix
- infogate
-
Συντάκτης θέματος
- Αποσυνδεμένος
- Administrator
-
- Imagination is the beginning of creation
2 Ημέρες 5 Ώρες πριν #347
από infogate
The best possible way to start your online marketing : fspirits.com/go/leadsleap-home
Explode Your Web Site Traffice: fspirits.com/go/sparktraffic
Start your affiliate journey here: fspirits.com/go/olsp-academy
Best Solution To Create Videos: fspirits.com/go/create-studio-pro
Best Solution To Create Graphics: fspirits.com/go/clickdesigns
Smart Chat Automation: fspirits.com/go/chatterpal
Multi-Purpose Video Maker: fspirits.com/go/avatar-builder
Multi-Purpose Video Creator: fspirits.com/go/video-creator
AI Human Spokesperson Videos: fspirits.com/go/humanpal
Roundcube PDF attachment upload fails at 98% with “Server Error” — CWP/Nginx fix δημιουργήθηκε από infogate
I’m posting this in case it saves someone else a few hours of debugging.
I had a strange issue on a CWP/Centos Web Panel server using Roundcube webmail.
Symptoms:
At first it looked like a Roundcube, PHP, quota, mailbox, or PDF/MIME issue, but it was not.
In Chrome DevTools → Network, the failed upload request showed:
So the real issue was a timeout during the Roundcube attachment upload request.
Things that were NOT the cause
PHP upload limits were already high:
Roundcube itself also showed a much higher allowed attachment size.
So the issue was not file size.
Root cause
The upload was timing out at the Nginx reverse proxy layer before Roundcube completed the attachment upload.
In this case, the important part was the Nginx proxy include file:
The fix was to normalize the proxy settings and make sure upload buffering/request handling was correct.
The most important line was:
This prevents Nginx from fully buffering the upload before passing it to the backend. For Roundcube AJAX uploads, this can prevent the upload from hanging near the end and returning a 408 timeout.
Fix used
Important: Backup first and do not reload Nginx unlesspasses.
If the test is successful:
Then test Roundcube again with the same PDF attachment.
Expected result
After the fix, the PDF attachment upload completes normally and the file appears in Roundcube.
Final working proxy settings
Make sure you have only one of each directive:
You can check with:
Extra note
During troubleshooting I also checked Roundcube/PHP intl/Spoofchecker issues, PHP upload limits, mailbox quota, Roundcube temp folder permissions, ModSecurity logs, and cwpsrv timeouts.
In this specific case, the final problem was the Nginx proxy upload handling, not Roundcube itself.
I hope this helps someone who sees PDF uploads stuck near 98% with a red Roundcube “Server Error”.
I had a strange issue on a CWP/Centos Web Panel server using Roundcube webmail.
Symptoms:
- User could send normal emails without attachments.
- Word documents uploaded correctly.
- Small PDF files failed.
- The PDF upload reached around 98% and then Roundcube showed a red:
Server Error! (error)At first it looked like a Roundcube, PHP, quota, mailbox, or PDF/MIME issue, but it was not.
In Chrome DevTools → Network, the failed upload request showed:
Status Code: 408
Request URL: /roundcube/?_task=mail&_remote=1&_from=compose&_id=...&_uploadid=...So the real issue was a timeout during the Roundcube attachment upload request.
Things that were NOT the cause
PHP upload limits were already high:
upload_max_filesize = 500M
post_max_size = 550M
memory_limit = 600M
max_input_time = -1
max_execution_time = 0Roundcube itself also showed a much higher allowed attachment size.
So the issue was not file size.
Root cause
The upload was timing out at the Nginx reverse proxy layer before Roundcube completed the attachment upload.
In this case, the important part was the Nginx proxy include file:
/etc/nginx/proxy.incThe fix was to normalize the proxy settings and make sure upload buffering/request handling was correct.
The most important line was:
proxy_request_buffering off;This prevents Nginx from fully buffering the upload before passing it to the backend. For Roundcube AJAX uploads, this can prevent the upload from hanging near the end and returning a 408 timeout.
Fix used
Important: Backup first and do not reload Nginx unless
nginx -tPROXY="/etc/nginx/proxy.inc"
TS="$(date +%F_%H%M%S)"
cp -a "$PROXY" "${PROXY}.bak_fix_duplicate_$TS"
python3 <<'PY'
from pathlib import Path
import re
path = Path("/etc/nginx/proxy.inc")
lines = path.read_text().splitlines()
wanted = {
"proxy_request_buffering": "proxy_request_buffering off;",
"proxy_buffering": "proxy_buffering off;",
"proxy_connect_timeout": "proxy_connect_timeout 600;",
"proxy_send_timeout": "proxy_send_timeout 600;",
"proxy_read_timeout": "proxy_read_timeout 600;",
}
seen = set()
out = []
for line in lines:
stripped = line.strip()
if stripped == "# Roundcube upload stability":
continue
m = re.match(r'^(proxy_request_buffering|proxy_buffering|proxy_connect_timeout|proxy_send_timeout|proxy_read_timeout)\s+', stripped)
if m:
key = m.group(1)
if key not in seen:
out.append(wanted[key])
seen.add(key)
continue
out.append(line)
if out and out[-1].strip():
out.append("")
out.append("# Roundcube upload stability - normalized")
for key, directive in wanted.items():
if key not in seen:
out.append(directive)
path.write_text("\n".join(out) + "\n")
print("proxy.inc normalized.")
PY
echo
echo "### Current proxy.inc"
nl -ba "$PROXY" | sed -n '1,80p'
echo
echo "### Test nginx"
nginx -tIf the test is successful:
systemctl reload nginxThen test Roundcube again with the same PDF attachment.
Expected result
After the fix, the PDF attachment upload completes normally and the file appears in Roundcube.
Final working proxy settings
Make sure you have only one of each directive:
proxy_request_buffering off;
proxy_buffering off;
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;You can check with:
grep -nE 'proxy_request_buffering|proxy_buffering|proxy_connect_timeout|proxy_send_timeout|proxy_read_timeout' /etc/nginx/proxy.incExtra note
During troubleshooting I also checked Roundcube/PHP intl/Spoofchecker issues, PHP upload limits, mailbox quota, Roundcube temp folder permissions, ModSecurity logs, and cwpsrv timeouts.
In this specific case, the final problem was the Nginx proxy upload handling, not Roundcube itself.
I hope this helps someone who sees PDF uploads stuck near 98% with a red Roundcube “Server Error”.
The best possible way to start your online marketing : fspirits.com/go/leadsleap-home
Explode Your Web Site Traffice: fspirits.com/go/sparktraffic
Start your affiliate journey here: fspirits.com/go/olsp-academy
Best Solution To Create Videos: fspirits.com/go/create-studio-pro
Best Solution To Create Graphics: fspirits.com/go/clickdesigns
Smart Chat Automation: fspirits.com/go/chatterpal
Multi-Purpose Video Maker: fspirits.com/go/avatar-builder
Multi-Purpose Video Creator: fspirits.com/go/video-creator
AI Human Spokesperson Videos: fspirits.com/go/humanpal
Παρακαλούμε Σύνδεση ή Δημιουργία λογαριασμού για να συμμετάσχετε στη συζήτηση.
- Forum
- Main Forum
- English Section
- CWP Control
- Roundcube PDF attachment upload fails at 98% with “Server Error” — CWP/Nginx fix
Χρόνος δημιουργίας σελίδας: 0.156 δευτερόλεπτα