Installation auf Qnap mit Debian 10 per Repository schlägt fehl

Hallo zusammen,

Ich habe ein älteres Qnap mit Debian drauf. Das lief alles sehr stabil mit OMV2 und Debian Wheezy. Da Wheezy sehr alt war, hatte ich mich entschieden upzugraden, also von Wheezy auf Jessie von Jessie auf Stretch und von Strech auf Buster.

Um quasi bei Null anzufangen und nicht meine Daten auf dem Raid zu verlieren, habe ich mit apt purge das System komplett bereinigt. Auch alte User habe ich entfernt. Das System läuft stabil.

Nun wollte ich OMV5 installieren und die Probleme fingen an. Und zwar bekam ich erst Meldungen, dass Gruppen nicht angelegt werden konnten, händisch ging es aber problemlos, dann meldete apt, dass die Einstellungen UID_MAX, SYS_GUID_MIN, MAX, etc., der /etc/login.defs nicht stimmen. Also habe ich diese auf Default zurückgesetzt.

Jetzt bricht er bei derE inrichtung des Users ab.

Useradd: Fehler beim Schreiben der Änderungen nach /etc/passwd

Es sind keine Locks etc. vorhanden (/etc/passwd.lock) also die üblichen Verdächtigen. Das anlegen von hand funktioniert problemlos, ich kann user adden, löschen, alles kein Problem. Geht auch mit adduser oder useradd.

Ich weiß jetzt nicht mehr weiter. Welche Benutzer will er während der Installation anlegen?

Es scheint ein Problem mit den UID's aus der Login.defs zu geben, die ich zwar behoben habe, aber kann es sein, dass die bereits angelegten User und Gruppen mit ihren Uid's jetzt einen Konflikt verursachen?

Hey danke für die Antwort! Das Problem bei einer Neuinstallation ist laut Doku, dass das NAS komplett neu geflasht wird, also auch das Raid flöten geht. Daher habe ich den langen langen aufwendigen Weg der Upgrades gewählt.

Das Script kannte ich tatsächlich gar nicht, das ist ein echt heißer Tipp, vielen Dank dafür!

Es ist auch echt blöd, dass eine Installation an einer Benutzereinrichtung scheitert. So erwas ist ja in der Regel schnell abgefrühstückt.

Ich werde es mit dem Script mal probieren und melde mich mit den Resultat!

Heyhey, habe das Script runtergeladen, gecheckt und ausgeführt. Es scheint zwar eher für einen busterbadierten Raspi zu sein, aber das ist vollkommen egal an dieser Stelle.

Leider mit dem gleichen Ergebnis. Letztendlich ruft das Script während der Ausführung auch nur apt install openmediavault auf und läuft dann auf genau den gleichen Fehler:

Useradd: failure while writing changes to /etc/passwd

Und weiter gehts!

Heureka!

Ich habe mich von macom dazu inspirieren lassen zwar nicht mein Qnap, aber mal ein Buster neuzuinstallieren und zwar habe ich das eben schnell in meiner Proxmox PVE virtuellen Umgebung in einem LXC Container getan, das ganze hat nicht mal eine Minute gedauert und das Buster war da.

Eine Installation von Openmediavault ist da allerdings auch fehlgeschlagen, aber aus ganz anderen Gründen.

Jedenfalls um meine eigenen Fragen zu beantworten es werden folgende Benutzer und Gruppen von OMV während der Installation erstellt:

Benutzer (/etc/passwd):
openmediavault-webgui:x:998:995::/home/openmediavault-webgui:/usr/sbin/nologin
admin:x:997:100:WebGUI administrator:/home/admin:/usr/sbin/nologin

Gruppen (/etc/group):
openmediavault-config:x:998:openmediavault-webgui
openmediavault-engined:x:997:openmediavault-webgui
openmediavault-admin:x:996:admin
openmediavault-webgui:x:995:

Dennoch habe ich mir bei dem neuen virtuellen Buster mal die Datei /etc/login.defs angesehen und festgestellt, dass diese anders aussah als meine. Ich habe meine nach der Debian Dokumentation (man pages) wieder auf Default-Werte gesetzt, allerdings sind bei einer frischen Installation von Buster schlichtweg einige Werte auskommentiert.

Ich widerum habe diese nach Dokumentation mit den Default-Werten befüllt und aktiv gelassen. OMV scheint bei der Installation den Befehl useradd mit irgendwelchen Parametern aufzurufen, die ein Problem mit den eigentlichen Default-Werten haben. Es scheint einen Unterschied zu machen ob ein Wert gesetzt oder auskommentiert ist, und ich meine jetzt nicht NULL und Null (0), sondern der Default-Wert scheint bei einer auskommentierten Zeile ein anderer zu sein, als der, der in den man pages steht.

Nun warum war meine login.defs anders?

Ganz einfach, wer schon einmal sein Linux-System mit einem Active Directory gekoppelt hat, der weiß, dass die UID und GUID eine gewisse Rolle für Samba und auch für OMV spielt. OMV brauchte zumindest damals dort eine Anpassung, da die User und Gruppen sonst nicht richtig angezeigt wurden.

Mal ehrlich, wäre einer von euch bei dieser Fehlermeldung auf irgendwelche Einstellungen in der login.defs gekommen? Ich denke nicht.
Ich könnte mir vorstellen, dass einige User bei Migrationen etc., auf das gleiche Problem stossen könnten wie ich.

Hier wäre es schön gewesen, wenn OMV bei diesem Fehler, vielleicht den verwendeten Befehl mit in der Fehlermeldung ausgeben könnte, denn das Anwenden von useradd etc, von mir selbst in der Shell funktionierte problemlos.

Ich bin schon in der IT tätig, da nannte man das noch "EDV" und ich habe noch nie so einen "Fehler" (war es denn einer?) während einer Installation von Software gehabt. Hier ging es letztendlich nur um Service-User, und nicht um Abhängigkeiten von Paketen oder Ähnliches, die alles gestoppt und die Installation abgebrochen haben.

Jedenfalls hier noch ein paar ungewollte Ratschläge für die Leute die ähnliche Probleme haben:
- Ein Linux-System lässt sich zu 99,99 % immer reparieren. (Anders als bei Windows)

- Prüft immer die Benutzer-Berechtigungen stimmen für das was gemacht werden soll. (chown / chmod)

- Prüft immer ob *.lock Dateien vorhanden sind. (/etc/passwd.lock, /etc/group.lock, etc.)

- Vergleicht bei aller Hilflosigkeit euer System mit einem anderem. (Virtualbox Images nutzen zum Beispiel)

Danke nochmal an macom für den Hinweis mit dem Script und die Inspiration einer Neuinstallation, oder einfach mal ein Buster in ein LXC Container zu werfen.