It is also possible to add an option of maximum disk size per folder. Like the option minimum free disk space.
1 Like
Many things are possible. 
What’s the use case?
1 Like
To give other family members (children) a reserved space to use my computer as a backup. And to prevent them from filling up my entire computer. So that I keep a little control over my disk space 
Workaround could be some additional partition or container for those folders, but having an option in syncthing would make it easier.
I would like to see the web GUI and Android app support the ability to set a size limit on a folder in kb/mb/gb and if the folder exceeds this, it will stop receiving data from other nodes.
1 Like
Hi, I’d like to revive this feature request.
Having a maximum size option for a folder helps to limit the space that a folder can take in the server.
Imagine having a Syncthing server that you share with friends and family, or for workers in a company, as a replacement for cloud storage such as Google Drive or Dropbox. Without a maximum folder size, one of those users could take up the entire storage space in the server, ruining the service for others.
With a maximum folder size option, one can effectively limit the space taken by users and distribute it in a planned manner.
The problem with this request is this: How should Syncthing determine which files to replicate (in the case where the source has more data than will fit at the target)? Not saying it’s an unsolvable problem, but it would need to be addressed in some manner.
One of the earlier posts mentioned using disk partitions or containers (e.g. Docker) which are probably simpler and more reliable compared to implementing a per-folder quota system in Syncthing…
In an enterprise/company deployment, it’s most likely running Windows Server, macOS, Linux and/or some other Un*x where the server-class OS has a built-in storage quota system.
I currently have this type of setup at work. A single Syncthing instance hosting multiple sync folders with each user assigned their own folder. Then the operating system (Linux) enforces disk quotas on each Syncthing folder.
In addition to what @billstewart already pointed out, another complication is the filesystem(s) being used.
On one of the file servers at my employer, the storage volume for user data has inline compression enabled. Without compression, the actual disk usage would be about 82% higher than it currently is. Syncthing sees a file’s reported size and not the actual size on disk after it’s been compressed, so there’s a risk of “overprovisioning” when deciding what the storage caps will be if multiple Syncthing folders are on the same storage volume.
Another wrinkle is filesystem cluster size. For example, a 10 TB disk formatted with an exFAT volume (commonly used by most manufacturers of USB connected drives) will use a 4MB cluster size, which isn’t necessarily good or bad. If a user syncs a bunch of typical size MP3 music files, it’s all good because many tracks will clock in at around 3-4 MB, making efficient use of the 4MB cluster size. However, if a user syncs an Obsidian or Joplin notebook containing mostly text files, the actual disk usage could easily be 10x the reported file sizes due to waste from “slack space”.
1 Like
Syncthing already has a Minimum Free Disk Space option, so I guess I would use the same mechanism that’s already implementing that limit.
That uses OS reported “free space” on the device (not path, device) the specific path is on. It’s nothing todo with quotas, which is what this describes.
It doesn’t matter, it is a mechanism that may accept or reject files according to the free space reported by the OS (tell me if I’m wrong, that’s what I understand).
So I propose to do the same with the following acceptance criteria for files:
current folder size + new file size <= max folder size
Creating and managing a partitions for all users sounds like a lot of work and also involves meddling with the filesystem. Breaking the drive into partitions is not a light thing to do. If you need to keep making partitions, it’s not desirable.
Also not everyone can or should run syncthing as Docker container. I personally run it in a shared hosting environment without docker support.
Also not everyone is in a company setting and many users use Windows.
So, yes, one could do it via the OS but there is much to gain from an option. It’s an easy way to limit the space taken by a folder. You don’t have to meddle with the file system, you can change the setting, anyone can use this feature regardless of OS or technical knowledge.
From a product perspective, since there is already a control on Minimum Free Disk Space it is not a stretch to add a Maximum Folder Space option right next to it.
I understand this but it sounds like splitting hairs. Maybe you say 10 GB limit and you end up using… what… 10.25 GB? of actual physical space. But the point of this feature is to limit people from using your entire drive when you want to give each user 10 GB.
Just last week I ran into this very problem…
A 12 TB USB drive, factory-formatted with a single exFAT volume. Per Microsoft’s specifications, the default cluster size for a volume that size is 4MB.
The file transfer was for a bunch of small files ranging from less than 200 bytes to a couple of megabytes, with more than 2/3 of the files being less than 256KB.
Since the drive was brand new, I went to check on the file transfer after a few minutes and was surprised to see that 114GB had already been used. When I ran a disk usage scan, only 13GB worth of files had actually been copied over (I’d assumed that the cluster size was much smaller).
Another example, this time involving Syncthing…
One of my Syncthing folders currently contains 16,263 files consisting mostly of text documents totaling 1.6GB (243 files are larger than 1MB; 15,579 are less than 256KB).
If I were to sync my notebook to another device with an exFAT filesystem (commonly used for USB HDDs, flash drives and SD cards) and a 4MB cluster size, it would consume a minimum of 65GB of disk space (16,263 files x 4MB).
So if the test condition is current folder size + new file size <= max folder size, what’s the “current folder size”?
Let’s assume I set max folder size to 10GB. From Syncthing’s perspective it’s the sum of the files within the folder, which is 1.6GB, so well under the quota. All good, right? However, in reality that 1.6GB folder just ate up 65GB of disk storage – so 10GB of files could require over 400GB of physical storage. 
A smaller cluster size…
One solution to the slack space issue is to lower the cluster size for the exFAT volume, but it impacts the number of files and the maximum size of the volume among other limitations.
For NTFS, the optimal default cluster size is 4KB – 1000x smaller than the 4MB default for exFAT – but then the tradeoff is that the maximum volume size is 16TB (with drive prices falling lower and lower, plus people holding onto more and more data, it’s no longer unusual for people to own what was once considered only in data centers).
I currently use a 4KB cluster size for my Syncthing folder, resulting in about 6.7% of capacity lost to slack space – i.e. 10GB of files would require 10.67GB of physical storage. For someone else it might be much worse depending on the number of files smaller than the cluster size.
1 Like
So how does Minimum Free Disk Space work?
Does Syncthing store the files, then it realizes it went over the minimum space (even though it shouldn’t have because of the logical file size) and deletes the files? As I see it, it is exactly the same problem.
The nuances of an archaic file system such as ExFAT should not mandate whether an option is implemented.
Having some quota is better than having no quota at all. Administrators should know that the quota is on logical file size and expect it to take slightly (or not so slightly) more space in the physical storage.
I think this all boils down to complexity. The usage of a single disk/volume is pretty clear. Given the (very) dynamic nature of mounts on e.g. BSD and Linux, things get ambiguous for folders.
Let’s say we’d define a limit for /mnt/data:
music # 40 GB
videos # 100 GB, mounted from /dev/sda1
documents # 10 GB
What is the size of the folder? Depending on your definition, the answer is either 50GB or 150 GB.