KeyHelp Community

---------------------------------------------------------------------------


Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
(Probleme ohne KeyHelp-Bezug gehören ins Offtopic-Forum)
Ja

Server-Betriebssystem + Version
(z.B. Ubuntu 20.04)
Debian GNU/Linux 12

Eingesetzte Server-Virtualisierung-Technologie
(z.B. keine, OpenVZ, KVM, XEN, etc.)
Proxmox KVM

KeyHelp-Version + Build-Nummer
(z.B. 22.0 - Build 2366)
24.1 (Build 3285)

Problembeschreibung / Fehlermeldungen
Wir nutzen eine separate /home und /var partition
Die Anpassung in der Datenbank ( settings / quota ) wurde auf /home gesetzt

setquota versucht immer noch auf / eine Quota zu setzen obwohl diese auf /home gesetzt werden sollte.
und führt zur Fehlermeldung:
ERROR | setquota: Mountpoint (or device) / not found or has no quota enabled.

in der fstab wurde die Quota nur auf /home aktiviert
/var ext4 errors=remount-ro,usrquota,grpquota

wenn ich auf / die Quota in der fstab aktiviere wird die Quota die in der WebUI gesetzt wird auf / gesetzt was natürlich nicht das Ziel ist wenn /home als separate partition gemounted ist.

Ansonsten werden die quotas korrekt berechhnet und in der WebUI richtig angezeigt.
repquota zeigt jedoch die falschen Werte.
Es muss aber in einer alten Keyhelp version noch funktioniert haben da ich alle angelegten Benutzer mit repquota angezeigt bekomme aber teilweise mit "alten" werden und ein ändern über die WebUI bewirkt keine Quota Änderung auf der /home partition.

Wo kann man die Einstellung bezüglich setquota anpassen damit nicht versucht wird auf / sondern auf /home die Quota zu setzen.


Erwartetes Ergebnis

Nach Änderung des quota Settings von / auf /home/ sollten die Quota Einstellungen aus der WebUI mit den Werten von repquota übereinstimmen.
Weiters sollte die Fehlermeldung: "ERROR | setquota: Mountpoint (or device) / not found or has no quota enabled." nicht im update log erscheinen.

Tatsächliches Ergebnis
Fehlermeldung bzgl. setquota und die tatsächlichen Quota werte werden nicht gesetzt.

Schritte zur Reproduktion
- Separate /home partition
- ändern der keyhelp datenbank
"update settings set value='/home/' where name='file_system' and category='quota';"
- Ändern einer Benutzerquota -> abwarten des Update laufes
- Kontrolle des update.log -> Fehlermeldung bzgl. / partition bei setquota
- Prüfen der Quota mit "repquota /home/"

Zusätzliche Informationen
(z.B. kürzlich durchgeführte Änderungen am Server, Auszüge aus Protokolldateien (/var/log/*, /var/log/keyhelp/php-error.log, etc.))

Hallo,

in der fstab wurde die Quota nur auf /home aktiviert
/var ext4 errors=remount-ro,usrquota,grpquota

Das ist aber dann für /var aktiv und nicht für /home

Vollkommen korrekt, weil ich die falsche Zeile kopiert habe und genau das nicht mehr kontrolliert habe.

Sorry für den mislead.

Die korrekten Einträge sind:

/ ext4 errors=remount-ro 0 1
/home ext4 errors=remount-ro,usrquota,grpquota 0 2
/var ext4 errors=remount-ro 0 2


Ergibt bei:
repquota -a
*** Report für user Quotas auf Gerät /dev/vdb1
Blockgnadenfrist: 7days; Inodegnadenfrist: 7days
Block Limits Dateilimits
Benutzer belegt weich hart Gnade belegt weich hart Gnade
* Hier folgen alle Benutzerquotas *

Die UUID von vdb1 (blkid)
ist natürlich ident mit der UUID des /home Mountpoints

lG
Alex

Ergänzung - gerade gesehen:

Die Quotas wurden bis 13. Apr 2023 noch korrekt gesetzt
ab auf jeden Fall 31. May 2023 nicht mehr aber das ist nur das Datum der Anlage des ersten Users der nicht mehr korrekt gesetzt wurde (wir verwenden Templates) und der 13.04. das datum an dem der letzte noch korrekt gesetzte erstellt wurde.

Falls jemand einen Zusammenhang mit einem Update herstellen kann.
Ist leider nicht früher aufgefallen da die Quotas initial schon sehr grosszügig gesetzt werden und eine Nachtkorrektur selten nötig ist.

lG
Alex

Wenn alles korrekt eingestellt ist, wie du sagt, sollte es eigentlich funktionieren.

Schick mir mal SSH root Zugangsdaten per PM, dann kann ich morgen einmal nachsehen. Hab wahrscheinlich auch schon eine Idee woran es liegt.

Problem gelöst!

Für Leute mit gleichem Problem, hier die Befehle zum Austauschen der fehlerbehafteten Dateien.

# Für Debian 12 Systeme # Für Ubuntu 22 Systeme # Für Debian 11 / Ubuntu 20 Systeme


Der fix ist dann natürlich auch in KeyHelp 24.2 enthalten.

Perfekt!

Vielen Vielen Dank!
Kann bestätigen dass der Fix auf Debian funktioniert!

Anmerkung meinerseits noch, bitte um Korrektur falls ich falsch liege!
Ich würde nach dem Anwenden des Patches noch
service quota stop
quotacheck -avmugf
service quota start

auf der CLI ausführen und in der WebUI

unter Konfiguration -> Quota -> einmal auf speichern gehen damit die Quotas aus der WebUI auch ins Dateisystem wieder übernommen werden.

Vielen Dank nochmal für eure großartige Arbeit und den herausragend kompetenten und schnellen Support!

Liebe Grüße
Alex

x-it_gmbh wrote: ↑Tue 9. Jul 2024, 11:38 Ich würde nach dem Anwenden des Patches noch
service quota stop
quotacheck -avmugf
service quota start

auf der CLI ausführen und in der WebUI

unter Konfiguration -> Quota -> einmal auf speichern gehen damit die Quotas aus der WebUI auch ins Dateisystem wieder übernommen werden.

Genau, der erste Punkt stellt kein Problem dar
und Letzteres sollte man in jedem Fall noch machen (oder man vergleicht mit repquota).


Danke fürs Melden des Fehlers .