Is 507 the client's fault or the server's?

The server's, almost always. 507 is a 5xx code, and the whole 5xx class means the server knows it failed and knows the failure is on its side. There is nothing wrong with your request — you could send the exact same bytes an hour later, after someone clears space, and it would succeed. That is the tell that separates 507 from its lookalikes. A 413 Payload Too Large means your body broke a configured size limit and you should send less. A 507 means the server had nowhere to put what you sent, no matter how small. One is a request problem you fix; the other is a server-capacity problem you wait out or escalate. Sending a smaller file might dodge a 507 by chance, but it doesn't fix anything — the disk is still full for the next person.

The disk has free space. Why am I still getting 507?

Check inodes, not just bytes. A filesystem tracks free space in two independent ledgers: raw blocks (what df shows) and inodes (one per file, what df -i shows). Millions of tiny files — session data, cache fragments, mail spool, PHP temp uploads — can exhaust every inode while gigabytes of block space sit unused. When inodes hit zero, the kernel refuses to create a single new file, and any handler that writes a temp file before responding returns 507 with a straight face while df swears there's plenty of room. It's one of the most confusing storage failures there is, because the obvious metric looks fine. Run df -i on the partition the app writes to. If inode use is at 100%, that's your 507, and deleting the small-file hoard fixes it — adding disk does not.

Is 507 the same as 508 Resource Limit Is Reached?

No. They share a neighborhood but not a cause. 507 Insufficient Storage (RFC 4918) is specifically about storage — the server can't store the representation your request needs, classically a full disk or exhausted quota. 508 is two different things depending on who emitted it: the real RFC 5842 code means Loop Detected, and the cPanel/CloudLinux page reusing that number means your hosting account blew its CPU, memory, or process budget. If the message says storage, disk, or quota, you're looking at a 507 problem — go find what filled up. If it says resource limit with cPanel branding, that's a 508 capacity problem and a different checklist.

Views: 28

507 Insufficient Storage: It's the Server's Disk

507 Insufficient Storage means the server ran out of room — a full disk, blown quota, or dead inodes. Find it in 3 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

A request that should have worked — an upload, a PUT, a form post, a file save in a web app — comes back 507 Insufficient Storage. The request itself is fine. The server is telling you, in the plainest terms the HTTP spec allows, that it had nowhere to put what you sent. Something on the server side is out of room: a disk, a quota, an inode table, or an internal buffer. The fix is never in your request; it’s in whatever filled up.

507 is defined in RFC 4918 §11.5, the WebDAV spec: “the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request.” It was born for WebDAV, but the meaning is so useful — I got your request, I just can’t store the result — that servers and frameworks well outside WebDAV now emit it for any storage-exhaustion condition.

Symptoms

Writes fail while reads succeed. Browsing the site is fine; uploading, saving, or posting returns 507.
The failure is sudden and total — it worked an hour ago, nothing in the code changed, and now every write 507s.
It clears the moment someone frees space, then comes back as the disk refills.
WebDAV, Nextcloud, SharePoint, a Git server, or an object-storage gateway returns 507 on PUT/POST but serves existing files normally.
df shows free space, yet writes still 507 — the classic inode-exhaustion trap.

What 507 Actually Means

507 says one thing: the server accepted your request and then couldn’t store what it needed to. That’s narrower than “the server broke.” A 500 is an unhandled exception; a 503 is the server refusing to serve at all; a 507 is a server that processed your request right up to the moment it tried to write, and hit a wall.

The wall is almost always one of three kinds of “full.”

Blocks are full. The partition the app writes to has zero free bytes. Upload directories, /tmp, the database volume, or a log partition that quietly grew until it swallowed the disk. Everything that needs to write a byte fails at once.

Inodes are full. This is the one that fools people. A filesystem can have gigabytes of free space and still refuse to create a file, because it has run out of inodes — the fixed-size table that holds one entry per file. A cache or session store spraying millions of tiny files exhausts the inode table long before it fills the disk. df looks healthy; df -i shows 100%; writes 507 anyway.

Quota is full. The disk is fine, but your slice of it isn’t. Shared hosting accounts, mailbox quotas, per-user disk limits, and object-storage buckets all cap how much one tenant can store. Blow the cap and you get 507 while the underlying volume has room to spare — the limit is policy, not physics.

The unifying idea: 507 is about capacity to store, not capacity to compute. That’s what separates it from the 5xx codes it sits next to.

Top Causes

The data partition is genuinely full - Uploads, logs, database files, or temp data grew until the volume hit 0 bytes free. Every write on that partition 507s until space is reclaimed. A runaway log file or an unpruned upload directory is the usual culprit.
Inode exhaustion with blocks to spare - Millions of small files (sessions, cache shards, mail, PHP upload_tmp_dir leftovers) used up the inode table. df says there’s room; df -i says there isn’t. Writes fail even though the disk looks half empty.
A per-account or per-mailbox quota was hit - The physical disk is fine, but the tenant’s allotment is exhausted. Common on shared hosting, WebDAV/Nextcloud user quotas, and mail stores. Raising or clearing the quota — not adding disk — is the fix.
An internal storage limit inside the app - Some frameworks and object-storage gateways return 507 when an in-process buffer, a configured max store size, or a backing bucket’s quota is exceeded, even when the host disk is fine. The limit lives in config, not in the filesystem.

Diagnose with DechoNet

HTTP Check reads the exact final status line and response headers the origin returns. That does two things fast. First, it confirms the 507 is coming from your origin and not from a proxy or CDN in front of it — the server signature in the headers tells you which box actually ran out of room. Second, it shows whether the 507 is constant or intermittent: a storage-exhaustion 507 that clears on a quiet retry behaves very differently from one that returns on every single write, and that split points you at “a disk that fills under load” versus “a disk that’s already full.” From there the on-server check is df -h and df -i on the partition the app writes to.

Resolution Checklist

Confirm the code and source. Run an HTTP check to verify it’s a real 507 from your origin, not a 413 (payload limit) or a 508 (resource/loop) wearing a similar message.
Check block space: df -h on the server. If the app’s partition is at 100%, find what filled it — du -sh /* or a targeted look at logs, uploads, and temp dirs — and reclaim space.
Check inodes: df -i on the same partition. If inode use is at 100% while blocks aren’t, hunt the small-file hoard (old sessions, cache fragments, orphaned temp files) and delete it. Adding disk won’t help here.
Check quotas. If block and inode space are both fine, the limit is a per-account, per-mailbox, or per-bucket quota. Raise it or clear space within the allotment.
Look at the app’s own storage config. Object-storage gateways and some frameworks cap store size independently of the disk; a 507 with a healthy filesystem points here.
Fix the growth, not just the symptom. Rotate and cap logs, prune temp and cache directories on a schedule, and alert on disk and inode usage before either hits 100%. A 507 you clear by hand comes straight back if nothing pruned the thing that filled up.

When to Escalate

If you don’t control the server — shared or managed hosting — and df isn’t yours to run, escalate to the host with the exact time and the failing operation. Their side can see which volume or quota tripped in seconds.
If block space and inodes are both healthy and quotas aren’t the cause, the 507 is coming from inside the application or an upstream storage service. That’s an app-config or object-storage issue, not a filesystem one — take it to whoever owns that layer.