Quota issues with subdomains

So all I had to do was recreate the users, and now they are doing just fine logging into IMAP. Now, I get this error message when trying to set quota limits...

Failed to save mailbox : User's quota cannot be higher than the domain's quota of 1024 MB

The top level server has a quota of 250GB.

Status: 
Closed (fixed)

Comments

Well, now unfortunately, my quotas are all out of whack. It doesn't seem I can set quotas at all. When I try to set it on some other others in subdomains, it simply leaves the users with unlimited quotas.

Top-level users in the domain can be set with quotas just fine.

You may want to try going into Limits and Validation -> Check Disk Quotas, and having it run a check on all your user and group quotas.

Also, in the top-level quota, make sure that both the Total server quota and Server administrator's quota are set to a high enough value.

There's no such option under Limits and Validation. The top-level server and administrator quota are set to Unlimited.

Hmm, what options do you see under Limits and Validation?

Also, what is the output of the command "mount"?

Lastly, can you paste in the output you see if you run System Settings -> Re-Check Config?

Hmm, what options do you see under Limits and Validation?

Disk Quota Monitoring
FTP Directory Restrictions
Validate Virtual Servers - but there doesn't seem to be any mention there of quota validations

Also, what is the output of the command "mount"?

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=3992696k,nr_inodes=998174,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mapper/centos_red-root on / type xfs (rw,relatime,attr2,inode64,usrquota,grpquota)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=35,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
sunrpc on /proc/fs/nfsd type nfsd (rw,relatime)
/dev/sda2 on /boot type ext4 (rw,relatime,data=ordered)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
/dev/mapper/centos_red--backup-backup on /virtualmin-backup type xfs (rw,relatime,attr2,inode64,noquota)

Lastly, can you paste in the output you see if you run System Settings -> Re-Check Config?

The status of your system is being checked to ensure that all enabled features are available, that the mail server is properly configured, and that quotas are active ..
Your system has 7.63 GB of memory, which is at or above the Virtualmin recommended minimum of 256 MB.
BIND DNS server is installed, and the system is configured to use it.

Mail server Postfix is installed and configured.

Postfix is configured to support per-domain outgoing IP addresses.

Apache is installed.

The following PHP versions are available : 5.4.16 (/bin/php-cgi)

Webalizer is installed.

Apache is configured to host SSL websites.

MySQL is installed and running.

ProFTPd is installed.

Logrotate is installed.

SpamAssassin and Procmail are installed and configured for use.

ClamAV is installed and assumed to be running.

Plugin AWstats reporting is installed OK.

Plugin DAV Login is installed OK.

Plugin Mailman is installed OK.

Plugin Protected web directories is installed OK.

Plugin Additional content styles from OpenWebDesign.org is installed OK.

Plugin Additional content styles is installed OK.

Plugin Virtualmin Support Links is installed OK.

Using network interface eth1 for virtual IPs.

Default IPv4 address for virtual servers is 167.114.56.225.

Both user and group quotas are enabled for home and email directories.

All commands needed to create and restore backups are installed.

Resource limits are supported and configured correctly.

The selected package management and update systems are installed OK.

.. your system is ready for use by Virtualmin.

Pixel, I'd like to verify that quotas are working properly for you.

What is the output of this command:

cat /etc/default/grub

Quotas are a bit different on CentOS 7. While quotas should normally be configured at install time, if it got changed somehow, that could potentially cause that.

Also, what is the output of this command:

quota -v USERNAME

Where "USERNAME" is one of your Virtual Server owners.

Output of cat /etc/default/grub

GRUB_DISABLE_RECOVERY=true
GRUB_TIMEOUT=5
GRUB_DEFAULT=saved
GRUB_TERMINAL_OUTPUT=console
GRUB_DISABLE_SUBMENU=true
GRUB_CMDLINE_LINUX="vconsole.font=latarcyrheb-sun16 vconsole.keymap=us rd.lvm.lv=centos_red/root crashkernel=auto rhgb quiet rootflags=uquota,gquota"
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"

output of quota -v USERNAME

Disk quotas for user USERNAME (uid 509):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
/dev/mapper/centos_red-root
                 111204  26214400 26214400             486       0       0    

Appears that quotas are not working. Also note that is an EFI booted system.

Your quotas there actually look good.

They are showing as being active, and they are enabled both in the kernel parameters, and on the filesystem mount options.

I had been wondering if you were seeing a new issue regarding XFS quotas and the new kernel options necessary for those to work, but that doesn't appear to be the case.

So far I haven't been able to reproduce the issue you've described, but as more than one person has mentioned seeing it, and it's not always on the same distro, I'm going to do some more digging and see if I can determine how to reproduce what you're describing.

Just to verify, which Virtualmin version is it that you're using? You can determine that with this command:

rpm -qa | grep wbm-virtual-server

That would be wbm-virtual-server-4.15-2.noarch

Pixel, would it be possible for us to log into your system to review the issue that's going on?

I know some other folks are following this request, such as "inteq" who responded above, but what we'd need to do is mark your request here as private, and then go over some details about your system so that we can sort out what's going on.

Inteq (and anyone else following this issue), once we sort out what's going on we'll respond in a non-private post about what's needed to resolve this issue so that you and anyone else seeing that can get it working again.

That is fine. Let me know if I should open another request or something to keep things private. Also please let me know what the next step is. Thank you sir.

You know, I was initially going to make this request private and work on it here... but I think I like your other suggestion better. Since this request is being monitored by others, we can post the solution here in this request once it's working properly.

Could you open a new support request, and in that request, mark it as private. You can use the same title as this one, and in the message body, just include a link to here.

What we'd need in that new request is the best way to access your system as root, as well as an example of a domain and user who is experiencing this problem. We'd need to be able to login via both SSH, and via Virtualmin.

Thanks!

Jamie and I reviewed Pixel's server, and a some bugs were discovered that were causing the described problems. Those issues will be corrected in the next Virtualmin version.

Since a few folks have mentioned that they're experiencing this issue, I'm going to talk to Joe and Jamie about pushing out a new release sooner rather than later.

Okay, we've released a new Virtualmin version, correcting all those issues.

Let us know if you see any further problems!

Updated to 4.16 Pro and looking good! Thanks!!