Locate the failed write and its actual filesystem and account limits before requesting a targeted capacity remedy; do not delete unrelated files or broaden permissions.
A website message saying No space left does not tell you which storage resource is exhausted. The affected operation might write to an upload directory, a temporary area or a different service from the one shown in the hosting dashboard. Establish the failing path and operation before choosing a remedy.
Imagine a fictional illustrator whose website displays existing pages normally but cannot accept a new portfolio upload. The account overview reports spare storage. Repeated attempts create more confusion, so the owner records the first error and asks the authorized operator to trace that upload’s write route. This example is a diagnostic plan, not a report of a live server test.
Preserve the failure evidence and pause avoidable retries
Record the action, approximate time, affected site and user-visible outcome. Did the upload never appear, did its entry appear without a usable file, or did the operation claim success despite the error? Avoid repeatedly submitting an important file until you understand whether the application has already accepted part of the operation.
The access and error log guide explains how an authorized operator can correlate the event. Ask for the specific component and attempted path from a private log, not a public error dump. A timestamp and a concise sanitized description are more useful than a screenshot containing account paths, customer documents or credentials.
Keep the original file and any unsaved work outside the failing operation. If normal publishing remains possible, do not trigger large exports, imports or maintenance tasks merely to collect more evidence. Agree who owns the recovery and what customer-facing work should wait while capacity is uncertain.
Match the capacity report to the actual destination
GNU’s df documentation describes reporting the filesystem associated with a supplied path. Its human-readable byte and inode modes answer different capacity questions. Ask the operator to inspect the filesystem for the failed destination, not just a convenient home directory. Other operating systems and hosting interfaces may use different controls.
In the illustrator’s case, an account total is not enough. The operator needs to identify where the upload first lands and where the finished file belongs. If those locations differ, obtain the relevant report for each. A healthy final destination does not settle whether the earlier stage can accept the file.
| Evidence to request | The question it answers | A targeted next step |
|---|---|---|
| Failed operation and exact write path | Which stage and destination could not complete? | Identify the responsible service and authorized operator |
| Capacity for the containing filesystem | Does this report describe the failing location? | Compare available bytes and inode capacity there |
| Quota for the writing account | Does this account still have an allowance? | Ask for the specific exceeded limit and its remedy |
| Temporary and final upload routes | Can both stages accept the intended file? | Review the demonstrated failing stage before retrying |
Retain the time of each report. A screenshot from before a failed backup or import may describe a different situation. When reports disagree, resolve their scope and timestamps before concluding that the dashboard is wrong. Ask what is measured and whether the displayed figure is current.
Distinguish capacity, quota and other write errors
The Linux open manual distinguishes ENOSPC from EDQUOT: the latter can reflect an account’s block or inode quota. It also distinguishes permission and read-only failures. The application’s short message may hide those distinctions, so ask for the underlying error before choosing a capacity fix.
Our hosting limit guide provides the broader resource vocabulary. Here the objective is narrower: explain this particular failed write. Do not infer that every file operation fails because one upload does, or that extra advertised storage necessarily changes the specific limit involved.
The operator might find a filesystem capacity problem, a per-account allowance or a different error altogether. Keep these as alternative hypotheses until the evidence identifies one. Do not make files world-writable, change ownership broadly or disable isolation to see whether a storage symptom disappears. Those actions introduce different risks without establishing the cause.
Include temporary storage in an upload diagnosis
PHP’s upload_tmp_dir guidance requires a writable upload temporary directory. PHP can use the system default when none is specified or the configured directory is unwritable; with open_basedir enabled, that fallback must be permitted. Review the effective web runtime configuration rather than assuming the final media folder is the only destination.
Ask the authorized operator which runtime handles the request and what temporary route it actually uses. A command-line check under another account is not automatically a reproduction of the website’s upload. Record the effective environment and the observed error without publishing a diagnostic page that exposes configuration to visitors.
If the upload reaches a temporary file but fails when the application creates the final result, that is a different boundary from failure before temporary storage. Use the existing application evidence to identify the stage. Do not add an unrestricted public upload endpoint as a troubleshooting shortcut.
Choose a remedy that has an owner and a preservation plan
A useful recovery proposal states the demonstrated limit, the affected location and the change that addresses it. Examples include a provider correcting the relevant allocation, or an authorized maintainer reviewing a known regenerable workload under the application’s documented procedure. The proposal should explain how required content, backups and other sites are preserved.
Do not browse shared hosting folders and remove the largest-looking items. A file can be required by a different application, a recovery process or a retention obligation. Even an apparently old archive needs an identified owner and a verified alternative before a responsible person decides what to do with it. This guide does not authorize deletion.
If evidence instead points to the filesystem access route, use the WordPress filesystem diagnosis guide. Changing a permission does not create capacity, and buying capacity does not fix the wrong ownership. Escalate with the exact demonstrated boundary rather than requesting a broad reset of the hosting account.
Rehearse one controlled write after the targeted repair
- Confirm that the authorized operator completed the agreed remedy for the correct site and location.
- Review the current capacity or quota report for that same location before resuming work.
- Use one small, harmless file through the normal supported workflow and record the outcome.
- Verify the application record and the usable resulting file rather than accepting a success banner alone.
- Check the relevant private log for recurrence, then resume larger work gradually under the agreed plan.
For the fictional portfolio, success means the supported upload produces a usable image in the intended place and the original write failure no longer recurs in that controlled check. It does not establish that every background job or other hosted site has been tested. Keep the failed-path evidence with the recovery note so a later capacity warning can be compared with the same measured resource.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- GNU Coreutils manual: df filesystem reportingChecked A path selects its filesystem; human-readable byte and inode reports answer different capacity questions.
Limits: GNU options are not guaranteed to match another operating system or hosting interface. - Linux manual: open errorsChecked ENOSPC and EDQUOT differ; quota exhaustion can concern blocks or inodes.
Limits: An application message may conceal the actual operating-system error and failed path. - PHP manual: upload_tmp_dirChecked Uploads require a writable temporary route; fallback and open_basedir constrain it.
Limits: This directive does not locate every application’s work files or prove a hosting fault.