Превышена дисковая квота linux как исправить

Опубликовано: 30.07.2019

Пошагово разберем процесс установки ограничений на использование дискового пространства в системах Linux. Какой дистрибутив — не важно. Процесс немного различается для файловых систем XFS и EXT4/остальных — мы разберем оба варианта.

Установка пакета quota

Установка пакета для управления квотами выполняется из репозитория.

а) для систем на базе RPM (Red Hat, CentOS):

yum install quota

б) для систем на базе deb (Debian, Ubuntu):

apt-get install quota

Настройка раздела

Для возможности управлять квотами для определенного раздела необходимо его смонтировать с соответствующими опциями. Для файловых систем XFS и не XFS (например, ext) эти опции различаются:

1. Для XFS — uquota (для пользователей) и/или gquota (для групп).
2. Для ext и других — usrquota (для пользователей)и/или grpquota (для групп).

И так, чтобы добавить нужные опции для включения квотирования, откроем файл fstab:

vi /etc/fstab

Находим настройку для монтирования раздела, на который необходимо установить квоту и добавим нужные опции:

/dev/sda     /     ext4     defaults,usrquota,grpquota     0 0
/dev/sdb     /var     xfs     defaults,uquota,gquota     0 0

* в данном примере мы добавили опции usrquota и grpquota для устройства /dev/sda, примонтированного в качестве корневого раздела / с файловой системой ext. А также опции uquota и gquota для устройства /dev/sdb (монтируется в /var с файловой системой xfs). Если необходимо включить квоту только для пользователей или групп, оставляем соответствующие опции.
* существуют и другие опции, например, jqfmt нужна для указания формата квоты при использовании журналирования. Подробнее описано в таблице Опции системы квот в файле /etc/fstab сайта IBM.

Перемонтируем наши разделы:

mount -o remount /

mount -o remount /var

Проверим, что нужные нам разделы теперь смонтированы с опциями квотирования:

mount | grep quota

Мы увидим, примерно, следующее:

/dev/sda on / type ext4 (rw,relatime,quota,usrquota,grpquota,data=ordered)
/dev/sdb on /var type xfs (rw,relatime,attr2,inode64,usrquota,grpquota)

Квоты включены для разделов.

Корневая директория (/) + XFS

При попытке включить квоту для корневой директории XFS с помощью файла fstab, результат будет нулевым — в опциях монтирования мы будем наблюдать noquota, например:

/dev/sda on / type xfs (rw,relatime,attr2,inode64,noquota)

Для включения опции квотирования необходимо отредактировать загрузчик. Для этого открываем файл:

vi /etc/default/grub

Находим строку GRUB_CMDLINE_LINUX и дописываем в нее rootflags=uquota,gquota — в моем случае получилось так:

…
GRUB_CMDLINE_LINUX=»crashkernel=auto rd.lvm.lv=vg/root rd.lvm.lv=vg/swap rhgb quiet floppy.allowed_drive_mask=0 rootflags=uquota,gquota«
…

На всякий случай, сохраним конфигурационный файл загрузчика:

cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.backup

… и применим настройки grub:

grub2-mkconfig -o /boot/grub2/grub.cfg

Перезагружаем компьютер:

shutdown -r now

После перезагрузки мы должны наблюдать такую картину:

mount | grep quota

/dev/mapper/vg-root on / type xfs (rw,relatime,attr2,inode64,usrquota,grpquota)

Квоты включены для корневого раздела с файловой системой XFS.

Включение квот

И так, мы разрешили квоты для разделов. Теперь включаем квоты. Процессы для XFS и остальных файловых систем немного различаются. Мы рассмотрим оба варианта. Так как в нашем примере есть разделы для XFS и Ext, то мы выполним все варианты настроек.

XFS

После монтирования раздела с файловой системой XFS автоматически включается квотирование (если была задана соответствующая опция). Проверить состояние можно, войдя в режим экспертного управления квотами:

xfs_quota -x

… и выполнив команду для получения статуса:

> state

Ext и другие

Выполним проверку наличия служебных файлов aquota.user и aquota.group — если их нет, команда их создаст автоматически:

quotacheck -favugm

… при наличии разделов с включенной квотой на XFS мы можем увидеть:

quotacheck: Skipping /dev/sdb [/var]

* это нам говорит о том, что команда quotacheck пропускаем раздел с xfs.

Включаем квоту для разделов:

quotaon -avug

Установка квот

Пришло время задать квоты. Они устанавливаются с помощью команды edquota.

Квоты пользователей

Для пользователя, вводим команду:

edquota -u dmosk

* где dmosk — имя пользователя, для которого будет задана квота.

В открывшемся редакторе можно задать ограничение на использование разделов, для которых включена квота:

Disk quotas for user dmosk (uid 1001):
  Filesystem    blocks    soft    hard    inodes    soft    hard
  /dev/sda          20       0     10M         8       0       0
  /dev/sdb           0       0     20M         0       0       0

* где:

• Filesystem — дисковое устройство, для которого устанавливается квота.
• blocks — текущее количество используемых пользователем блоков.
• первый soft — мягкая квота на объем данных (при ее превышении отправляется уведомление по почте, а после периода отсрочки, который по умолчанию составляет 7 дней, мягкая квота становится жесткой).
• первый hard — жесткая квота на объем данных (при ее превышении дальнейшая запись будет запрещена).
• inodes — текущее количество файлов, используемых пользователем.
• второй soft — мягкая квота на количество файлов (при ее превышении отправляется уведомление по почте).
• второй hard — жесткая квота на количество файлов (при ее превышении дальнейшая запись будет запрещена).

* в данном примере мы задали жесткую квоту для пользователя dmosk в 10 Мб на /dev/sda (корневой раздел) и 20 Мб на /dev/sdb (/var).

Квоты для групп

Для группы, задаем квоту так:

edquota -g mail

Как и в случае с пользователем, откроется редактор, с помощью которого можно задать квоту:

Disk quotas for group mail (gid 12):
  Filesystem    blocks    soft    hard    inodes    soft    hard
  /dev/sda           0       0     30M         6       0       0
  /dev/sdb           0       0     40M         0       0       0

* в данном примере мы зададим квоту для группы в 30 Мб на /dev/sda (корневой раздел) и 40 Мб на /dev/sdb (/var).

Копирование квот

Мы также можем копировать квоты для пользователей. Для этого используется та же команда edquota с ключом -p:

edquota -p dmosk ivanov

* в данном примере мы скопируем настройку квотирования, которая применяется к dmosk на другого пользователя ivanov.

Настройка периода отсрочки

Как было упомянуто выше, мягкие ссылки являются мягкими только в течение периода отсрочки. Данный период по умолчанию равен 7 дням. Его можно задать командой edquota с ключом -t:

edquota -t

В открывшемся окне задаем новые значения:

Grace period before enforcing soft limits for users:
Time units may be: days, hours, minutes, or seconds
  Filesystem             Block grace period     Inode grace period
  /dev/mapper/vg-root                  8days                  9days
  /dev/sdb                      8days                  9days

* в данном примере мы задали 8 дней для квот на дисковое пространство и 9 дней — на количество файлов.

Просмотр и проверка квот

Ограничения настроены. Проверим…

Отчет по квотам

Чтобы посмотреть отчет об используемом пространстве и установленных квотах, вводим команду:

repquota -us /

* для отчета корневого раздела только по пользовательским (u) квотам в режиме удобного чтения (s).

… и:

repquota -g /var

* для отчета по разделу /var для групп.

Мы увидим что-то на подобие:

*** Report for user quotas on device /dev/sda
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
———————————————————————-
root      —   2862M      0K      0K           115k     0     0       
polkitd   —      0K      0K      0K              2     0     0       
tss       —      8K      0K      0K              2     0     0       
postfix   —      4K      0K      0K             38     0     0       
chrony    —      4K      0K      0K              3     0     0       
dmosk     —     20K      0K  10240K              8     0     0       
rpc       —      0K      0K      0K              2     0     0       
ntp       —      4K      0K      0K              3     0     0       
…

* как видим, это отчет по использованию раздела /. Мы видим, каким пользователем сколько занято дискового пространства и видим, что для нашего пользователя dmosk установлена квота в 10 Мб (10240 Кб).

Проверка

И так, мы настроили для пользователя dmosk ограничение на использование дискового пространства. Попробуем превысить данный лимит. Заходим в консоль под нужным пользователем:

su — dmosk

… и вводим:

dd if=/dev/zero of=/tmp/tmp_dmosk_file bs=1024000 count=100

* команда должна создать файл на 100 Мб в каталоге tmp.

Однако, система вернет сообщение:

dd: ошибка записи «/tmp/tmp_dmosk_file»: Превышена дисковая квота
11+0 записей получено
10+0 записей отправлено
 скопировано 10240000 байт (10 MB), 0,223768 c, 45,8 MB/c

Квота работает.

Другие квоты

Иногда, необходимо установить квоту в рамках определенной программы или каталога.

Однако, квоты так не работают и нет возможности задать их для определенного каталога или программы. Но это не означает, что выхода нет.

Квота на директорию

Чаще всего, нет необходимости задавать квоту на всю систему — нужно только ограничение размера директории. В данной ситуации нам нужно примонтировать диск к нужной директории и задать квоту на примонтированный раздел.

Квоты в samba

Как правило, речь в контексте samba идет о ограничения на использование шары. Для этого необходимо каждую шару поместить на отдельный раздел, каждый со своей квотой.

Также в файловом сервере samba есть возможность настройки квотирования на уровне программного обеспечения. В конфигурационном файле при настройке шары добавим:

[share]
  …
  vfs objects = default_quota
  default_quota:uid = 1022
  default_quota:uid nolimit = no
  …

* в данном примере мы задаем квоту на каталог share. Данная квота должна быть такой же, как у системного пользователя с uid 1022. Таким образом, системные квоты должны быть настроены.

Для samba есть также параметр max disk size, который не является ограничением, а просто показывает для других программ максимальный объем доступного пространства.

Квоты в vsftpd

Настраивая vsftpd, мы также должны позаботиться о том, чтобы каталоги с FTP были на разделах с установленными квотами. Другими словами — вопрос также решается с применением пакета quota.

Disk Quota Exceeded is a common error in Linux web hosting servers. Website owners see this error when they try to upload a file, send a mail or update a database.

Every month, our engineers resolve hundreds of “Disk Quota Exceeded” errors in our role as website support for web hosting companies. We’ve seen these 2 causes for the error:

1. Users exceeding their mail or web space quota
2. Corrupted disk quota table
3. File limit (inode) exhaustion

Today, we’ll take a look at how to troubleshoot, fix and prevent quota exceeded errors.

Fixing mail/web space overage

About 80% of disk quota exceeded errors occur due to users uploading files beyond their subscription limit.

In many cases, we’ve found large files (such as backup, videos, DB dumps, etc.) in the user’s home directory itself. But there are other locations that are not so obvious:

1. Trash or Spam mail folders
2. Catch-all mail accounts
3. Web app log files (eg. WordPress error log)
4. Old log files (eg. access_log.bak)
5. Old uncompressed backups (from a previous site restore for eg.)
6. Un-used web applications

It’s not easy to find these space files if you look at a web panel report. That is why we use Linux command line tools (such as du) to list all directories in a user’s account, and sort them as per size.

Once we’ve found the top directories, we drill down until we locate all non-essential files.

[ Never let disk quota errors affect your website functioning. Get our professional help to fix your website errors at affordable pricing. ]

Special case – User’s files located outside home directory

In self-managed VPS servers, we’ve found user files stored outside the user’s home directory. This could be from past troubleshooting steps, incomplete site restore, etc.

We’ve found such files in /usr, /var, / or in some cases even in /root directory.

We resolve this issue by searching the whole file system with the username, deleting them, and then updating the quota table.

Pro Tip : All this detective work takes time. Business mails coming in during this period will bounce. So, if you’re a shared web host, increase the quota by 100 MB temporarily so that services to the user is immediately restored.

Fixing cPanel disk quota cache error

In cPanel servers, even after a disk quota exceeded error is resolved, the web panel shows the old disk space info. That is, even if a 1 GB file is deleted, the space usage doesn’t show any difference.

It is caused by a cPanel feature called “disk quota cache”. cPanel stores disk usage info for 15-30 mins, to reduce disk access, and thereby keep down server load.

To fix this, our tech support team uses two approaches:

1. In powerful servers, we disable this cache (choose off), as server load isn’t affected.
2. In heavily loaded or less powerful servers, we educate the users via custom tool tips in the panel that the correct value will be reflected in 15 mins.

How to prevent space overage

Disk space overage results in customers losing their business mails, or websites being down. We’ve been able to reduce the incidence of such downtime in web hosting companies by sending “Disk Quota Warning” emails with specific steps on what to check, and how to delete excess files.

How to fix incorrect quota table

Linux servers store quota information in files such as aquota.user, aquota.group, .quota.user, etc.

In some situations, such as a server crash or hard disk errors, these files could get corrupted, leading to many users getting quota related errors.

When we see a sudden surge in mail or web quota errors for many users at once, we immediately check the quota table. In general, we follow these steps:

1. Disable quota for the affected partition (usually /home in web hosting servers)
2. Stop services such as mail, web and FTP that can write new files
3. Recreate the quota table using the “quotacheck” command (or fixquota in cPanel servers)
4. Re-enable quota for the affected partition

Pro Tip : A damaged quota table indicates a more serious underlying problem such as a failing hard disk. When such situations, we scan the server for health or security issues. In many cases, we’ve prevented major downtimes by finding and correcting serious server errors.

[ Are you stuck due to no disk space? Get assistance from our server experts to fix your website issues permanently. ]

Resolving file limit (inode) exhaustion

Our engineers provide tech support for several VPS hosting providers. In these companies, the majority of disk quota exceeded errors caused by VPSs hitting file number limit.

Linux servers use something called inodes to keep track of each file. The trouble is, each server (or VPS) has only a limited number of inodes. So, when all inodes are used up by a malicious activity (eg. a spam attack), new files cannot be created.

Here are a few common causes for iNode exhaustion:

1. Thousands of un-delivered spam mails filling up the mail queue.
2. Several versions of un-compressed backups
3. Catch-all mail boxes that accumulated years worth of mails
4. Old cache files of some programs such as “eAccelerator”
5. PHP session files that are not automatically deleted

Since VPS users have administrator (root) access, these files could be anywhere. So, we use a top-down scan to find out which folders have the max number of files.

For eg. If /home partition is 100% full, we’d start the scan at /home – like this:

Then the scan is repeated on the top directory, and the process repeated until we find and delete the junk files.

Pro Tip : At 100% inode usage, all services would be virtually stuck. So, as soon as you login, move a few non-critical folders (like old log files) to another partition to immediately restore services. This will prevent mails bouncing, site errors, etc.

Are you having recurrent issues in your hosting servers? Looking for an expert intervention to stabilize your servers? Click here to know how we can help you make things better.

var google_conversion_label = «Blp0CLCojHIQ0aD71QM»;

Disk Quota Exceeded is a common error in Linux web hosting servers. Website owners see this error when they try to upload a file, send a mail or update a database.

These are causes for the error:

1. Users exceeding their mail or web space quota
2. Corrupted disk quota table
3. File limit (inode) exhaustion

Fixing mail/web space overage

About 80% of disk quota exceeded errors occur due to users uploading files beyond their subscription limit.

In many cases, we’ve found large files (such as backup, videos, DB dumps, etc.) in the user’s home directory itself. But there are other locations that are not so obvious:

1. Trash or Spam mail folders
2. Catch-all mail accounts
3. Web app log files (eg. WordPress error log)
4. Old log files (eg. access_log.bak)
5. Old uncompressed backups (from a previous site restore for eg.)
6. Un-used web applications

Fixing cPanel disk quota cache error

In cPanel servers, even after a disk quota exceeded error is resolved, the web panel shows the old disk space info. That is, even if a 1 GB file is deleted, the space usage doesn’t show any difference.

It is caused by a cPanel feature called “disk quota cache”. cPanel stores disk usage info for 15-30 mins, to reduce disk access, and thereby keep down server load.

Uses these approaches:

1. In powerful servers, we disable this cache (choose off), as server load isn’t affected.
2. In heavily loaded or less powerful servers, we educate the users via custom tooltips in the panel that the correct value will be reflected in 15 mins.

How to prevent space overage

Disk space overage results in customers losing their business emails, or websites being down. We’ve been able to reduce the incidence of such downtime in web hosting companies by sending “Disk Quota Warning” emails with specific steps on what to check, and how to delete excess files.

Fixing incorrect quota table

Linux servers store quota information in files such as aquota.user, aquota.group, .quota.user, etc.

In some situations, such as a server crash or hard disk errors, these files could get corrupted, leading to many users getting quota related errors.

When we see a sudden surge in mail or web quota errors for many users at once, we immediately check the quota table. In general, we follow these steps:

1. Disable quota for the affected partition (usually /home in web hosting servers)
2. Stop services such as mail, web, and FTP that can write new files
3. Recreate the quota table using the “quotacheck” command (or fix quota in cPanel servers)
4. Re-enable quota for the affected partition

Resolving file limit (inode) exhaustion

Linux servers use something called inodes to keep track of each file. The trouble is, each server (or VPS) has only a limited number of inodes. So, when all inodes are used up by a malicious activity (eg. a spam attack), new files cannot be created.

Here are a few common causes for iNode exhaustion:

1. Thousands of un-delivered spam mails filling up the mail queue.
2. Several versions of un-compressed backups
3. Catch-all mailboxes that accumulated years worth of emails
4. Old cache files of some programs such as “eAccelerator”
5. PHP session files that are not automatically deleted

Never let disk quota errors affect your website functioning. For assistance, visit  hire our expert

У вас есть файловая система VZFS, что означает, что ваш VPS является виртуальной машиной Parallels Virtuozzo. В Virtuozzo хостинг-провайдер может устанавливать ограничения по многим параметрам, включая то, какие выделения вы получаете с VZFS.

Причина: из Inodes (наиболее распространенные)

После нескольких лет работы с сотнями клиентов Virtuozzo VPS, которые сталкивались с проблемой невозможности создания файлов, несмотря на то, что свободного места оказалось достаточно, подавляющее большинство из них достигло предела числа узлов. Выполните эту команду , чтобы увидеть распределение индексных дескрипторов Inodes дескрипторы используются IUsed остальные дескрипторы IFree и процент инодов используются IUse%

df -i

100% -ное использование inode происходит очень часто. Общие причины в моем опыте:

• Спам по электронной почте
• Исходящие спам-сообщения в очереди
• Сохранено много входящих писем
• Некоторые пользователи устанавливают свою сборку мусора в сеансе PHP (session.gc_maxlifetime) более чем на сто лет
• Слишком много общих файлов кэша
• Кэш объектов включен в плагине WordPress W3 Total Cache
• Журнал ошибок Magento (для каждой ошибки создается новый файл)
• Другие плохо настроенные или плохо разработанные программы / скрипты, которые создают кучу файлов и забывают удалить их

Поиск проблемы

Если вы обнаружите, что у вас мало или не хватает inode, но вы не знаете, где находится большинство из них, у меня есть одна строчка Bash, которая ищет текущий каталог и подсчитывает inode с глубиной папки 1:

for i in $(find $(pwd) -maxdepth 1 -type d | sort); do echo -e "$(find "$i" | wc -l)t: $(readlink -f "$i")"; done | sort -nr

Вы можете продолжать изменять текущий рабочий каталог, начиная с / пока не найдете виновника, использующего выделение вашего inode.

объяснение

Ваш VPS находится в файловой системе VZFS, которая является частью Parallels Virtuozzo (не OpenVZ, который похож и основан на той же технологии, но OpenVZ не будет использовать VZFS).

Благодаря тому, что Virtuozzo хранит файлы в VZFS, иноды часто ограничены в большей степени, чем в других файловых системах, таких как ext4 или XFS. Хост отслеживает все эти файлы, и хостинг-провайдеру было бы полезно не допустить, чтобы один VPS занимал сотни миллионов инодов. В результате хостинг-провайдер может установить низкий предел инодов, например, 1 000 000 инодов.

После многих лет работы с сотнями клиентов, которые исчерпали свое распределение inode в Virtuozzo, эти «таинственные» проблемы с дисковыми квотами меня больше не удивляют.

Причина: другие ограничения Virtuozzo

У очень небольшого процента клиентов Virtuozzo VPS, с которыми я работал, были проблемы с файловой системой, потому что они выходили за другие пределы. Вы можете увидеть некоторые (но не все) ограничения с помощью этой команды:

cat /proc/user_beancounters

Поиск проблемы

Если столбец failcnt имеет значения больше 0 или held значение столбца равно соответствующее limit значение, вы попали предел.

Вы можете посмотреть, что каждый параметр есть в вики OpenVZ здесь. Параметр может быть «первичным», «вторичным» или «вспомогательным».

Вы должны обратиться к вашему хостинг — провайдеру для получения дополнительной помощи , если вы обнаружите , что вы не можете уменьшить held количество для лимита , что ваш VPS достиг.

Этот ответ может быть значительно расширен в зависимости от того, какие бобы были превышены, так как разные пределы вызывают разные симптомы.

Причина: лимит (ы) уменьшился после удара

Что касается /proc/user_beancounters или df -i , иногда системный администратор Virtuozzo может уменьшить limit параметра ниже held значения.

Например, если исходное ограничение параметра diskinodes составляло 1 500 000, и вы достигли этого предела, то кто-то из вашего хостинг-провайдера установит ограничение вашего инода на 1 000 000, вы увидите странный отчет об инодах из df -i который не имеет смысла.

С вашей стороны вы можете увидеть неоправданно большое число, например, 18,446,744,069,620,218,961.

Я считаю, что это провокационное поведение со стороны хостинг-провайдера, особенно если они не сообщают вам, потому что необычные ценности, которые вы видите, противоречат знаниям суперпользователей, которые не имеют опыта работы с Virtuozzo/OpenVZ, что приводит к вводящим в заблуждение совет (пример, другой пример).

Поиск проблемы

Свяжитесь с вашим хостинг-провайдером. Покажите им, что вы нашли, и работайте с ними, чтобы ваши бобы были ниже предела.

Если они откажутся вам помочь, откажитесь от своего хостинг-провайдера и найдите другого, который не использует виртуализацию Virtuozzo/OpenVZ. На виртуализацию KVM, виртуализацию VMware, виртуализацию Xen или серверы с открытым исходным кодом будет распространяться гораздо меньше ограничений, чем в Virtuozzo/OpenVZ.

объяснение

Возможно, ваш хостинг-провайдер проводил аудит или отвечал на предупреждение и обнаружил, что ваш VPS использовал слишком много определенного ресурса (почти всегда ограничение inode, которое является параметром diskinodes на их конце).

Неопытный администратор Virtuozzo в хостинг-провайдере считает, что он может решить эту проблему, уменьшив ограничение до уровня, который ниже фактического использования ресурсов. В случае inode у вас может быть более низкое распределение, например, 1 000 000, даже если фактическое текущее использование может быть выше, например, 1 500 000.

Администратор Virtuozzo в своей панели управления будет видеть ваше фактическое использование и новый лимит, но вы увидите фальшивые числа, которые, возможно, очень неоправданно высоки из-за способа виртуализации Virtuozzo.

Нерадивый администратор Virtuozzo не сообщит вам об этом изменении, поэтому вам следует обратиться к вашему хостинг-провайдеру, если это произойдет с вами.