A Nextcloud upload that stops at 2 GB is usually being limited by one layer in the request path, not by a single universal Nextcloud setting. To accept larger files, set a target above the file size at every layer that handles the upload: PHP, the web server, and any reverse proxy or hosting panel. Then confirm that storage, temporary space, and request timeouts can support the transfer.
This guide uses a 5 GB target as an example for files up to about 4 GB. Choose a limit that matches your real use case, leave headroom for request overhead where applicable, and keep the setting consistent across your stack. The examples apply to a self-managed Nextcloud Server using PHP; managed hosting, containers, and appliances may expose different configuration paths.
Why a 2 GB upload can fail
Nextcloud’s current administration manual explains that large uploads can be constrained by PHP and web-server configuration. With chunked uploads, the browser or client sends pieces that Nextcloud assembles; some PHP file-size directives may not govern those requests, while web-server or PHP timeouts still can. A proxy, firewall, storage backend, user quota, or full temporary disk can impose another limit. See the Nextcloud large-file upload administration guide and the Nextcloud user guide to large uploads.
“2 GB” may also mean 2,000,000,000 bytes or 2 GiB (2,147,483,648 bytes). A displayed limit and an actual byte threshold may not match exactly. Record the error, the file size in bytes, and whether the failure happens immediately or after progress begins. Those details help identify which layer to inspect.
1. Identify the first layer that rejects the upload
Before changing settings, note how the file is uploaded: Nextcloud web interface, desktop or mobile sync client, or WebDAV application. Test a file slightly larger than the old threshold, but do not repeatedly upload a multi-gigabyte file while troubleshooting. Check Nextcloud’s administration overview and log, the web-server error log, PHP-FPM or Apache logs, and any proxy or hosting dashboard at the failure time.
- An immediate HTTP 413 response often points to a web server or proxy request-body limit.
- A PHP warning about a file exceeding an allowed size points to PHP upload settings for a conventional multipart request.
- A transfer that starts but stalls or times out suggests request timeouts, an interrupted connection, or resource pressure.
- A clear quota message means the user’s available Nextcloud storage, rather than the server upload cap, is the obstacle.
These are clues, not conclusive diagnoses: a proxy can replace an application error, and logs differ by deployment. Compare timestamps across layers before editing configuration.
2. Set PHP limits for browser form uploads
Find the PHP configuration used by the web-facing Nextcloud process. On Debian or Ubuntu, a typical PHP-FPM file is under /etc/php/<version>/fpm/php.ini; Apache with mod_php commonly uses a separate apache2/php.ini. The PHP command-line configuration can be different, so editing the file reported by php --ini alone may not change the website. Nextcloud’s PHP configuration guidance describes the server-side configuration context.
For a 5 GB ceiling, review these settings in the active web PHP configuration:
upload_max_filesize = 5G
post_max_size = 5G
max_input_time = 3600
max_execution_time = 3600
post_max_size should be at least as large as upload_max_filesize; setting both to the same target is a practical starting point for a single-file multipart upload. The time values above are examples, not a guarantee that a transfer will finish: choose a duration that suits your available bandwidth and operational policy. Do not increase PHP’s memory_limit to 5 GB just because the file is 5 GB. PHP documents that max_input_time includes time spent receiving upload input and that upload behavior depends on related directives; consult the PHP upload pitfalls documentation.
3. Raise the web-server request limit
Nginx with PHP-FPM
In the active Nginx server block for Nextcloud, set a request-body cap above the largest file you intend to accept. For the 5 GB example:
client_max_body_size 5G;
Place it in the appropriate http, server, or location context, avoiding a conflicting lower value in a more specific block. Nginx documents this directive in its core module reference. Nextcloud’s Nginx installation example also includes upload-size and timeout settings. Validate the configuration with sudo nginx -t before reloading Nginx.
Apache
Check whether the active virtual host, directory configuration, or included configuration sets LimitRequestBody. On Apache versions where a default or explicit cap is lower than your target, raise it to the required byte count or use 0 for no Apache-level limit only if that is acceptable for your deployment. Confirm the directive is placed in a context allowed by your Apache version and configuration. Apache describes its behavior in the LimitRequestBody documentation. Run apachectl configtest before reloading the service.
4. Check reverse proxies, containers, and storage
If traffic passes through another Nginx instance, a load balancer, a hosting control panel, or a security proxy, its body-size and timeout limits must also permit the upload. A request can be rejected before it reaches Nextcloud. Update only the layer that owns that setting, then inspect its logs and response code. For Docker or another container deployment, change the configuration mounted into the running container or the supported environment settings for that image; a host PHP file may not be used by the container at all.
Large uploads also consume resources. Confirm that the Nextcloud data volume has enough free space and that the PHP or web-server temporary directory can accommodate the workload. With chunked uploads, temporary space may be needed while chunks are assembled; object-storage deployments can need additional temporary disk. Plan for simultaneous uploads, not just one maximum-size file. Review Nextcloud’s section on temporary space and large-file uploads before raising the limit in a busy installation.
5. Apply changes and verify with a controlled test
After configuration checks pass, reload or restart the relevant PHP-FPM and web-server services so they read the updated settings. The exact service names vary by distribution and PHP version. Avoid restarting unrelated production services. Then upload a file just above the previous 2 GB cutoff—such as a known test file around 2.1 GB—using the same client and route that originally failed. Keep the test below your new limit and monitor free disk space, logs, and transfer progress.
A successful test should finish without an HTTP size error or timeout, appear in the intended Nextcloud folder, and have a plausible file size when checked from the client. For an important file, compare a checksum at the source and destination if your workflow supports it. A progress bar reaching 100 percent alone does not verify that the stored file is complete.
When this fix is not enough
- The web upload works, but the desktop client fails: inspect client, proxy, and server timeout behavior. Nextcloud clients use chunked uploads, so changing PHP’s
upload_max_filesize alone may not resolve a chunk request or final assembly timeout.
- The error says the user is out of space: adjust that user’s Nextcloud quota or free storage; increasing the request limit will not create capacity.
- Failure occurs at the same byte count for every client: look for a shared proxy, WAF, hosting-provider, or web-server cap and correlate its logs with the request.
- Uploads complete but consume too much temporary disk: reduce concurrent uploads, ensure adequate temporary storage, or review the documented chunking and storage behavior for your backend.
Raising the upload limit expands what users can send to the server, so it should be paired with quotas, monitoring, sufficient storage, and sensible access controls. There is no universal safe maximum: the practical ceiling depends on the slowest limit in the request path and the capacity of the server and storage system.
References