Bin gerade bei der Neuinstallation von 7.4. Bei linuxmuster-setup habe ich kurz vor dem Ende mehrfach folgenden Fehler erhalten:
Command '['ssh', '-q', '-oNumberOfPasswordPrompts=0', '-oStrictHostkeyChecking=no', '-l', 'root', '10.0.0.254', 'exit']' returned non-zero exit status 255.
Eigene Schule?
Aus der Anleitung wird mir auch nicht klar, wie ich eine eigene Schule statt default-school anlegen könnte. Ist das erst nach dem Setup möglich? Gibt es die default-school also immer?
Fehlgeschlagener Service auf Server
Nach dem Neustart des Servers schlägt quotaon@srv.service fehl.
× quotaon@srv.service - Enable File System Quotas
Loaded: loaded (/usr/lib/systemd/system/quotaon@.service; enabled-runtime; preset: enabled)
Active: failed (Result: exit-code) since Mon 2026-08-24 18:22:16 CEST; 3min 37s ago
Invocation: 46d15ee9cf824330a0b62be4fa9a8170
Docs: man:quotaon(8)
Process: 976 ExecStart=/usr/sbin/quotaon -ug /srv (code=exited, status=2)
Main PID: 976 (code=exited, status=2)
Mem peak: 2M
CPU: 22ms
Aug 24 18:22:16 server.lmn.ohgw.de systemd[1]: Starting quotaon@srv.service - Enable File System Quotas...
Aug 24 18:22:16 server.lmn.ohgw.de quotaon[976]: quotaon: Cannot stat() mounted device tmpfs: No such file or directory
Aug 24 18:22:16 server.lmn.ohgw.de quotaon[976]: quotaon: Cannot stat() mounted device tmpfs: No such file or directory
Aug 24 18:22:16 server.lmn.ohgw.de quotaon[976]: quotaon: using . on /dev/sdb1 [/srv]: File exists
Aug 24 18:22:16 server.lmn.ohgw.de quotaon[976]: quotaon: using . on /dev/sdb1 [/srv]: File exists
Aug 24 18:22:16 server.lmn.ohgw.de systemd[1]: quotaon@srv.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Aug 24 18:22:16 server.lmn.ohgw.de systemd[1]: quotaon@srv.service: Failed with result 'exit-code'.
Aug 24 18:22:16 server.lmn.ohgw.de systemd[1]: Failed to start quotaon@srv.service - Enable File System Quotas.
Squid auf OPNsense lässt sich nicht starten
template reload OPNsense/ProxySSO: OK Starting squid. CPU Usage: 0.020 seconds = 0.010 user + 0.010 sys Maximum Resident Size: 63552 KB Page faults with physical i/o: 0 2026/08/24 18:34:40| Processing Configuration File: /usr/local/etc/squid/squid.conf (depth 0) 2026/08/24 18:34:40| Not currently OK to rewrite swap log. 2026/08/24 18:34:40| storeDirWriteCleanLogs: Operation aborted. 2026/08/24 18:34:40| FATAL: Unable to open configuration file: /usr/local/etc/squid/squid.conf: (13) Permission denied 2026/08/24 18:34:40| Squid Cache (Version 6.14): Terminated abnormally. /usr/local/etc/rc.d/squid: WARNING: failed to start squid
In der Doku zum Setup des File-Servers ist m.E. folgende Zeile falsch:
„Öffne nun die Konsole auf dem AD und wechsel zum Benutzer root.“
Statt „AD“ müsste es doch „File-Server“ heißen, oder nicht?
Die ssh-Meldung ist kein Fehler. Hintergrund: Am Ende des Setups wird darauf gewartet, dass die Firewall wieder online ist. Dabei werden immer wieder Verbindungsversuche per ssh gemacht, die eben fehlschlagen und geloggt werden. Ich werde das künftig unterdrücken (s. #196).
Die quota-Fehlermeldung weist tatsächlich auf einen Bug hin. Es wird unnötigerweise versucht, den quota-Service für eine Partition zu starten, den das moderne interne ext4-quota-Feature auf Kernelebene automatisch schon aktiviert hat. Wird im nächsten Release gefixt (s. #197), allerdings nur für Neuinstallationen. Du musst den quotaon service für /srv manuell mit folgenden Schritten maskieren:
# 1. Bestätigen, dass Quota auf /srv tatsächlich schon aktiv ist
# (kernelseitig durchs Bord-Feature, unabhängig vom kaputten Service)
quotaon -p -u /srv
quotaon -p -g /srv
repquota /srv # zeigt echte Nutzungsdaten, falls aktiv
# 2. Den überflüssigen, dauerhaft scheiternden Service maskieren
sudo systemctl mask quotaon@srv.service
# 3. Den "failed"-Status aus systemctl/journalctl aufräumen
sudo systemctl reset-failed quotaon@srv.service
# 4. Kontrolle
systemctl status quotaon@srv.service
OPNsense/Squid: Offensichtlich hat squid.conf falsche Berechtigungen. Das Setup hat mit dieser Datei aber nichts zu tun. Versuche auf der OPNsense-Konsole squid.conf sauber neu zu erstellen:
quotaon -p -u /srv
quotaon: Cannot stat() mounted device tmpfs: No such file or directory
quotaon: Cannot stat() mounted device tmpfs: No such file or directory
user quota on /srv (/dev/sdb1) is on
root@server:~# quotaon -p -g /srv
quotaon: Cannot stat() mounted device tmpfs: No such file or directory
quotaon: Cannot stat() mounted device tmpfs: No such file or directory
group quota on /srv (/dev/sdb1) is on
root@server:~# repquota /srv
repquota: Cannot stat() mounted device tmpfs: No such file or directory
repquota: Cannot stat() mounted device tmpfs: No such file or directory
*** Report for user quotas on device /dev/sdb1
Block grace time: 7days; Inode grace time: 7days
Block limits File limits
User used soft hard grace used soft hard grace
----------------------------------------------------------------------
root -- 537216 0 0 812 0 0
nobody -- 4 0 0 1 0 0
_opentracker -- 4 0 0 2 0 0
#3000000 -- 152 0 0 19 0 0
#3000004 -- 80 0 0 10 0 0
#3000024 -- 8 0 0 1 0 0
Deaktivieren und Maskieren von quotaon@srv.service hat natürlich problemlos geklappt. systemctl status zeigt nun keine Fehler mehr.
Gibt es einen Zusammenhang damit, dass der rsync-Befehl beim Einrichten des File-Servers zwar die Daten von default-school korrekt übertragen hat, auf dem Server aber nicht löschen konnte (permission denied)?
Ist es bei einer Neuinstallation wirklich so gedacht, dass /srv/samba/schools/default-school zuerst auf dem Server anlegt und danach per rsync auf den File-Server übertragen wird, oder bin ich in der Doku falsch abgebogen?
Btw, falls es Dir oder mir etwas brächte: Noch könnte ich mit relativ geringem Aufwand auf den Snapshot vor linuxmuster-setup zurückgehen.
ich behandle das Squid-Problem in dieser separaten Antwort, damit der Thread halbwegs übersichtlich bleibt.
Die von Dir genannten Befehle zum Neuerstellen der squid.conf haben leider nichts gebracht. Offensichtlich stimmen die Berechtigungen nach wie vor nicht:
root@firewall:~ # ls -al /usr/local/etc/squid/squid.conf
-rw-r----- 1 root wheel 3781 Aug 25 09:38 /usr/local/etc/squid/squid.conf
Unter Firmware werden
os-squid
os-web-proxy-sso
als misconfigured angezeigt (neben Freeradius, das wir aber nicht nutzen).
kannst Du mir sagen, wie die Rechte für squid.conf in der OPNsense gesetzt sein müssten? Das Plugin wird aber vom Skript hinzugefügt, richtig? Nach der Erstinstallation war das meines Erachtens noch nicht installiert.
Ich kann die Rechte von /usr/local/etc/squid/squid.conf manuell auf 644 setzen und danach den Dienst starten. Nach einem Neustart der OPNsense stehen sie aber wieder auf 640, und der Dienst lässt sich nicht mehr starten.
Die Rechte für das Verzeichnis /usr/local/etc/squid/pre-auth musste ich zudem auf 755 setzen (stand auf 750), für die darin enthalten Dateien auf 644 (stand auf 640). Diese manuelle Änderung überlebt den Neustart.
Ich habe folgende Versionen:
OPNsense 26.7.2_2-amd64
os-squid 1.4_1
os-web-proxy-sso 2.2._3
Die Anzeige als misconfigured bleibt auch nach erfolgreichem Start des Squid-Dienstes bestehen.
Auf der Kerberos-Seite sind aber alle Haken grün, und der Login-Test liefert ein gültiges Ticket.
Mit dem Reboot-Problem kann ich aber nicht live gehen. Any ideas?
www/squid -- Squid is a caching proxy for the web (not maintained)
www/web-proxy-sso -- Kerberos authentication module (not maintained)
Das klingt nicht sehr verheißungsvoll …
Wurde in diesem Thread ja schon diskutiert. Hätte ich erst eine ältere Version der OPNsense installieren müssen und diese später updaten? Oder deaktiviere ich einfach Squid und SSO? Das Problem müssen andere doch auch haben.
linuxmuster-base v7.4.17 bringt vier Fixes, die sich aus den letzten Rückmeldungen ergaben:
Quota-Service-Fehler nach Neustart (#197) – quotaon@srv.service schlug bei jedem Boot mit „File exists“ fehl, wenn ein nicht-root-Dateisystem (z.B. /srv) bereits das moderne ext4-Bord-Quota-Feature mitbrachte. e_fstab.py maskiert jetzt gezielt auch die betroffene Mount-spezifische Service-Instanz, nicht mehr nur die von root.
Irreführende SSH-Fehlermeldungen beim Setup (#196) – Das Warten auf den Neustart der Firewall (waitForFw()) loggte jeden erwarteten, aber fehlgeschlagenen Verbindungsversuch während des Reboots wie einen echten Fehler. Läuft jetzt still im Hintergrund, ohne den Eindruck eines gescheiterten Setups zu erwecken.
SSO-Anmeldung am Webproxy nach Setup unzuverlässig (#198) – Squid wurde nur vor der Keytab-Erstellung neu gestartet, nie danach. Jetzt gibt es einen zweiten Neustart, nachdem Keytab und SPN wirklich existieren.
Firewall-Regeln im veralteten Format (#199) – Die 7 mitgelieferten Firewall-Regeln landeten wegen OPNsense 26.1 im „Legacy“-Schema und mussten manuell über den Migration Assistant konvertiert werden. Sie werden jetzt direkt im neuen, UUID-basierten Regelformat angelegt – live gegen eine echte OPNsense-26.7-Instanz verifiziert.
ich habe mit einer OPNsense 26.7.2_2 und den aktuellsten lmn-Paketen eine from-scratch Installation und setup der lmn v7.4 durchgeführt.
Dieses ist ohne weitere Fehler in den logs durchgelaufen.
Aber - und das gab es mit anderen OPNsense - Versionen so bislang nicht - kann ich das beschriebene Squid-Problem so bestätigen - auch wenn das mit dem Setup nichts zu tun hat.
Die Berechtigungen für squid.conf und anderen Dateien sind wie zuvor beschrieben falsch gesetzt. Passe ich diese an, kann ich Squid korrekt starten, die Berechtigungen gehen aber bei einem Neustart verloren.
Ich hatte die FW ursprünglich mit 26.1.6 aufgesetzt und später auf 26.7 aktualisiert. Evtl. macht das den Unterschied. Bei mir funktioniert Squid ohne Probleme.
Ein chgrp -R squid /usr/local/etc/squid (kein chmod) sollte genügen – die 750/640-Rechte sind korrekt und sollen so bleiben, da pre-auth.conf das LDAP-Bind-Passwort im Klartext enthält), danach startet Squid sauber, auch nach einem Reboot.
Könntet ihr das bitte nachvollziehen?
Hintergrund:
Bei einer frischen Installation mit 26.7-Installationsimage wird /usr/local/etc/squid beim ersten Boot mit falscher Gruppe wheel neu angelegt. Da 750/640-Rechte gesetzt sind, kann squid die Datei nicht lesen, weil es mit Gruppe squid läuft.
Bei einer Installation mit einem älteren Image, das aktualisiert wurde, existiert der Ordner schon mit korrekter Gruppe squid, was bei einem Upgrade nicht angefasst wird.
Das Problem tauchte also jetzt auf, da 26.7 die Dateisystemrechte restriktiver setzt.
Ein Fix für das Setup, der die Gruppe korrekt setzt, ist in Arbeit.
ich habe aktuell die Versionen 7.3 und 7.4 vom Scratch installiert.
Bei den Vorgängerversionen konnte oder musste man das -l für die Partition und das -v für die Aufteilung mit angeben, wenn man die ./lmn-appliance ausgeführt hat.
Bei der 7.3 kann man diese Einstellungen nach dem Ausführen noch eintragen, da die Informationen noch einmal bestätigt werden müssen. Hier läuft das Script auf Fehler, wenn man versucht, schon bei der Eingabe das -l und -v mit anzugeben.
In der 7.4 kommt die Bestätigungsanfrage gar nicht und er installiert mit Standardwerten drauflos.
Dabei ist /samba/* nicht unter /srv. Bis jetzt habe ich es noch gar nicht gefunden. Noch habe ich nicht das linuxmuster-setup ausgeführt, da mir dieser aktuelle Zustand nicht richtig vorkommt.
Unten aktuell ein paar Screenshots zum aktuellen Zustand.
Vielleicht kann einer mich mal informieren, ob generell die Version 7.4 mit dem verfügbaren GitHub-Script nicht funktioniert oder ob ich einen bestimmten Schritt besonders beachten muss.
