Uploads Failing on a Server That Still Has Free Space?

Uploads failing while the hosting dashboard shows plenty of free space is a particularly annoying kind of outage. The obvious explanation appears to have been ruled out. So somebody increases an upload limit, restarts a service or orders a bigger disk.

Before doing any of that, establish what could not be written, where the write happened and which account attempted it. Free gigabytes on one filesystem do not prove that an application can create a file on another. They do not even prove it can create a new file on the same one.

Start with the path that failed

An upload may pass through temporary storage before reaching its final directory. If temporary storage is the failing stage, inspecting only the website’s uploads folder sends you in the wrong direction. Containers, separate mounts and application-specific temporary directories add more opportunities to check the wrong place.

Find the actual error in the application or service logs. Keep the timestamp and affected request together. Identify the configured temporary path and destination path, then inspect each from the environment where the application runs. A host-level storage dashboard may describe a different view.

On a Linux system with GNU utilities, these read-only commands inspect the filesystem containing an existing path. Replace the example directory with your verified path:

df -h /actual/upload/path
df -i /actual/upload/path

The first reports space in storage blocks using readable units. The second reports inode usage. Run the checks against the temporary location too if it differs. Do not assume /tmp is the location merely because it is common.

Read the second capacity counter

On filesystems that expose a finite inode pool, files need available metadata capacity as well as data capacity. A very large population of small files can consume that pool while leaving considerable room for file contents. Uploading another small image still requires a new file to be created.

The following is an illustrative diagnostic comparison, not output from a customer server or a measured incident:

Filesystem behaviour matters. Do not carry assumptions about a fixed inode pool onto every storage technology. If inode figures are unavailable or unfamiliar, check the filesystem and hosting platform documentation. A dashboard percentage without its underlying resource and mount is weak evidence.

If the inode counter is healthy

Stay with the exact error. An account quota can prevent writes while the wider filesystem has room. The application can lack permission to create files in one directory even though your administrator account can. A read-only mount points to a different problem again. These are separate branches, not reasons to run the same cleanup command harder.

There are also failures that are not filesystem capacity failures at all. Request-size limits, application validation and interrupted requests can reject an upload before a destination file exists. Raising a limit only makes sense when the rejection identifies that limit. Otherwise it adds another configuration change to investigate later.

A successful test as an administrator is not sufficient. The relevant identity is the service account processing the request, with its own permissions, limits and view of storage.

Find the producer before deleting its files

If inode exhaustion is supported by the evidence, investigate the accumulation. File-backed sessions, application caches, queues and temporary exports are possible sources. The largest directory by bytes is not necessarily the directory holding the most files.

GNU du can help inspect inode consumption within a known application tree:

du --inodes --max-depth=1 --one-file-system /known/application/cache

This is read-only, but not cost-free: a large tree can take time and generate considerable filesystem activity. Start with a justified candidate path, consider the server load and avoid launching an unrestricted scan of the entire machine during an incident. Permission errors and mount boundaries also affect what you see.

Before cleanup, answer three practical questions:

• Which application owns these files, and are any still in use?
• What retention rule distinguishes disposable data from customer uploads, active sessions or queued work?
• What supported cleanup mechanism and recovery option exist for this directory?

Use the application’s supported expiry or cleanup process where one exists. If manual removal is necessary, define and review its exact scope first. An old modification date is not a universal permission to delete. Emptying a queue can erase work; removing session data can disrupt users; deleting the wrong cache can create a costly rebuild precisely when the server is struggling.

Then address why the population grew. Perhaps a scheduled cleanup stopped running, retention was never configured or an application now creates files much faster than expected. Freeing capacity without fixing the producer starts a countdown to the next failure.

Prove the repair through the application

Record the relevant counters before and after the repair. Repeat a small, permitted upload through the same application route and verify that it reaches the intended destination and can be retrieved. Check for a fresh error at that timestamp. Remove only the controlled test artefact through the normal application mechanism.

Watch the rate of growth afterwards. A temporarily lower inode count is useful evidence of recovery, but a rapidly rising count points to an unfinished repair. Monitoring should cover the resource that actually failed, alongside storage bytes and any applicable account quotas.

If the failure path or cleanup ownership is unclear, Advance IT Support can start with that evidence instead of a deletion guess. When the measurements show a genuine capacity mismatch, VPS hosting should be sized around the application’s file behaviour as well as its headline storage requirement.

Bring the error, the path, the service identity and both capacity readings. That is a useful incident brief. “The disk looks fine” is only the beginning of one.