Oh, schade, das Joinscript hat einen kleinen Mechanismus um zu erkennen, ob es schon mal gelaufen ist und steigt dann gar nicht mehr in den relevanten Teil ein. Kannst du folgende Datei löschen:
/var/lib/univention-appcenter/apps/nextcloud/conf/initial_config_done
und dann nochmal anstoßen?
univention-run-join-scripts --force --run-scripts 50nextcloud.inst
Sorry, das hatte ich nicht auf dem Zettel.
Guten Tag,
ich habe leider die gleichen Probleme wie Frank, daher die Frage, ob es hier schon eine Lösung gibt?
@omega: Ist es sicher das gleiche Problem? Bei Frank lautete die Fehlermeldung beim Aufruf der API:
<message>Invalid query, please check the syntax. API specifications are here: http://www.freedesktop.org/wiki/Specifications/open-collaboration-services.
Das hab ich so noch nicht gesehen.
Was ich vorallem nicht verstehe ist, wenn ich ein System mit 4.1 aufsetzte. Kopano und Nextcloud und LetsEncrypt einrichte, dann das Update auf 4.2 mache - dann geht es.
Ebenso wenn ich 4.1 installiere, gleich das Update auf 4.2 und dann Kopano, Nextcloud und Letsencrypt.
Nur wenn ich gleich 4.2 installiere geht es nicht…
Ja, exakt gleicher Eintrag im Logfile.
Ich habe das Bild heute nach einem Neustart auch gesehen…
Mein Container hatte recht spärliche /etc/resolv.conf und /etc/hosts Dateien.
Nachdem ich da den UCS-Master eingetragen habe, geht die Anmeldung der LDAP-Benutzer wieder. Auch ich hatte den user=-- im log-file.
Allerdings gibt es noch keine Verbindung von Nextcloud zum Internet, nur:
GuzzleHttp\Exception\ConnectException: cURL error 6: Could not resolve host: www.github.com
etc.
Das scheint bei mir geholfen zu haben. Ebenfalls in der /etc/hosts im nexctloud-docker die IP des UCS-Master eingetragen und jetzt kann ich mich anmelden.
Apps kann ich auch nachziehen, daher gehe ich davon aus, dass der Internzugang funktioniert bei mir.
@Grandjean Vielleicht hilft Euch das ja, den “Fehler” zu lokalisieren.
//edit: Einziges Manko, den Eintrag in die hosts “merkt” sich der nextcloud-Docker nicht - jemand einen Tipp, wie man das permanent macht?
Kannst du noch kurz schreiben wie der Eintrag genau bei dir aussieht? Den trage ich dann mit Hilfe der Dockershell im laufenden Container ein?
Zuerst per univention-app shell nextcloud in den Container und dort dann
echo -e "<IP.IP.IP.IP>\t<HOSTNAME>" >> /etc/hosts"
Wie gesagt, ist leider nicht permanent. Vl. könnte man den Thread hier auch mal splitten, um das ungelöste Problem wieder nach oben zu bringen @Grandjean
Das sieht mir danach aus, als würde das setup Script (im Container) nicht ordnungsgemäß durchgelaufen sein, mit der Folge, dass das LDAP Backend nicht aktiviert worden ist.
Okay, IP ist dann die externe IP des Servers und Hostname die registrierte Domain? Oder sind es die lokalen Daten? Hab den Zusammenhang noch nicht ganz verstanden
Momentan stehen in der hosts folgenden Einträge:
172.17.0.3 nextc-75141726
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
resolf.conf hat dieses hier:
domain Firma.intranet
nameserver IP.IP.IP.IP
options timeout:2
Edith:
Nach dem manuellen Eintragen findet er den LDAP tatsächlich, allerdings keine User. Ist da noch mehr im argen?
Es gibt User bei denen unter erweiterte Einstellungen der Haken bei NextCloud gesetzt ist, er sollte eigentlich was finden. LDAP wurde auch schon neu gestartet.
Gut, nach dem Aufsetzen einer kleinen TestVM und dem Abschreiben aller relevanten LDAP Daten läuft das Ganze nun endlich auch mit LDAP Authentifizierung. Vielen Dank für die Hilfe 