Yes your file limit is calculated directly from your disk quota, at a fixed ratio: 500 files per GiB of disk quota, plus a 25% burst allowance on top. It is not set independently, and it is not a flat number per terabyte of hardware.
Your plan carries two separate limits, and either one can stop you writing:
- Disk space how many bytes you can store.
- File count (inodes) how many individual files and directories you can create.
Every file, every directory, and every symlink uses exactly one inode, whether it holds 2 bytes or 40 GiB. So a library of millions of tiny files can exhaust the file limit while most of your disk space sits unused.
The formula
Two numbers are set from your quota:
- Soft limit = disk quota in GiB × 500 files (minimum 15,000 files)
- Hard limit = soft limit × 1.25
The hard limit is the wall. Cross it and new files fail immediately with Disk quota exceeded, and torrent clients and media apps start throwing errors.
The soft limit is a warning you can exceed but only for a grace period. Sit above it past that window and the soft limit starts blocking writes exactly as the hard limit does, even though you are nowhere near the hard number. Treat the soft limit as the figure to stay under, not as a suggestion.
The same 1.25 burst applies to your disk space, so both limits behave the same way.
What that works out to
| Disk quota | Soft file limit | Hard file limit |
|---|---|---|
| 1 TiB | 512,000 | 640,000 |
| 2 TiB | 1,024,000 | 1,280,000 |
| 4 TiB | 2,048,000 | 2,560,000 |
| 10 TiB | 5,120,000 | 6,400,000 |
These rows are provisioned disk quota, which is not always the round number in the plan name a plan sold as 1 TB is commonly provisioned at 910 GiB, giving a hard limit of 568,750 rather than 640,000. When your service is reconfigured, on an upgrade or a downgrade, the file limit is recalculated from the new quota at the same ratio.
For your own account, quota -s is the authority. It reports the exact numbers in force on your service, and those are the ones that matter.
The number that actually matters: your average file size
Turn the ratio around and it tells you something more useful. To fill your disk without running out of files, your average file needs to be about 2 MiB or larger that is 1 GiB divided by 500. Riding the burst allowance buys you down to roughly 1.6 MiB, but that is the ceiling, not somewhere to live.
Below that, the file limit arrives first. At an average of 0.5 MiB you will reach your soft file limit at roughly a quarter of your disk space. That is not a fault it is arithmetic, and it is why the limit can feel like it appeared out of nowhere on an account that looks mostly empty.
Check your own average with one command over SSH:
find ~ -xdev -type f -printf '%s\n' | awk '{c++;s+=$1} END{printf "Files: %d | Avg: %.2f KiB\n",c,s/1024/c}'Checking where you stand
The quota meter in your control panel gives you the quick view. For the exact numbers, read them straight from the server over SSH:
quota -sThis prints both limits side by side blocks (disk space) and files (inodes) with your current usage and both the soft and hard values.
To find what is consuming the files:
du --inodes -h --max-depth=3 ~ | sort -hr | head -40That sorts your directories by file count rather than size, which is usually enough to identify the culprit in a few seconds.
Common causes, and what to do
Media stacks are the usual source. Creating enormous numbers of very small files is normal operation for them:
- Plex / Jellyfin turn off preview thumbnails, intro detection, and lyric and metadata agents. Thumbnail generation alone can produce hundreds of thousands of files.
- rclone raise
--vfs-cache-chunk-sizeto 64–128 MiB and clear the old cache. Small chunks mean many more cache files. - Sonarr, Radarr, and the rest of the *arr stack use hardlinks rather than copies, so a file is not duplicated on import.
- Large libraries of tiny files comics, ROMs, ebooks, datasets. Packing these into a
.taror squashfs image collapses thousands of inodes into one. Do not do this to files you are actively seeding. Your torrent client needs those files exactly where and as they are; archiving them breaks the torrent and stops the seeding. Archive only what your client is not serving. - Docker container image layers are made of many small files. Removing unused images and containers reclaims a surprising number.
Deleting files frees the count immediately, so writes start working again straight away. Your panel meter may take a little longer to catch up, since it refreshes on a schedule trust quota -s over the meter in the minutes after a cleanup.
If your workload genuinely needs the files, a larger disk quota is the answer, since the file limit scales with it. A plan upgrade is the usual route see how to upgrade or downgrade your service. If you are not sure which plan fits your file counts, ask us and we will work it out with you.
Why the limit exists
Millions of tiny files carry costs that do not show up in the space they occupy. Every file operation touches the filesystem metadata tables, so small-file workloads generate metadata IOPS far out of proportion to the data moved. The kernel caches inode and directory entries in RAM, so one account with millions of files eats memory belonging to the whole server. On RAID5 arrays, each small metadata write becomes a read-modify-write cycle across the array.
Without a file limit, one account can degrade every other account on the same server. The limit is what keeps that from happening.
A second limit you may see
If you run df -i you will see much larger numbers than your quota. Those belong to the server's filesystem as a whole, shared by everyone on it, and they are not your allowance quota -s is.
That pool works differently, and the difference is worth knowing. A filesystem's total inode count is fixed permanently when the volume is created, derived from a bytes-per-inode ratio chosen at that moment. It cannot be grown afterwards without rebuilding the filesystem. Pulsed Media provisions storage volumes at standard inode density for exactly that reason: a volume tuned for large files alone would leave far too little headroom for the small-file workloads our customers actually run. We track inode density across our servers and factor it into where accounts are placed.
If you are still stuck
Open a ticket and tell us what quota -s reports and which application is misbehaving. If your usage looks legitimate and the limit is simply the wrong shape for your workload, say so we would rather find you the right plan than watch you fight the arithmetic.
Related reading: Seedbox Storage Quota on our wiki covers the quota meter and bonus disk policy.
