forum.opsi.org

Hallo Forum,

es wird mich freuen, wenn mich hier jemand auf das richtige Gleis setzen kann, da mir kein plausibler Lösungsweg einfällt.

Ich habe opsi sklavisch nach den Anweisungen in "Erste Schritte" auf unserem Univention Corporate Server installiert, inklusive dem digitec-opsi-listener. Allerdings können die Benutzer "pcpatch" und "adminuser", die während der Installation angelegt wurden, nicht auf die Freigabe "opsi_depot" zugreifen. Der Versuch wird mit der Meldung "Systemfehler 86", falsches Netzwerkkennwort, unter Windows quittiert. Ich habe das Passwort mehrfach über "opsiadmin -d task setPcpatchPassword" und über die grafische Oberfläche des UCS geändert, ohne Erfolg. Wechselt man auf der Konsole per "su pcpatch" in das Konto und versucht, das Passwort über "passwd" zu ändern, wird das mit dieser Meldung quittiert: Da ich vermutete, dass das wegen Samba4 offenbar schwierige Zusammenspiel von opsi und LDAP eine Ursache sein könnte, habe ich über die grafische Benutzeroberfläche des UCS den Benutzer "pcpatch" gelöscht und erneut angelegt - ohne Erfolg. Was eigenartig ist: die opsi-Gruppen (opsifileamdins und opsiadmin) tauchen zwar im grafischen Backend, nicht aber unter /etc/group und auch nicht unter "samba-tool group list" auf; in /etc/group ist allein der Eintrag shadow42:opsiconfd zu finden.

Also hab ich mir den Spaß gegönnt und die Gruppe "opsifileadmins" über "samba-tool group add" angelegt und ihr dann ebenfalls von Hand den Benutzer "pcpatch" beigefügt.

Ergebnis: immer noch kein Zugriff.

Der UCS-Benutzer "Administrator", der ausweislich der UCS-Benutzeroberfläche Mitglied der Gruppe "opsifileadmins" ist, kann die Freigabe auf einem Windows-Client problemlos mounten - die Benutzer pcpatch und adminuser können das nicht.

Hier ist irgendetwas vergniesgnaddelt und ich komme nicht drauf, was das sein könnte.

Bin für jede Hilfe danke,


Christian

+ 1
soll heissen. Bei mir genauso. Allerdings habe ich abgesehn von Neustart und Überprüfung der Einstellungen von weiteren Modifikationen abgesehen.

Danke.

Hallo

schaut bitte mal hier
viewtopic.php?f=1&t=4810

hilft das weiter?

Gruß
Karsten Köpke

Hallo,

der Thread ist zwar uralt, allerdings habe ich derzeit genau die gleiche Herausforderung mit einem UCS 4.0.1-1 (aktuelles) und dem aktuellen Opsi.

Ich sehe den user pcpatch auch im UDM, er ist auch Mitglied der Gruppe opsifileadmins. diverse male aufgerufen, genauso wie und restart der Dienste.

Ich bekomme nirgends Fehler geworfen, so weit sieht es gut aus.

Der genannte Tip hilft nicht, bzw. ist bei aktuellen Installationen ja schon umgesetzt, in der /etc/samba/shares.conf.d/opsi_depot stehen bereits @opsifileadmin administrator und join-backup als admin users drin.

Wenn ich nun aber ein Netboot-Produkt (z.B. hwaudit, oder auch ein win7-x64) laden will, funktioniert der pxe-boot auch wunderbar und alles läuft gut, bis er das depot mounten will (\\opsiserver\opsi_depot), hier bricht er ab mit Permission denied.

Seltsamerweise taucht der user pcpatch auch nicht in der Liste auf wenn ich per mir die user mit Sambazugriff anzeigen lasse (obwohl er im UDM wie oben beschrieben ganz normal auftaucht und auch alle Eigenschaften korrekt aussehen).

Wenn ich im configed Interface unter Host-Parameter -> clientconfig den Eintrag clientconfig.depot.user den Nutzer auf <Domäne>\Administrator statt <Domäne>\pcpatch ändere funktioniert im übrigen alles wunderbar, das ist aber natürlich nicht der gewünschte weg.
Es hängt also irgendwo am pcpatch user !?

Ich stehe auf dem Schlauch Hat jemand Vorschläge?

VG,
Sebastian

Wie wurde denn opsi installiert? Manuell gemäß Getting Started oder übers AppCenter?

Bitte führ mal folgendes auf dem Master aus und poste die Ausgabe dann hier: