Permission Model Conflict During Apache to LiteSpeed Migration
Summary
On April 3, 2026, WAYSCloud performed a controlled migration of a production node from Apache (mod_ruid2) to LiteSpeed Enterprise. During the initial switch, hosted websites on the node returned errors due to a mismatch between Apache's per-user execution model and LiteSpeed's process-based access model. The issue was immediately detected, rolled back within minutes, and resolved through a corrected permission model aligned with cPanel FileProtect. All services were fully restored, and the system is now operating under the intended LiteSpeed configuration baseline.
What Happened
On April 3, 2026, WAYSCloud performed a controlled migration of a production node from Apache (mod_ruid2) to LiteSpeed Enterprise.
During the migration, a temporary service disruption occurred due to a permission model mismatch between the two webserver architectures. The issue was immediately detected, rolled back within minutes, and resolved without lasting impact.
All services are now operating under the intended LiteSpeed configuration baseline.
The root cause was a mismatch between Apache's per-user execution model and LiteSpeed's process-based access model. Apache with mod_ruid2 executes requests as the account user, with FileProtect setting document roots to USER:USER 0750. LiteSpeed runs the main web server process as nobody, while PHP executes as the account user via LSAPI. This model requires group-level access through USER:nobody 0750.
After the initial switch, LiteSpeed could not read .htaccess files or serve static content because the document roots were still aligned to the Apache mod_ruid2 model.
All systems are stable and operating under the new configuration baseline.
Impact
Temporary service disruption during a brief migration window. Scope was limited to web-serving on a single node. Affected services returned HTTP 403 and 404 errors during the initial switch. There was no data loss and no security impact. Full service was restored immediately after rollback.
No customer data or configuration was affected. This was limited to a single node and did not impact platform-wide services.
Actions Taken
The issue was resolved by aligning filesystem permissions with LiteSpeed's execution model.
The node was switched to LiteSpeed, which automatically changed the execution mode. FileProtect was then re-applied, updating document roots to the correct ownership model for LiteSpeed (USER:nobody 0750).
After this correction, all active services became immediately accessible and stable.
Preventive Measures
A LiteSpeed deployment runbook has been established for this node class. The required permission model for LiteSpeed environments has been documented. Operational guardrails have been added to avoid re-enabling mod_ruid2 and to ensure FileProtect remains enabled. The migration procedure has been updated to include post-switch permission validation.