cPanel File Manager Upload Fails? Fix Size Limits

You drag a 40 MB zip or a fresh WordPress theme into cPanel's File Manager, hit upload, and watch the progress bar crawl to some random percentage before it just... stops. No error, no explanation, or a red banner that reads "The uploaded file exceeds the upload_max_filesize directive." Here's why File Manager caps out on bigger files and the fastest ways around it.

Symptom

This shows up in a few slightly different flavors depending on what's blocking you:

• The upload bar fills up, then resets to 0% or freezes at a fixed percentage (often around 95-99%) and never finishes.
• You get an explicit message: The uploaded file exceeds the upload_max_filesize directive in php.ini.
• The browser tab just hangs, then eventually times out with a generic "server not responding" error.
• Small files (under a few MB) upload fine; anything bigger fails consistently.
• You see a 413 "Request Entity Too Large" or a blank white screen instead of a clear message.

Why This Happens

File Manager's upload button looks like a simple drag-and-drop tool, but under the hood it's a PHP script handling the file transfer, not a raw FTP-style copy. That means every PHP limit that applies to a normal web form applies here too - and those limits are tuned for small form submissions, not multi-hundred-megabyte files.

1. upload_max_filesize and post_max_size

These two php.ini directives set the actual ceiling. upload_max_filesize caps a single file; post_max_size caps the entire POST request (which needs to be equal to or larger than upload_max_filesize, or uploads silently fail even under the per-file limit). Most shared hosting accounts default to something like 64M or 128M for both - fine for images and plugin zips, not fine for a database dump or a video file.

2. max_execution_time and max_input_time

Even if the size limit is high enough, a slow connection can still lose the race against the clock. max_input_time governs how long PHP waits for the upload data to arrive; max_execution_time governs how long the script itself can run. On a default 30-60 second limit, a large file over a slow upload connection just gets cut off mid-transfer.

3. Server-side hard caps you can't override

On shared hosting, WHM/cPanel administrators can set an absolute ceiling for upload sizes that a user-level php.ini or .htaccess override cannot exceed. If you set upload_max_filesize = 2048M in your own MultiPHP INI Editor but the server enforces a lower ceiling, your setting is quietly ignored and the smaller limit wins. This is by design - it stops one account from starving shared resources for everyone else on the node.

4. A WAF or mod_security rule blocking the POST

Some security rulesets flag unusually large POST requests as suspicious, especially if the file has an executable-sounding extension or the request looks automated. This usually shows up as a 403 or a connection reset rather than a clean "file too large" message, which makes it easy to mistake for a plain size-limit issue.

The Fix

Step 1: Check and raise your PHP upload limits

In cPanel, go to Software → MultiPHP INI Editor, select your domain, and switch to Editor Mode. Set:

upload_max_filesize = 512M
post_max_size = 512M
max_execution_time = 300
max_input_time = 300
memory_limit = 512M

Save and re-test. If your host doesn't expose MultiPHP INI Editor, the same values often work in a .user.ini file dropped in public_html (PHP-FPM setups) or an .htaccess block for mod_php setups:

php_value upload_max_filesize 512M
php_value post_max_size 512M
php_value max_execution_time 300

Don't set these absurdly high "just in case" - a huge memory_limit paired with a busy site can make a runaway script eat far more RAM than it should. Match the value to what you actually need to upload.

Step 2: Confirm the change actually took effect

Upload a small PHP file called phpinfo.php containing <?php phpinfo(); ?> to your document root, load it in a browser, and search the page for upload_max_filesize. If the value shown doesn't match what you set, either the wrong PHP version is selected in MultiPHP Manager, or the server has a hard cap you can't override - which brings you to Step 3. Delete this file once you're done; leaving a public phpinfo page live is an easy way to leak server details.

Step 3: Skip File Manager entirely for big files

If the server enforces a low ceiling you genuinely can't raise, don't fight File Manager - use a transfer method that doesn't go through PHP at all:

• FTP/SFTP: A client like FileZilla connects directly to the file system and isn't bound by PHP's upload directives. This is the most reliable option for anything over 100-200 MB.
• SSH + wget/curl: If the file is hosted somewhere else, SSH in and pull it directly onto the server: wget https://example.com/bigfile.zip. This is often the fastest option since the transfer happens server-to-server.
• SCP from your local machine: scp bigfile.zip username@yourserver.com:~/public_html/ moves the file without touching PHP or the browser at all.

Step 4: Rule out a WAF block

If you're getting a 403 or reset connection rather than a clean size-limit error, check Security → ModSecurity in cPanel (if available on your plan) for a triggered rule around the time of the failed upload. On a Getwebup VPS with CSF/ModSecurity active, the audit log at /usr/local/apache/logs/modsec_audit.log will show the exact rule ID that fired, which you can then adjust or whitelist for your account.

Prevention

• Set a realistic, permanent upload limit for your account (e.g., 256M) instead of raising it ad hoc every time you hit the wall.
• Default to FTP/SFTP for anything over roughly 100 MB - it's faster and doesn't depend on PHP configuration at all.
• For database dumps specifically, upload via SSH and import with mysql -u user -p dbname < dump.sql instead of pushing them through File Manager or phpMyAdmin.
• If you're on a VPS, keep an eye on PHP-FPM pool memory when you raise memory_limit across multiple sites - it adds up fast under concurrent uploads.