On the XBackBone package, uploads larger than 1 GiB fail with HTTP 413. The package's Apache vhost (apache/xbackbone.conf) defines no LimitRequestBody, so Apache 2.4.58 applies its built-in 1 GiB default. Apache rejects the request before PHP is reached, so raising post_max_size/upload_max_filesize via /app/data/php.ini has no effect. The app's advertised limit (25 GB, derived from PHP) is therefore misleading.

Environment:

App: XBackBone (v3.8.2), base image cloudron/base:5.0.0
apache2 -v → Apache/2.4.58 (Ubuntu), built 2024-10-02
Modules: mpm_prefork_module, php_module (mod_php, PHP 8.3)
Standard Cloudron reverse proxy; no external proxy in front

Observed on my instance (Web Terminal):
LimitRequestBody is unset anywhere in Apache config or app code:

grep -rniE 'LimitRequestBody' /etc/apache2/ /app/code/  → no matches

PHP is not the limiter:

php -r '... ini_get ...'
post_max_size=25G
upload_max_filesize=25G
memory_limit=-1

Calling the container's Apache directly (localhost:80, bypassing the Cloudron proxy), bracketing 1 GiB:

curl -F upload=@900M   http://localhost:80/upload/web  → HTTP 302
curl -F upload=@1100M  http://localhost:80/upload/web  → HTTP 413

#response headers on the 1100M request:
HTTP/1.1 413 Request Entity Too Large
Server: Apache/2.4.58 (Ubuntu)

This confirms the 413 originates from the app container's Apache (not the Cloudron proxy), and the threshold is the 1 GiB Apache default. In the browser, the same upload surfaces as Server: nginx because the platform proxy relabels the response header.

Root cause:

Apache 2.4.54+ ships a default LimitRequestBody of 1 GiB (1073741824 bytes) instead of unlimited (CVE-2022-29404). Because apache/xbackbone.conf sets no explicit value, every upload is capped at 1 GiB regardless of PHP configuration or the app's stated maximum.

Impact:

The effective upload ceiling (1 GiB) contradicts both the UI's advertised limit and the documented php.ini tuning path.

The fix is not available to users: the vhost lives at /etc/apache2/sites-enabled/xbackbone.conf on the read-only container filesystem, LimitRequestBody cannot be expressed via php.ini or /app/data, and XBackBone's .htaccess sits in read-only /app/code. A package change is required.

Proposed fix:

Add an explicit LimitRequestBody to apache/xbackbone.conf, deferring the ceiling to PHP's post_max_size (the value users are already directed to set):

# Apache 2.4.54+ defaults `LimitRequestBody` to 1 GiB (CVE-2022-29404).
# Defer the upload ceiling to PHP `post_max_size` (set via /app/data/php.ini).
LimitRequestBody 0

Alternatively, derive LimitRequestBody from the effective post_max_size in start.sh so the two stay in sync. The docs at docs.cloudron.io/apps/xbackbone should also be updated, as they currently present php.ini as the sole upload-size control.

Verification for the fix:

After patching, upload a file > 1 GiB (e.g. dd if=/dev/zero of=test bs=1M count=1200). Currently returns 413; should succeed.

Reference:

Package file to patch: https://git.cloudron.io/packages/xbackbone-app/-/blob/master/apache/xbackbone.conf
Apache LimitRequestBody: https://httpd.apache.org/docs/2.4/mod/core.html#limitrequestbody

PS: Troubleshooting conducted & this summary prepared in collaboration with Claude