Nextcloud Desktop Client kann nichtmehr verbinden?

[Marek72]

ok, da ist das Problem...
Variante 1. - setze mal in Zeile 4 die RewriteEngine auf Off -> Datei speichern

dann den Webserver neu starten mit: systemctl restart apache2

oder

Du kommentierst die Zeilen 3-7 aus:

#<IfModule mod_rewrite.c>
# RewriteEngine On
#RewriteCond %{HTTPS} !=on
#RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
#</IfModule>

also eine Raute # vor die Zeilen setzen.

dann den Webserver neu starten mit: systemctl restart apache2

Dann kannst Du Sache nochmal curlen wie oben - dann sollte auch ein 200er Statusmeldung kommen oder Du testest das gleich mit dem Client. Der NC Client wird Dich dann aufmerksam machen das kein Zertifikat vorhanden ist aber dann einfach "trotzdem vertrauen". - Dann sollte es eigentlich klappen :-)

 

[Keylan]

hmmm, nee das gibt auch keinerlei besserung.

Das ergebnis des curl hat sich etwas geändert. Enthält jetzt einiges an passphrases die ich wieder raus nehme.

*   Trying 192.168.178.25:80...
* Connected to 192.168.178.25 (192.168.178.25) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.178.25
> User-Agent: curl/7.78.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Date: Mon, 20 Sep 2021 22:11:31 GMT
< Server: Apache
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-######='; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *; object-src 'none'; base-uri 'self';
< Set-Cookie: oc_sessionPassphrase=######; path=/; secure; HttpOnly; SameSite=Lax
< Set-Cookie: ######=######; path=/; secure; HttpOnly; SameSite=Lax
< Set-Cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
< Set-Cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
< Strict-Transport-Security: max-age=15768000; includeSubDomains
< Referrer-Policy: no-referrer
< X-Content-Type-Options: nosniff
< X-Download-Options: noopen
< X-Frame-Options: SAMEORIGIN
< X-Permitted-Cross-Domain-Policies: none
< X-Robots-Tag: none
< X-XSS-Protection: 1; mode=block
< Upgrade: h2,h2c
< Connection: Upgrade
< Location: https://192.168.178.25/login
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
<
* Connection #0 to host 192.168.178.25 left intact

Ich weiß die Hilfe wirklich zu schätzen. Bei so Änderungen von Konfigurationsdateien wäre ein kleiner Absatz was ich den da Umstelle zur Erklärung aber wirklich hilfreich. Notfalls auch ein Link, der den Bereich etwas erläutert.

Nachdem das jetzt anscheinend nicht den gewünschten Effekt hatte drehe ich das erst mal wieder zurück. Zumindest wurde weder beim Zugriff per Browser etwas abgefragt, noch hat der Client auch nur einen Pieps von sich gegeben als ich den Angestossen hatte.
Ganz kurz im SystemTray und dann schon wieder Tot.

 

[M-X]

Inder config

'overwrite.cli.url' => 'http://pi/',
'overwriteprotocol' => 'http',

Ich würde das mal probieren.

1. Ändern von https auf http
2. Als weiter Zeile hinzufügen

Nextcloud überschreibt über diese Parameter die URL an einigen Ecken (die Doku ist nicht so 100% genau wo überall) und laut deiner config auf httpS, was ohne Zertifikate natürlich nicht klappt. Eigentlich sollte das nur für Proxy Setups relevant sein aber probieren kannst du es.

 

[niteaholic]

Ich sehe dass du kein port für deine mysql eingetragen hast. Oder läuft bei dir via sqllite?

 

[Marek72]

Die Idee von @M-X wäre ein Versuch Wert - als anderer Ansatz wäre noch die .htaccess im Webroot Verzeichnis von Nextcloud. Auch da könnte eine Rewrite Regel hinterlegt sein, die die URL von http auf https umgeschreibt.

@Keylan - DU ich greife auch nochmal Deinen Wunsch auf, die Änderungen zu kommentieren was die oben besagte Config angeht. Das Modul mod_rewrite ermöglicht es dem Webserver zu gestatten angeforderte URL's umzuschreiben. Stichwort Suchmaschinenfreundliche URL's wäre ein Thema. Das Verfahren wird aber auch dazu genutzt den Webserver anzuweisen eine http Anfrage in eine https Anfrage "umzuwandeln". Das scheint eben bei Dir zu passieren weil der Statuscode 302 besagt das Deine Anfrage weitergeleitet wird - also von http//localhost:80 auf https://localhost/:443. Diese Regeln werden entweder in der VirtualHost Datei oder in der .htaccess Datei definiert. Wobei auch diese Reihenfolge so vom Webserver abgearbeitet wird. Der Tipp von @M-X wäre wie gesagt ein Versuch Wert aber ich befürchte das der so nicht funktionieren kann.

 

[Keylan]

Hallo und nochmal Danke für die Antworten und Hilfestellungen.

@M-X Leider hat die Umstellung des Verweises auf http nichts gebracht. Vielmehr hat es den Aufruf im Browser in sofern zerschossen, das der jetzt eben auch auf http gesprungen ist. Da hat https ja aber schon funktioniert.

@niteaholic Das ganze läuft mit MariaDB

@Marek72 Vielen Dank für die Erklärung. Das hilft mir nicht nur generell um dazu zu lernen, sondern auch um deutlich gezielter bei der Web Recherche nach dem Thema suchen zu können. Ebenso dabei deinen Ansatz nachzuvollziehen und selbst darauf aufbauen zu können.

Nachdem Ich jetzt noch einige Stunden die Nextcloud Dokumentation durchgegangen bin aber überall nur in Sackgassen gelaufen bin habe ich Kapituliert.
Ich habe die ganze Nextcloud Einrichtung Zurückgesetzt (Er zieht neue Quellen und Setzt die komplette Konfiguration auf Default). Natürlich hat er die alten Repositorys nur Gesichert und nicht integriert. Ohne das ich ohnehin alles im händischen Backup gehabt hätte wäre das nochmal ein schöner Spaß gewesen die Daten da raus zu ziehen. Auch ohne Verschlüsselung recht nervig.
Sonst war die Konfiguration durch mich aber recht Übersichtlich und konnte in den groben Zügen schnell nachgezogen werden.
Die Clients haben als Sie den alten Host nicht mehr gefunden haben zumindest wieder gestartet und Settings aufrufen lassen. Als dann die neue Instanz mit altem Hostnamen da war schön die Lokalen Nextcloud Verzeichnisse einfach gelöscht und mit dem Bloat-Kram des Servers ersetzt. Die Sync Verzeichniss hatte er sich aber gemerkt und nach 3-4 Verschluckern hat er dann auch sauber den Sync wieder gemacht.
Sowohl auf Linux als auch Windows laufen jetzt die Clients wieder, und da bisher nur ein User auf dem System ist, ist auch alles recht schnell erledigt. Wenn ich das aber für eine Ganz Gruppe managen müsste wäre das ne Aufwändige Lösung.

Insofern hoffe ich mal, das diese Phänomen nicht einfach wieder auftritt.

 

[M-X]

Warte du nutzt doch https? Ich hatte es so verstanden das du es ja nur im lokalen Netz nutzt und daher kein https und daher keiner Zertifikate hast, dann konnte mein Tipp natürlich nicht funktionieren.

Es scheint als werden Zertifikate zur Websocket Verbindung nicht gefunden. Problem ist nur, dass ich nie Zertifikate angelegt habe und auch nicht wüsste wo ich das hier tun sollte.
Klar, wenn man die Encyption nutzt muss dafür noch was mit Zertifikaten erstellt werden und der Key abgelegt werden.

 

[niteaholic]

Welcher DB Port hast du für mariadb als docker eingestellt? Dieser sollte auch in der cfg gewesen sein, was bei dir ja nicht der fall war.

 

[Keylan]

Welcher DB Port hast du für mariadb als docker eingestellt? Dieser sollte auch in der cfg gewesen sein, was bei dir ja nicht der fall war.

Von Docker war doch gar nicht die rede. Ich habe NexcloudPi direkt auf Rasperian installiert. Hatte vorher gelesen, das die Konfiguration von Nextcloud im Docker aufwendiger ist weil es eben nicht im Host läuft und hab mir das deshalb gespart.

@M-X Der Server legt bei Installation schon irgendwelche SSL Zertifikate an. Allerdings habe ich das weder gezielt angestossen, noch die Zertifikate irgendwo eingebunden. Auch gib es keine CA und im Browser wird die fehlende Authorisierung explizit aktzeptiert. Solange ich bei mir im Netz bleibe ist das denke ich auch ok. Wenn ich die Kiste mal von Aussen erreichbar machen will, ist dann etwas mehr zu tun mit Domäne, SSL und Encryption.