Dateisystem Quotas einrichten: Speicherplatz pro Benutzer und Gruppe begrenzen

1. Warum Quotas auf Multi-User-Servern unverzichtbar sind

Dateisystem Quotas begrenzen, wie viel Speicherplatz und wie viele Dateien ein einzelner Benutzer oder eine Gruppe auf einem Dateisystem belegen darf. Ohne diese Begrenzung reicht ein einzelner Dienst mit einem fehlerhaften Log-Rotation, ein Benutzer mit einem versehentlich rekursiv laufenden Backup-Skript oder ein kompromittierter Account, um eine komplette Partition zu füllen und damit den gesamten Server in Mitleidenschaft zu ziehen, selbst Dienste, die mit dem eigentlichen Verursacher nichts zu tun haben.

Auf Shared-Hosting-Umgebungen mit mehreren Kunden auf demselben Server sind Quotas praktisch Pflicht, aber auch auf internen Servern mit mehreren technischen Benutzern, etwa getrennten Accounts für verschiedene Anwendungen oder Entwickler, verhindern Dateisystem-Quotas, dass ein einzelner fehlerhafter Prozess den gesamten verfügbaren Speicherplatz belegt und damit auch unbeteiligte Dienste zum Absturz bringt, weil das Root-Dateisystem plötzlich voll ist.

In der Praxis zeigt sich der Wert von Quotas besonders bei automatisierten Prozessen: ein CI-Runner, der Build-Artefakte in einem gemeinsam genutzten Verzeichnis ablegt, oder ein Cronjob, der bei einem Fehler in einer Endlosschleife Logdateien schreibt, sind klassische Auslöser für vollgelaufene Partitionen. Dateisystem Quotas fangen genau solche Fälle ab, bevor sie zum produktionsweiten Vorfall werden.

2. Soft-Limit, Hard-Limit und Grace Period verstehen

Linux-Quotas unterscheiden zwei Arten von Limits, jeweils sowohl für Speicherplatz (Blocks) als auch für Dateianzahl (Inodes). Das Soft-Limit kann vorübergehend überschritten werden, löst aber ab dem Überschreiten eine Warnung und den Start der sogenannten Grace Period aus, einer festgelegten Zeitspanne, innerhalb derer der Benutzer wieder unter das Soft-Limit kommen muss. Das Hard-Limit ist absolut, sobald es erreicht ist, schlagen weitere Schreibversuche mit EDQUOT (Disk quota exceeded) fehl, unabhängig von der Grace Period.

Diese zweistufige Struktur erlaubt kurzfristige Spitzen, etwa während eines Deployments oder eines temporären Exports, ohne sofort blockiert zu werden, verhindert aber dauerhaftes Überschreiten. Wird die Grace Period nicht eingehalten, wirkt das Soft-Limit anschließend wie ein Hard-Limit, bis die Nutzung wieder darunter fällt. Für die meisten Anwendungsfälle ist eine Grace Period zwischen sieben und vierzehn Tagen ein sinnvoller Kompromiss zwischen Flexibilität und Kontrolle.

Ein oft übersehener Aspekt: Sowohl Soft- als auch Hard-Limit gelten pro Dateisystem, nicht global über den gesamten Server. Ein Benutzer mit Zugriff auf mehrere gemountete Partitionen benötigt daher für jede einzelne Partition eigene Quota-Einträge, es gibt keine serverweite Summierung über mehrere Mount-Points hinweg.

3. Quota-Unterstützung im Dateisystem aktivieren

Bevor Quotas gesetzt werden können, muss das Dateisystem selbst Quota-Buchführung aktivieren. Bei ext4 geschieht das über die Mount-Optionen usrquota und grpquota in /etc/fstab, getrennt für benutzerbezogene und gruppenbezogene Limits, beide lassen sich unabhängig voneinander aktivieren.

# /etc/fstab: enable user and group quota accounting on ext4
UUID=2a9e7c31-5b4d-4e8a-9f21-6c3d0e7a1b55  /home  ext4  defaults,usrquota,grpquota  0  2

# Remount without a reboot to apply the new mount options
sudo mount -o remount /home

Ein Remount reicht in der Regel aus, um die neuen Mount-Optionen ohne Neustart zu übernehmen, auf dem Root-Dateisystem selbst kann jedoch ein Neustart notwendig sein, weil das Root-Dateisystem beim Booten in einem sehr frühen Stadium eingehängt wird. Wichtig: Die Mount-Optionen allein aktivieren nur die technische Voraussetzung, die eigentliche Quota-Datenbank muss danach separat initialisiert werden.

Ein Blick in /proc/mounts nach dem Remount bestätigt, ob die Quota-Optionen tatsächlich aktiv übernommen wurden, gerade bei Netzwerk-Dateisystemen oder ungewöhnlichen Mount-Reihenfolgen lohnt sich diese Kontrolle, bevor man sich auf funktionierende Quotas verlässt.

4. Quota-Datenbank initialisieren und einschalten

Nach der Aktivierung der Mount-Optionen muss quotacheck einmalig das gesamte Dateisystem durchsuchen, jedem Benutzer und jeder Gruppe die tatsächlich belegten Blocks und Inodes zuordnen und daraus die internen Quota-Dateien aquota.user und aquota.group im Wurzelverzeichnis des Mount-Points erzeugen.

# Scan the filesystem and create the quota accounting files
sudo quotacheck -cug /home

# Turn quota enforcement on for the mount point
sudo quotaon /home

# Verify that accounting is active
sudo quotaon -p /home

quotacheck sollte idealerweise auf einem möglichst wenig genutzten Dateisystem laufen, weil parallele Schreibzugriffe während des Scans zu leicht inkonsistenten Anfangswerten führen können, die sich aber beim nächsten regulären Durchlauf von selbst korrigieren. Nach erfolgreichem quotaon ist die Buchführung aktiv, ohne dass bereits irgendwelche Limits gesetzt wären, an dieser Stelle wird nur noch mitgezählt, aber noch nichts begrenzt.

Nach einem größeren Dateisystem-Wachstum oder nach dem Wiederherstellen aus einem Backup empfiehlt sich ein erneuter quotacheck-Lauf, weil sich die tatsächliche Belegung in der Zwischenzeit signifikant verändert haben kann und die intern gespeicherten Werte sonst von der Realität abweichen.

5. Limits pro Benutzer und Gruppe setzen

Die eigentlichen Limits werden mit setquota gesetzt, das für jeden Benutzer oder jede Gruppe vier Werte erwartet: Soft-Limit und Hard-Limit für Blocks (in Kilobyte), sowie Soft-Limit und Hard-Limit für Inodes. Wiederkehrende Limits, etwa für alle Entwickler-Accounts eines Teams, lassen sich effizient über edquota -p von einem bereits konfigurierten Referenz-Benutzer auf mehrere andere Accounts übertragen.

# Set soft/hard limits for blocks and inodes for a single user
# setquota <user> <block-soft> <block-hard> <inode-soft> <inode-hard> <mountpoint>
sudo setquota -u deploy 5000000 5500000 200000 220000 /home

# Set the same limits for an entire group at once
sudo setquota -g www-data 20000000 22000000 500000 550000 /home

# Copy quota settings from one user to a list of others
sudo edquota -p deploy -u www-user2 www-user3

Ein häufiger Fehler bei der Erstkonfiguration: Das Inode-Limit wird vergessen und nur das Block-Limit gesetzt. Ein Benutzer, der viele sehr kleine Dateien anlegt, etwa Millionen winziger Cache- oder Session-Dateien, kann dabei ein Dateisystem an sein Inode-Limit bringen, lange bevor der eigentliche Speicherplatz (Blocks) ausgeschöpft ist. Beide Limit-Typen gehören daher immer gemeinsam gepflegt.

Für Hosting-Umgebungen mit vielen ähnlichen Accounts lohnt sich ein einfaches Wrapper-Skript um setquota, das Limits zentral aus einer Konfigurationsdatei liest, statt sie für jeden Benutzer einzeln manuell einzutippen, das reduziert Tippfehler und macht Änderungen an Standard-Limits für alle Accounts gleichzeitig nachvollziehbar.

6. Nutzung überwachen und Reports auswerten

Für einen einzelnen Benutzer zeigt quota -u die aktuelle Nutzung im Vergleich zu den gesetzten Limits, praktisch für den Benutzer selbst oder für gezielte Support-Anfragen. Für den Überblick über alle Benutzer mit aktiven Quota-Einträgen auf einem Mount-Point liefert repquota eine vollständige, sortierbare Tabelle.

# Check a single user's current usage against their limits
sudo quota -u deploy

# Report every user with active quota entries on a mount point
sudo repquota -a

# Human-readable, sorted by usage
sudo repquota -as | sort -k3 -h -r | head -20

In der Praxis lohnt sich ein regelmäßiger, automatisierter repquota -a-Lauf per Cronjob, dessen Ausgabe auf Benutzer nahe am Soft-Limit gefiltert und per E-Mail an das Betriebsteam verschickt wird. So lassen sich Engpässe erkennen, bevor ein Benutzer tatsächlich in die Grace Period oder gegen das Hard-Limit läuft und produktive Prozesse dadurch fehlschlagen.

Ergänzend zu repquota liefert quota -uqv für den aufrufenden Benutzer selbst eine kompakte Ausgabe, nur wenn tatsächlich ein Limit gesetzt ist, das nutzt sich hervorragend in Login-Skripten, ohne bei Benutzern ohne gesetzte Limits unnötige Ausgaben zu erzeugen.

7. Grace Period konfigurieren und Benutzer warnen

Die Grace Period wird mit setquota -t global pro Dateisystem konfiguriert, getrennt für Block- und Inode-Limits, angegeben in Sekunden. Sie definiert, wie lange ein Benutzer oberhalb des Soft-Limits, aber unterhalb des Hard-Limits agieren darf, bevor das System das Soft-Limit wie ein Hard-Limit behandelt.

# /etc/quotatab or via setquota: default grace period once soft limit is hit
sudo setquota -t 604800 604800 /home   # 7 days for blocks and inodes

# Check remaining grace period for a specific user
sudo repquota -a | grep deploy
# Output columns include days left until the hard limit becomes enforced

Wichtig für die Praxis: Standardmäßig erhalten Benutzer keine automatische Warnung außerhalb einer interaktiven Shell-Sitzung, in der ein Login-Skript quota aufruft. Für Server ohne interaktive Logins, etwa reine Anwendungsserver, sollte die Überwachung daher zwingend über automatisierte repquota-Reports laufen, sonst bemerkt niemand, dass die Grace Period bereits läuft, bis das Hard-Limit greift und Schreibzugriffe plötzlich fehlschlagen.

Wird keine explizite Grace Period gesetzt, greift ein systemweiter Standardwert, der bei den meisten Distributionen bei sieben Tagen liegt, für produktive Umgebungen mit unterschiedlichen Anwendungsfällen lohnt sich aber fast immer eine bewusste, dokumentierte Entscheidung statt sich auf den Standardwert zu verlassen.

8. Quotas unter XFS: project quotas als Alternative

XFS implementiert Quotas grundlegend anders als ext4, die Konfiguration erfolgt nicht über usrquota/grpquota in fstab, sondern über die Mount-Option uquota/gquota beziehungsweise pquota für Project Quotas, und die Verwaltung läuft über das eigenständige Kommando xfs_quota statt über setquota und repquota.

Project Quotas sind eine XFS-Besonderheit ohne direktes ext4-Äquivalent: Statt Limits an einen Benutzer oder eine Gruppe zu binden, wird ein beliebiges Verzeichnis einem Projekt zugeordnet, unabhängig davon, welcher Benutzer die Dateien darin anlegt. Das eignet sich hervorragend für Hosting-Szenarien, in denen ein Kundenverzeichnis begrenzt werden soll, unabhängig davon, unter welchem Systembenutzer ein PHP-FPM-Pool oder ein Cronjob innerhalb dieses Verzeichnisses schreibt.

Der Befehl xfs_quota -x -c 'report -h' liefert dabei eine dem repquota sehr ähnliche, menschenlesbare Übersicht, sodass sich die Umstellung von ext4 auf XFS aus Sicht der täglichen Quota-Administration in der Praxis meist auf die Umgewöhnung an ein neues Kommando beschränkt, nicht auf ein grundlegend anderes Konzept.

9. Quota-Ansätze im direkten Vergleich

Je nach Dateisystem und Anwendungsfall passt ein anderer Quota-Mechanismus besser. Die folgende Übersicht ordnet die wichtigsten Optionen ein.

Für klassische Multi-User-Server mit ext4 sind usrquota und grpquota der direkte, gut dokumentierte Weg. Für Hosting-Umgebungen mit XFS und pro Kunde getrennten Verzeichnissen sind Project Quotas oft die sauberere Lösung, weil sie nicht an einzelne Systembenutzer gebunden sind.

10. Zusammenfassung

Dateisystem Quotas verhindern, dass ein einzelner Benutzer, eine Gruppe oder ein fehlerhafter Prozess ein gesamtes Dateisystem füllt und dabei unbeteiligte Dienste in Mitleidenschaft zieht. Soft-Limits mit Grace Period erlauben kurzfristige Spitzen, Hard-Limits setzen eine absolute Obergrenze.

Die Einrichtung läuft in drei Schritten: Mount-Optionen aktivieren, mit quotacheck initialisieren und mit setquota Limits vergeben, immer für Blocks und Inodes gemeinsam. Regelmäßiges Reporting per repquota macht aus einer einmaligen Konfiguration ein dauerhaft überwachtes System.

11. FAQ: Dateisystem Quotas einrichten