Diagnosing Webmail 'Invalid Request' Session Errors on the Server (Roundcube/Plesk)

This is the server-side companion to the client-facing guide How to Fix the Webmail Error "Invalid Request. No Data Was Saved." It is written for administrators and self-managing server owners with shell access who need to confirm, on the server, why a user is seeing that webmail message. It is an internal and advanced reference, not client-facing help: send clients to the guide above for the resolution steps.

The diagnostic approach here applies to any control panel that ships Roundcube webmail: establish the ground truth, then exclude each candidate cause on evidence. The specific commands and paths shown are for Plesk Obsidian on Debian 12 with the stock Roundcube it ships (the psa-roundcube package), not the Plesk Premium Mail extension. On another panel the same checks apply against that panel's Roundcube paths and logs. Throughout, <domain> is the placeholder for the affected domain.

Last reviewed: 27 July 2026, against Plesk Obsidian 18.0 (latest stable) and the stock Roundcube it ships. This reference is written for Noiz-managed servers and is kept current against Plesk. It complements, and does not replace, the official Plesk and Roundcube documentation linked below.

Official Documentation Reference

• Roundcube webmail project: the upstream webmail software, its configuration reference and session handling.
• Plesk Obsidian Administrator's Guide: the official reference for the mail stack and webmail that Plesk ships and manages.

The Short Version

The client message "Invalid request. No data was saved." is almost always the ordinary Roundcube session inactivity timeout: the browser submits a request token that no longer matches a live server-side session, and Roundcube refuses the request rather than writing partial data. This is a shipped default, not a fault. The single most important thing to know before you start digging is that the ordinary expiry path writes nothing to the server logs, so an empty error log is consistent with this cause, not evidence against it.

Server-Side Verification Procedure

Establish the Ground Truth First

Before forming any hypothesis, establish what is actually running and what is actually configured. Do not assume a version, a path, or a default value.

# Roundcube version
grep -rhoE "RCMAIL_VERSION',[[:space:]]*'[^']+'" /usr/share/psa-roundcube/ 2>/dev/null | head -1

# What is actually overridden locally (defaults apply to everything absent here)
grep -vE "^[[:space:]]*(//|#|/\*|\*|$)" /usr/share/psa-roundcube/config/config.inc.php

# The settings that matter, from stock defaults
grep -nE "\$config\['(session_lifetime|session_storage|ip_check|log_logins|session_debug|debug_level)'\]" /usr/share/psa-roundcube/config/defaults.inc.php

# Log location and rotation state
ls -la /var/log/plesk-roundcube/

Stock Roundcube on Plesk logs to /var/log/plesk-roundcube/errors. If the Plesk Premium Mail extension is installed the path is /var/log/roundcubemail/errors.log instead. Check which applies before grepping, and adjust the paths in the commands below to match.

Work Through the Exclusions

Each command below is read-only. Run one block, confirm its output, and read what that output proves or excludes before moving to the next.

# Server-side equivalent of the browser message, where it logs at all
zgrep -h "Request security check failed" /var/log/plesk-roundcube/errors /var/log/plesk-roundcube/errors.1 /var/log/plesk-roundcube/errors.*.gz 2>/dev/null

# Frequency by day - establishes whether this is systemic or baseline noise
zgrep -h "Request security check failed" /var/log/plesk-roundcube/errors /var/log/plesk-roundcube/errors.1 /var/log/plesk-roundcube/errors.*.gz 2>/dev/null | awk -F'[][]' '{print $2}' | awk '{print $1}' | sort | uniq -c

# Session row write failures (concurrent requests racing the same session)
zgrep -hE "DB Error.*Duplicate entry.*session" /var/log/plesk-roundcube/errors /var/log/plesk-roundcube/errors.1 /var/log/plesk-roundcube/errors.*.gz 2>/dev/null | sed -E "s|'[A-Za-z0-9+/=]{100,}'|'<vars>'|g"

# Session table health - rules out storage degradation or failed garbage collection
MYSQL_PWD=$(cat /etc/psa/.psa.shadow) mariadb -uadmin roundcubemail -e "SELECT COUNT(*) AS rows_total, MIN(changed) AS oldest, MAX(changed) AS newest FROM session; SELECT COUNT(*) AS stale_over_24h FROM session WHERE changed < NOW() - INTERVAL 1 DAY;"

# Cookie scope - rules out competing cookies from dual entry paths
for u in "https://webmail.<domain>/" "https://webmail.<domain>/roundcube/"; do
  echo "--- $u"
  curl -sk -D- -o /dev/null "$u" | grep -iE "^(HTTP/|location:|set-cookie:)"
done

# HTTP-layer correlation for the affected domain
zcat -f /var/www/vhosts/system/<domain>/logs/access_ssl_log* | grep -a "_task="
zcat -f /var/www/vhosts/system/<domain>/logs/access_ssl_log* | grep -a "_err=session"
zcat -f /var/www/vhosts/system/<domain>/logs/access_ssl_log* | grep -a "_task=" | grep -aE '" [45][0-9]{2} '

# Referer check - exposes bookmarked post-login URLs
zcat -f /var/www/vhosts/system/<domain>/logs/access_ssl_log* | grep -a "_task=" | grep -aoE '"https://[^"]*index\.php\?_user=[^"]*"' | sort | uniq -c

What Each Result Means

• ip_check false: rules out client IP churn, proxy IP restoration, and CDN egress rotation as a cause. Do not pursue those.
• Session table with zero rows stale beyond 24h: garbage collection is working and storage is healthy. Rules out session backend degradation.
• Both entry paths returning roundcube_sessid with path=/: one cookie scope, no competing cookies. Rules out the dual entry path (DocumentRoot plus the /roundcube/ alias) as a cause.
• "Request security check failed" appearing only a handful of times across months, server-wide: baseline noise. It does not account for a single user reporting recurring problems, because the ordinary expiry path writes nothing at all.
• No _err=session entries: expected, and not an exclusion. When the session has lapsed, Roundcube renders the login page at the requested URL rather than redirecting, so the absence of _err=session does not rule out expiry.
• Duplicate entry errors on the session table: concurrent requests holding the same session ID. This is commonly caused by security-suite link scanners or browser prefetch re-fetching webmail URLs from a different address moments behind the user. Cosmetic in isolation. Run a whois on the requesting IPs before drawing any conclusion.

State the central diagnostic point plainly, because it is where most investigations go wrong: the ordinary expiry path produces no server-side log entry at all, so an empty error log is consistent with this cause rather than evidence against it. Absence of evidence in the Roundcube log is the expected result here, not a dead end.

Optional Instrumentation (Changes Live Configuration)

The following overrides add logging that can confirm the pattern on a stubborn case. Treat this as a change that alters live configuration: apply it deliberately, one change at a time, and remove it once the case is understood.

$config['log_logins'] = true;      // writes to /var/log/plesk-roundcube/userlogins.log
$config['session_debug'] = true;
$config['debug_level'] = 1;

Note that /usr/share/psa-roundcube/config/config.inc.php can be replaced by a package update, so any override placed there belongs under version control and should be re-checked after every Plesk update. Raising session_lifetime is a deliberate security and usability trade-off, not a default remedy: it should only be changed with explicit sign-off, never as a first response.

Reusable AI Prompts

The two prompts below are written to be pasted, as they stand, into an AI assistant that has shell access on a Plesk mail server. Use Prompt A to diagnose a reported case, and Prompt B to walk a client through the resolution. They are complete prompts, not summaries.

Prompt A: Diagnosis

You are assisting a Plesk mail-server administrator diagnosing intermittent
webmail failures where users see "Invalid request. No data was saved."
The platform is Plesk Obsidian on Debian 12 with stock Roundcube
(the psa-roundcube package), not the Plesk Premium Mail extension.

Work strictly from evidence. Do not assume any path, version, or config value.

1. First establish the ground truth before forming any hypothesis:
   - the running Roundcube version,
   - the active log location (stock is /var/log/plesk-roundcube/errors;
     the Premium Mail extension uses /var/log/roundcubemail/errors.log),
   - and exactly which settings are overridden in config.inc.php versus
     left at defaults.inc.php.

2. Then exclude these causes, on evidence, in this order, and after each one
   state which hypothesis you have killed and the exact output that killed it:
   a. ip_check (client IP churn / proxy / CDN egress rotation),
   b. session storage health (session table row counts and stale rows,
      confirming garbage collection is working),
   c. cookie scope (that both entry paths return one session cookie at path=/,
      ruling out competing cookies from the dual entry path).

3. Then correlate at the HTTP layer in the domain's access logs
   (/var/www/vhosts/system/<domain>/logs/access_ssl_log*): look at _task=
   requests, 4xx/5xx responses, and Referer values that expose bookmarked
   post-login URLs.

4. Treat an empty Roundcube error log as CONSISTENT WITH session expiry, not
   as an exclusion: the ordinary expiry path writes nothing to the log, so its
   absence is the expected result, not proof the cause is something else.

Rules: issue exactly ONE read-only command block at a time and wait for me to
paste the output before continuing. Never assume a path or config value you
have not read. Never assert a conclusion without quoting the log line or query
result that supports it. End by listing each hypothesis you tested, whether it
was killed or survived, and the specific output that decided it.

Prompt B: Resolution

You are helping a client resolve a webmail message that reads
"Invalid request. No data was saved." on a Plesk-hosted mailbox using
stock Roundcube webmail. The underlying cause is the webmail session's
inactivity timeout, which is a shipped default of the webmail software,
not a fault or an outage.

Before proposing anything server-side, confirm that the cause is this shipped
default rather than a genuine fault. Only once that is established should any
server-side change even be discussed.

Give the client this sequence, in this order:
1. Sign in again (this clears most occurrences).
2. If it persists, clear cookies and site data for the webmail address, close
   the browser fully, reopen, and sign in again.
3. Check the bookmark or saved shortcut and replace it with the plain webmail
   address only, https://webmail.<domain>, then sign in from there.
4. Try a different browser or a private/incognito window.

Explain that step 4 is a DIAGNOSTIC, not a permanent fix: it confirms whether a
stale session was the cause, but the timeout applies in every browser, so it
cannot be switched off by changing browser.

Check specifically for a bookmarked post-login URL, because bookmarking the
address shown after login (which carries one-time session and mailbox
parameters) is a frequent trigger.

For anyone who keeps mail open all day, recommend a desktop mail application
(Mozilla Thunderbird is the free cross-platform option), because a mail
application holds its own connection and is not subject to the webmail session
timeout.

Treat raising the webmail session_lifetime as a deliberate security-and-
usability trade-off that requires explicit sign-off, NOT as a default remedy.
Do not offer it as the first answer.