Uploading a large zip file to Moodle succeeds, but extracting it (for example in Private files, or any file manager that offers “Unzip”) fails with a generic error. The reason is that Moodle keeps the original archive in the file area while unpacking, so extraction needs room for the zip plus its uncompressed contents at once, and that combined size is checked against the file area’s size limit, not against the per-file upload limit that let the zip in.

Two different limits, and why that matters

There are two distinct kinds of limit, and the unzip failure is about the second one:

  1. The per-file upload limit caps the size of a single uploaded file. It is the minimum of PHP's upload_max_filesize and post_max_size, the site limit ($CFG->maxbytes), and the course/activity limit. This governs getting the zip in, and it is usually not the problem here.
  2. The file-area size limit (areamaxbytes) caps the total size of everything in a given file area at once. For Private files this comes from $CFG->userquota. This is the limit the unzip operation actually checks.

The trap is that these are different numbers. A zip can be small enough to upload, then fail to extract because the zip plus its contents exceed the area limit. Note that a plain File resource does not impose an area limit at all, so the failure typically shows up in Private files or other quota-bound areas rather than when adding a File resource to a course.

Why the math catches you out

Consider a 600 MB zip file containing a large SCORM package or video collection. The actual uncompressed size is also approximately 600 MB. During extraction:

  • The zip file remains on disk: 600 MB
  • The extracted files are written alongside it: 600 MB
  • Peak combined usage: ~1.2 GB

If the area limit is 1 GB, extraction fails. The upload succeeded because 600 MB is under 1 GB. The extraction fails because the zip plus its extracted contents, ~1.2 GB in the area at once, is not.

The error message Moodle shows, something like “Cannot unzip file”, does not explain this. It looks identical to a corrupt zip or a permissions error.

Finding which limit is triggering

If the failure is in Private files (the most common case), the area limit is the user quota. Check it at:

Site administration > Security > Site security settings > User quota

The user quota ($CFG->userquota) is the total a user may hold in their private files area. The zip plus its extracted contents must fit under it simultaneously, which is the ~2x requirement. Users with the moodle/user:ignoreuserquota capability are exempt, which is why an administrator may not reproduce a learner's failure.

Confirm the zip did clear the separate per-file upload limit (it almost always did, since it uploaded). The effective upload limit is the minimum of the PHP, site, and course values; cross-reference PHP with:

php -r "echo ini_get('upload_max_filesize'), ' / ', ini_get('post_max_size'), PHP_EOL;"

The fix

Raise the area limit so the zip and its contents fit at once. For a Private files failure, that means temporarily increasing the user quota to at least twice the zip size:

Site administration > Security > Site security settings > User quota

Extract the zip, then return the quota to its normal value. Because the user quota is site-wide, do not leave it inflated permanently. An alternative that avoids changing the quota at all is to grant the affected user the moodle/user:ignoreuserquota capability for the extraction, then remove it.

Avoiding the problem

Do not try to “extract on the server” by unzipping into moodledata directly. Moodle stores file content by SHA1 content hash with matching rows in the mdl_files table, so loose files dropped into the filesystem are not recognised, and there is no CLI tool to register them after the fact. Work through Moodle's own file handling instead.

The cleaner long-term fix is to avoid pushing very large archives through a quota-bound area at all. For SCORM packages specifically, many authoring tools can produce smaller packages by splitting large assets (video) out of the SCORM zip and referencing them as external resources, which keeps both the upload and the extracted footprint well under the limits.

Solin provides Moodle administration, configuration, and end-user support.

Contact us