Currently running ISPConfig 22.214.171.124 on a public server, and 126.96.36.199 on an another one for testing, both on Debian, with one large main partition on install. While the testing one is overall working, it wasn't strictly setup following say for example www.howtoforge.com/perfect-server-debian-squeeze-with-bind-and-dovecot-ispconfig-3. What we have in mind is to offer a simple webstorage so that users can access their files remotely. For a small fee, we provide them FTP creditentials, as well as an account for a web file manager. Each have a limited disk space, and this is where we are wondering what would be the recommended settings. Through the ISPConfig interface, it is possible to set quotas for websites. Now, there is not going to be a website per user, obviously, so we created folders outside the default /var/www/clients/clientX/webX path for their files. We know that ISPConfig is primarly focused on traditional hosting so to speak, but does it support setting quotas outside the default path? Maybe it is not the case with the GUI, but it most probably would be possible from the shell. On our potentially flawed 188.8.131.52 install testing machine, we attempted with the setquota -u user ... command, we also tried with quotatool -u user -b -q 100MB -n -v -d filesystem (just a test on /home/foldername ) which resulted in quotatool: Error while detecting kernel quota version: No such process While we haven't followed www.howtoforge.com/perfect-server-debian-squeeze-with-bind-and-dovecot-ispconfig-3 100% for the testing machine, we don't think it should create problems to create quotas. What files should we edit via command line? We know it goes a little outside the purpose of ISPConfig to edit manually, but until things are all set, we are still deciding what way we will go. We haven't really check if subdomains would be OK for that. Now the reasoning behind it is that we have a SSL certificate from a CA, and while we can cover subdomains, for the time being it is only valid for the "main" domain, so we could not have https://sub.domain.tld for users to connect without exposing their logins, unless of course there would be way around that we haven't considered. And we doubt that for say a hundred users, we would make 100 partitions, unless this is current practice? We may have left out some needed information for members of the forum to give some helpful hints, if this is the case let us know, we will be happy to provide more details.