Anleitung: nextcloud mit nginx reverse proxy und LetsEncrypt auf Docker

    Anleitung: nextcloud mit nginx reverse proxy und LetsEncrypt auf Docker

    Beschreibung

    Diese Anleitung beschreibt, wie man auf einem Docker-fähigen QNAP-System nextcloud mit folgenden Leistungsmerkmalen installiert:

    • 5 Docker-Container auf einem QNAP hinter einem Internet-Router
      • Nginx-Reverse-Proxy
      • Lets-Encrypt-Companion
      • Web-Server
      • nextcloud
      • Maria-DB
    • verschlüsselter Aufruf über eine Subdomain, Portangabe nicht erforderlich
    • SSL-Verschlüsselung auf Basis von kostenlosen LetsEncrypt-Zertifikaten, die automatisch verlängert werden.
    • einfache Installation über ein docker-compose-File und ein paar Konfigurationsfiles
    • einfache Aktualisierung der Docker-Container über 2 Befehle
    • Daten und Konfigurationen bleiben auf Docker-Volumes erhalten
    • Die Docker-Container können auch über die QNAP Container-Station gemanaged werden. Leider sind nicht alle Einstellungen aus dem docker-compose-File sichtbar.

    Grundlagen

    Diese Anleitung basiert auf folgendem Beispiel:

    https://github.com/nextcloud/d…h-nginx-proxy/mariadb/fpm

    Da wir hier in einem QNAP-Forum sind, ist die Anleitung und die angehängte Musterkonfiguration auf QNAP-Verhältnisse abgestimmt. Die Anleitung lässt sich aber sicher z.B. auch auf einem Ubuntu-System umsetzen.


    Voraussetzungen

    1. Dockerfähiges QNAP-System hinter einem Internet-Router
      Bei mir ist es eine Fritzbox.
    2. Subdomain einrichten
      Die Subdomain (z.B. cloud.example.com) muss mit einem Typ A- oder Typ CNAME-Record auf die feste IP oder die DynDns-Adresse des Netzwerks zeigen, in dem sich auch das QNAP-System befindet. Eine einfache Weiterleitung funktioniert nicht!
    3. Ports 80 und 443 freimachen
      Die Ports 80 und 443 sind möglicherweise auf dem Router und dem QNAP bereits belegt. Sie müssen dort durch andere Ports ersetzt werden, da sie später vom ACME-Protokoll des LetsEncrypt-Containers benötigt werden. Diese lassen sich meines Wissens aktuell (noch) nicht überschreiben. Ich hatte zu Anfang immer mit Port-Mappings gearbeitet. Dann hat aber das Generieren der Zertifikate nicht funktioniert.
    4. Portweiterleitung im Router für Ports 80 und 443
      Im Router muss jetzt eine Portweiterleitung für die Ports 80 und 443 auf die IP des QNAP-Systems eingerichtet werden. Auf diese Ports wird später der nginx-Reverse-Proxy lauschen.
    5. Freigabe-Ordner auf QNAP
      Die spätere Konfiguration basiert darauf, dass auf dem QNAP folgende Freigabe-Ordner angelegt sind:

      Docker-Configs: für Docker-Konfigurationen
      Docker-Volumes: für die persistenten Daten der Docker-Container

    Konfiguration

    1. ssh-Zugang zum QNAP-System starten
      Ich arbeite hierfür gerne mit MobaXterm.
    2. Musterkonfiguration herunterladen
      Die angehängte Musterkonfiguration nextcloud.zip herunterladen und im Freigabe-Ordner Docker-Configs als Ordner nextcloud entpacken.
    3. Musterkonfiguration anpassen
      In der Musterkonfiguration muss nun im File db.env das Passwort für die nextcloud-DB eingetragen werden. User nextcloud und DB-Name nextcloud bleiben unverändert.
      Als nächstes wird das docker-compose.yml-File angepasst. Hier müssen folgende Werte geändert werden:
      - <<meinPasswort>> > Master-PW für mariaDB
      - cloud.example.com > Subdomain-Name
      - <<name>>@example.com > User für LetsEncrypt-Benachrichtigungen

    Build and Run

    1. Container erstellen
      Auf der ssh-Konsole in den Konfigurationsordner wechseln
      cd /share/CACHEDEV1_DATA/Docker-Configs/nextcloud/ 
      und den Build aufrufen
      docker-compose build --pull
    2. Container starten
      docker-compose up -d

    Nach der Installation

    1. Warten
      Nachdem die Docker-Container erstellt und gestartet wurden, sollte man erst einmal ca. 10 Minuten warten, bis sich die Container initialisiert haben. Insbesondere die Generierung des LetsEncrypt-Zertifikats für die Subdomain dauert eine Weile.
      Die Volumes werden autmatisch angelegt und erscheinen unter /share/CACHEDEV1_DATA/Docker-Volumes/nextcloud/.
      Insbesondere wird die Konfigurationsdatei für den nginx Reverse Proxy erzeugt. Man kann das Ergebnis unter /share/CACHEDEV1_DATA/Docker-Volumes/nextcloud/nginx-conf.d/default.conf ansehen.
      Den Initialisierungsprozess kann man auch über die QNAP-Container-Station beobachten.
    2. Abschließen der nextcloud-Installation
      Um die nextcloud-Installation abzuschließen, ruft man jetzt die Subdomain über einen Browser auf. Auf der nun erscheinenden Anmeldemaske gibt man UserID und Passwort für den Admin-User ein und muss anschließend noch einmal eine Weile warten, bis im Hintergrund die nextcloud-Datenbank fertig eingerichtet ist.

    Aktualisierung und Wartung

    1. Aktualisierung
      Neue Containerversionen installiert man einfach durch erneutes Aufrufen der Schritte 1 und 2 unter Build and Run. Die Daten bleiben über die Volumes erhalten.
    2. Spezielle Konfigurationen
      Besonderheiten insbesondere für den nginx Reverse Proxy können über spezielle Templates/Includes nachkonfiguriert werden. Wie das geht, kann man unter https://hub.docker.com/r/jwilder/nginx-proxy/ nachlesen.
    3. Container-Station
      Über die Container-Station lassen sich Container stoppen und starten. Außerdem können weitere Informationen über Container, Images und Volumes eingesehen werden.
      Spezielle Details bekommt man mit Hilfe von Original-Docker-Befehlen über die die ssh-Konsole.

    Viel Erfolg beim Nachbauen
    xgadscu

    Hallo xgadscu,


    danke für das HowTo!


    docker-compose up -d mit nem "done" am Ende positiv quittiert, jedoch starten dann folgende container mit Fehlern.


    Die Dockereinstellungen sind alle QNAP STandard, auch die Netzwerkeinstellungen.

    QNAP MariaDB ist deaktiviert. Firmware 4.3.4.0597.


    nextcloud_proxy_1

    Code
    nginx.1    | 2018/06/10 22:24:57 [emerg] 28#28: mkdir() "/var/cache/nginx/client_temp" failed (1: Operation not permitted)                                                                                                                                                      
nginx.1    | nginx: [emerg] mkdir() "/var/cache/nginx/client_temp" failed (1: Operation not permitted)                                                                                                                                                                          
forego     | starting nginx.1 on port 5200                                                                                                                                                                                                                                      
forego     | sending SIGTERM to nginx.1                                                                                                                                                                                                                                         
forego     | sending SIGTERM to dockergen.1

    wie kann ich dem Benutzer mehr Rechte geben im Container? Oder ist das nicht die Ursache?


    nextcloud_db_1

    Der QNAP MySQL/MAriaDB ist im AdminGUI dektiviert. Und auch hier Rechteprobleme?


    Über eine Hilfestellung würde ich mich freuen, sorry für mein "Unwissen" :saint: !


    GRüße

    cunctator

    Hallo cunctator,


    wenn Du Dich gemäß QNAP-Standard mit dem admin-User auf der ssh-Konsole anmeldest, sollten die Rechte ok sein. Ich habe jedenfalls nichts anderes gemacht als oben beschrieben.

    Aus Deinen Log-Auszügen kann ich nicht unbedingt die Ursache für Deine Probleme ersehen. Dazu müsste man die zugrundeliegende Konfiguration und ggfs. weitere Log-Auszüge haben.

    Zunächst einmal kann ich Dir folgende Tipps geben:

    Beim Starten müssen sich die Container aufeinander einspielen. Der eine ist von dem anderen abhängig usw. Aus diesem Grund kann es anfangs auch zu Fehlermeldungen kommen. Daher würde ich zunächst einmal alle Container stoppen und neu starten.

    Falls es beim Umsetzen meiner Anleitung zwischendurch mal Fehler gegeben haben sollte, könnte es sein, dass irgendetwas nicht zusammen passt. Dann kannst Du, und das ist das Schöne daran, alle Container und ggfs. sogar alle Images einfach löschen (über die ssh-Konsole oder über die QNAP-Container-Station). Der Docker-Compose baut ja alles wieder auf.


    Viel Erfolg
    xgadscu


    PS: Ich habe meine Konfiguration übrigens schon vor 2 Wochen erweitert um 3 weitere Container:

    • redis
    • cron
    • collabora

    Soeben habe ich ganz einfach die Versionen auf den neuesten Stand gebracht. Einfach Build and Run erneut ausführen und Schwupp, alles ist frisch :)

    Hallo xgadscu,


    erst einmal vielen Dank für Deine Mühe. Die aktuellste Nextcloud damit auf dem QNAP via Docker zu starten war kein Problem. Auch wenn, wie in einigen Foren diskutiert, die maxinale Upload Filesize von 10G ein Sicherheitsproblem darstellen kann und besser für jeden Virtual Host einzeln konfiguriert wird und nicht direkt generell am Proxy. Hierzu habe ich nur wenige Informationen gefunden; frickel aber mal fröhlich weiter daran herum...


    Jetzt aber zu meiner eigentlichen Frage:


    Wie hast Du Collabora zusammen mit Deiner Kombination Netxcloud-Nginx-Proxy-Lets-Encrypt-Kombo konfiguriert ?


    Wenn ich den Collabora Container in das proxy-tier Netzwerk einhänge, sehe ich im log, daß das Lets Encrypt Zertifikat korrekt erstellt wird, erhalte dann aber einen 502 Bad Gateway. Die Kommunikation der einzelnen Container untereinander sollte doch funktionieren ... ?


    Für ein paar Tips wäre ich Dir sehr dankbar. Vielleicht kannst Du ja Deine docker-compose.yml hier mal posten für Collabora ?


    Viele Grüße,


    coyotekarl

    Hallo coyotekarl,


    im Anhang findest Du meine neutralisierten Konfigurationsdateien für die Kombi:


    8 Docker-Container auf einem QNAP hinter einem Internet-Router

    • Nginx-Reverse-Proxy
    • Lets-Encrypt-Companion
    • Web-Server
    • nextcloud
    • Maria-DB
    • redis
    • cron
    • collabora

    Neu hinzugekommen ist eine Subdomain für collabora. Ich habe sie mal office.example.com getauft. Du musst diesen Namen in allen Konfigurationsdateien und einmal als Dateiname auf die von Dir erstellte SubDomain umbenennen.


    Wenn alles angepasst ist, heißt es wieder: Build and Run


    Danach muss in der Cloud zunächst Collabora als App aktiviert werden. Dann erscheint unter den Einstellungen ein Menüpunkt "Collabora Online". Hier muss man dann den Collabora Online Server einstellen, d.h. nach meiner Anleitungs-Nomenklatur wäre das https://office.example.com.


    Viel Erfolg. Schön wäre auch eine Rückmeldung hier im Forum, ob alles geklappt hat.


    xgadscu

    Vielen herzlichen Dank für die Anleitung und das Bereitstellen der Konfigurationsdateien! In allen vorherigen Anläufen ist es mir als absoluter Nichtswisser in Bezug auf Container/Docker und SSH nie gelungen, eine Nextcloud auf dem eigenen QNAP zu installieren. Nachdem ich den ersten Schreck über die SSH-Konsolenbefehle überwunden hatte, habe ich mich heute dran getraut und hatte nach einigen Fehlern meinerseits (wie krieg ich die Ports im QNAP frei, wie lege ich überhaupt eine DynDNS mit der eigenen Domain an usw.) nach einer Stunde ein funktionierendes Nextcloud. Einzig den Collabora Container kriege ich nicht gestartet und habe da scheinbar in der Anpassung der configs oder dem erstellen der Subdomain einen Fehler gemacht. Wenn da noch jemand Rat weiß und das letzte Puzzleteil sich fügen sollte, wäre ich entzückt ;).


    Hallo xgadscu,


    vielen Dank für Deine Hilfe. Ich hatte Collabora dann auch nach langem "basteln" dazu bewegen können die Dienste vernünftig bereit zu stellen. Mein Fehler war, dass ich in domain = ... nicht die nextcloud-Domäne eingetragen hatte; dies war mir aus der Doku zu Collabora nicht ganz klar geworden. Somit endete mein Bemühen immer in : "Unautorisierter WOPI-Host". Nach korrektem Eintragen musste ich alle Container einmal neu starten. Macht man dies nicht erhält man bei Office-konformen Files die Fehlermeldung: "Unbekannter Dateityp".


    Was ich noch gerne hätte für kleinere Teams ist Mattermost. Werde das in den nächsten Tagen mal testen.


    VG


    coyotekarl

    Hallo HerrJott,


    ich hatte wohl zwischendurch auch mal solche Meldungen. Es gibt dazu eine Diskussion im nextcloud-Forum: https://help.nextcloud.com/t/r…-child-processes/12209/25


    Am Ende heißt es, man solle nach einem Update in den Collabora-Online-Einstellungen unter nextcloud noch einmal den Apply/Anwenden-Button drücken. Das würde ich an Deiner Stelle mal versuchen und ggfs. den Container restarten.


    Viele Grüße
    xgadscu

    Hallo xgadscu, ich habe gerade Deine Anleitung vom 20.05.18 umgesetzt. Hat super funktioniert - Danke für die Anleitung!!!


    Mir sind ein paar Sachen aufgefallen:

    - Nach der Installation kann ich die https Verbindung nur verwenden, wenn ich die Port Freischaltung der Fritz box offen lasse. Es wäre toll, wenn es
    eine Möglichkeit gäbe, über https lokal zu arbeiten. Was muss hierzu geändert werden?
    Ohne https geht es nicht, da ich carddav und caldav mit iOS verwenden möchte.


    - Ich habe auch Let's encrypt verwendet, um eine Zertifikat für mein NAS zu generieren. Hier habe ich die gleiche Situation, dass der https Port offen bleiben
    muß. Gleiche Frage wie oben.
    Über das NAS habe ich die files : SSLprivatekey.key, SSLcertificate.crt und SSLIntermediateCertificate.crt bekommen.


    - Über Deine Installation sind ca. ein Dutzend files unter nginx-certs angelegt worden.

    Da ich nicht der Fachmann für Zertifikate bin, aber schon gerne verstehen würde, welches file wofür ist, wäre eine Beschreibung (link) hilfreich.


    - Die Ports vom Nas (80, 443) würde ich gerne wieder auf die Originalwerte zurückstellen.
    Ich hatte oben bei Dir gelesen, dass es hier wohl Probleme mit dem Mappging gibt (Zertifikat-Erstellung).
    Aber spätestens, wenn man die 2te App (z.B. gitlab) installiern möchte, muß man eine Lösung finden, da es sonst mit nextcloud kollidieren würde.
    Hast Du hier schon eine Lösung?


    Vielen Dank und viele Grüße
    boeth

    Hallo boeth,


    schön, dass die Anleitung auch bei Dir funktioniert hat.


    Zu Deinen ersten 3 Fragen: Gegenstand dieser Anleitung ist, dass man eine von außen erreichbare private Cloud bekommt, mit der man sicher kommunizieren kann. Mit LetsEncrypt werden die erforderlichen Zertifikate automatisch erzeugt und turnusmäßig aktualisiert. Wenn Du rein im Heimnetz per https kommunizieren möchtest, muss Du nach anderen Lösungen suchen. Da bin ich außen vor.

    Bzgl. der Dateien in nginx-certs muss Du wohl mal die Suchmaschinen bemühen. Da gibt es schon genügend Antworten.

    Zur letzten Frage: Die unbedingte Nutzung des Ports 443 ist wie in der Anleitung beschrieben leider (noch) eine Restriktion von LetsEncrypt. Entsprechende Anfragen wurden meines Wissens nach bislang nicht umgesetzt. Das kann sich natürlich ändern. Bis dahin benutzt LetsEncrypt den Port 443 für die Validierung der Sub-Domain per ACME-Protokoll und das auch bei der Aktualisierung der Zertifikate.


    Die Sicherheit der eigenen Cloud kann man übrigens über https://scan.nextcloud.com testen.


    mfG
    xgadscu

    Hallo xgadscu,


    Danke für die schnelle Antwort. Den Scan hatte ich auch schon gefunden und er war A+. Überlege, ob ich die Ports dann doch offen lasse.
    Ist auf jeden Fall eine sehr gute Lösung, die du gefunden hast. Klappt top.

    Einzig, wenn meine lokale ip sich ändert, dauert es bis das Update über DNS kommt. Nutze den Eintrag myFritz!-Konto, der auch eine eindeutig URL liefert.
    Hast Du auch diese Verzögerung?

    Sync über calDav macOS klappt - update in beide Richtungen in Sekunden. Beim Update über cardDav kommt es nicht in Contacts an. Da muß
    ich auch noch mal schauen.


    gitlab müsste ich dann zum package hinzfügen. Müßt ich mir mal anschauen. Könnte ja mit auf nginx laufen.


    Das mit den Zertifikaten intressiert mich, da ich dann diese auch für die lokale Entwicklung verwenden könnte. Ohne Zertifikat geht so gut
    wie nix mehr. Werde mal schauen, welches ein Apache davon gebrauchen kann.


    Vielen Dank nochmal

    boeth

    Hallo xgadscu,

    danke für deine Antwort. Nachdem ich noch einen anderen Fehler in meiner Konfiguration gefunden hatte (schon beim Erstellen des Container-Moduls) hab ich heute noch einmal von vorne angefangen. Geht ja schnell, dachte ich. Nun hab ich alle cloud.example.com in meine URL wolke.meineurl.de umbenannt und die Passwörter geändert. Verstehe ich dich aber richtig, dass eine zweite Subdomain nötig ist, also bei mir dann z.B. office.meineurl.de oder muss dein office.example.com dann ebenfalls durch meine eine URL wolke.meineurl.de ersetzt werden? Egal was ich zuletzt probiert habe führt zu einem Fehler beim Vorbereiten der Docker-Container:


    Code
    Building proxy
Step 1/3 : FROM jwilder/nginx-proxy:alpine
alpine: Pulling from jwilder/nginx-proxy
Digest: sha256:4db4ecb7fbac270898d2dcb245c374be424c48827c52d8544677dbf3dfbea35f
Status: Image is up to date for jwilder/nginx-proxy:alpine ---> db9682e825f5
Step 2/3 : COPY uploadsize.conf /etc/nginx/conf.d/uploadsize.conf ---> Using cache ---> 8ea31928d3a6
Step 3/3 : COPY office.example.com /etc/nginx/vhost.d/office.example.com
ERROR: Service 'proxy' failed to build: COPY failed: stat /share/CACHEDEV1_DATA/Container/container-station-data/lib/docker/tmp/docker-builder328448459/office.example.com: no such file or directory


    Die cloud.example.com Datei habe ich umbenannt. Wenn ich es bei cloud.example.com belasse bekomme ich den Proxy nicht richtig konfiguriert und später einen 502 Gateway Fehler.

    Kannst du da noch einmal unterstützen und mir eine Idee geben? Danach würde ich das Einbinden von Collabora noch einmal so ausprobieren, wie von dir geschrieben,


    Dirk

    Hallo Dirk,


    man braucht eine zusätzliche SubDomain. Ich habe geschrieben:

    Zitat

    Neu hinzugekommen ist eine Subdomain für collabora. Ich habe sie mal office.example.com getauft. Du musst diesen Namen in allen Konfigurationsdateien und einmal als Dateiname auf die von Dir erstellte SubDomain umbenennen.

    Das meinte ich auch so. Die Betonung liegt auf "allen". Das heißt insbesondere, dass der Copy-Step im proxy/Dockerfile angepasst werden muss. In deinem Fall wird natürlich proxy/office.example.com nicht gefunden.


    Gruß xgadscu

    Tipp: WebDAV-Zugriff über das lokale Netz


    Normalerweise kann man bei obiger Konfiguration über die URL


    https://cloud.example.de/remote.php/dav/files/<<user>>


    per WebDAV auf die Nextcloud zugreifen.


    Wenn man sich im internen Netz befindet, geht das aber viel schneller über


    http://xxx.xxx.xxx.xxx:4080/remote.php/dav/files/<<user>>


    Hierbei ist xxx.xxx.xxx.xxx durch die lokale IP-Adresse des QNAP-Systems und <<user>> durch den nextcloud-Benutzer zu ersetzen.

    Hierfür hatte ich in der web-Section des docker-compose.yml-Files den Port 4080 externalisiert.


    Gruß xgadscu

    Das Dockerfile hatte ich übersehen. Jetzt hat die Installation natürlich geklappt, nachdem ich auch in proxy/Dockerfile die zwei Veränderungen vorgenommen hatte. Danke für den Hinweis. Collabora zickt zwar immer noch rum und gibt mir den internen Serverfehler, aber da nehme ich mir später noch einmal Zeit, den Fehler zu finden. In den Einstellungen "Anwenden" zu klicken reicht bei mir scheinbar nicht aus. Danke aber dennoch für deine Mühe und das Bereitstellen der Daten!

    Hi,

    danke für die Anleitung. Wie kann ich eigentlich auf nextcloud über https zugreifen.
    Da steht diese Warnung, dass dies nicht konfiguriert ist.

    Danke

    Ich mühe mich seit einigen -zig Stunden etwas zum Laufen zu bekommen und scheitere immer wieder. Vielleicht kann mir jemand auf die Sprünge helfen.


    HW: TS-443Be (ab jetzt 'Gerät' genannt), 1x 300GB Test-Disk (sonst 2x8 TB RAID1), 8 GB Speicher

    FW: 4.3.4.0597


    Zunächst ist da ein kleines Problem, dass der file CACHEDEV1_DATA gar nicht vorhanden ist, wenn ein Laufwerk verschlüsselt ist. Statt dessen gibt es den file CE_CACHEDAEV1_DATA und bei der Erstellung der Freigabeordner landen diese dort. Das ist aber wohl nicht das Hauptproblem und ich möchte das auch erst zurückstellen.


    In meiner Fritzbox habe ich in der Portfreigabe für das Gerät die ports http mit 80 und https mit 443 freigegeben.

    Es existiert eine subdomain <MeinName>.goip.de. Ein ping darauf zeigt die vom Internet Provider vergebene externe IPv4-Adresse meiner Fritzbox an.


    Ich habe also das Gerät mit einer disk ganz neu und ohne Verschlüsselung aufgesetzt. Dann die Container-Station installiert und gestartet. Ferner habe ich im Geräte-ControlCenter | Allgemeine Einstellungen den "Sicheren Anschluss (HTTPS) aktivieren" deaktiviert und damit sollte der port 443 wohl frei sein. Den port 80 habe ich überall gesucht, konnte aber dafür keine Einstellung im Gerät finden.


    Die files in "db.env" und "docker-compose.yml" habe ich entsprechend angepasst. Das password für mariaDB ist wohl klar, Im file "docker-compose" habe ich an der Stelle "- cloud.example.com >" "<MeinName>.goip.de" eingetragen und bei "-<<name>>@example.com >" meine normale email Adresse. Ich hoffe, dass das soweit richtig ist.


    Der Lauf von "docker-compose build --pull" ist auch o.k., der Lauf von "docker-composer up -d" endet mit den Fehlern:

    Code
    ERROR: for nextcloud_proxy_1 Cannot start service proxy: driver failed programming external connectivity on endpoint nextcloud_proxy_1 (1d8d59516f52e48209d94832dc1d0b7319e302fc47e080e9df310e1523e2a188): Error starting userland proxy: listen tcp 0.0.0.0:80: listen: address already in use

ERROR: for proxy Cannot start service proxy: driver failed programming external connectivity on endpoint nextcloud_proxy_1 (1d8d59516f52e48209d94832dc1d0b7319e302fc47e080e9df310e1523e2a188): Error starting userland proxy: listen tcp 0.0.0.0:80: listen: address already in use

ERROR: Encountered errors while bringing up the project.

[/share/CACHEDEV1_DATA/Docker-Configs/nextcloud] #

[/share/CACHEDEV1_DATA/Docker-Configs/nextcloud] #

    Ein Stoppen und neu Starten der 4 erstellten Container bringt auch nichts: Der Versuch den Container "nextcloud_proxy_1" neu zu starten schlägt fehl.


    Wie aus dem Fehlertext bei der der Erstellung ersichtlich, scheint etwas mit port 80 nicht zu stimmen. Wo kann ich da suchen und etwas ändern?

    Geschafft! Es war ein wenig schwierig den hhtp daemon zu finden, weil QNAP das auf Qthttpd.sh verbogen hat. Nachdem der gestoppt ist, lief alles einwandfrei durch.


    Danke an xgadscu.


    Gruß quasimodoz.

    Einmal editiert, zuletzt von quasimodoz ()

    Hallo quasimodoz,


    aus Deinem Log ist ersichtlich, dass der Port 80 bereits anderweitig verwendet wird. Da die Portweiterleitung auf der Fritzbox offensichtlich bei Port 80 keinen Konflikt gemeldet hatte, musste es das QNAP-System selbst sein. Der Port 80 ist dort standardmäßig beim Webserver eingestellt. Du hättest den Port also auch unter Systemsteuerung/Anwendungen/Webserver umstellen können. So hatte ich es auch gemacht. Das Script Qthttpd.sh brauchte nicht angepasst zu werden.


    Gruß xgadscu

    Einmal editiert, zuletzt von xgadscu () aus folgendem Grund: Bearbeitung der Anleitung leider nicht mehr möglich.

    Hallo xgadscu,


    Grrrrrrr. Den Haken bei "Systemsteuerung/Anwendungen/Webserver/Webserver aktivieren" zu entfernen hilft nicht, auch wenn der Port 80 dann ausgegraut ist (Auch reboot hilft da nicht). Was hilft, ist eine andere Portnummer einzugeben. Dann ist auch der Port 80 nicht mehr freigegeben


    Darauf muss man erst mal kommen!


    Aber vielen Dank für deine Hilfe.


    Gruß quasimodoz

    Komisch. Gestern hatte ich hier kurz beschrieben, wie man sich auch lokal einloggen kann - heute ist es weg. Also probiere ich es noch einmal.


    Das lokale Einloggen z.B. von Windows 10 und Firefox klappt einwandfrei, mit der URL https://locale_IP/login. Da dafür kein Zertifikat besteht, muss man noch die üblichen Bestätigungen abgeben, damit sich Firefox verbindet. Die eigene nextcloud-Seite wird dann angezeigt, allerdings mit einem geöffneten Sicherheitsschloss in der Adressleiste.


    Ich habe noch nicht sehr viel damit gearbeitet. Aber übliche Adminarbeiten wie das Anlegen eines Accounts, Passwortrichtlinienänderung etc. sind möglich.


    Eine kleine Änderung gibt es dennoch. Für die CalDav-Synchronisation muss die URL nicht https://locale_IP//remote.php/webdav/ sondern …/remote.php.dav/ lauten. Damit war bei mir eine Synchronisation von Kalender und Kontakten einwandfrei möglich.


    Gruss quasomodoz

    @xgadscu


    Hallo xgadscu,


    da du das Script im Finger hast, kannst du mir vielleicht mit der folgenden Frage helfen: WIe kann ich in diesem Umfeld occ, also die “ownCloud Console” aufrufen?


    Gruss quasimodoz


    Edit: Warum sind bei mir in der Menuleiste oben links nur die Felder "Nextcloud Symbol", "Dateien", "Aktivität" und "Galerie" zu sehen, alle anderen im Manual beschriebenen aber nicht, insbesondere kein Menupunkt um Apps zu installieren? Gibt es eine andere Möglichkeit z.B. shortcuts um Apps zu installieren?

    Einmal editiert, zuletzt von quasimodoz ()

    Hallo xgadscu,


    bekomme beim nextcloud file upload folgenden Fehler, wenn ich größere Files uploaden möchte (z.B. 7MB) : Request Entity Too Large


    Habe schon in der nginx.conf geschaut. Dort ist client_max_body_size 10G eingetragen.

    Habe ich auf der nextcloud Oberfläche auch so eingetragen.


    Wo muß noch ein Limit erhöht werden?


    Gruß
    boeth

    Einmal editiert, zuletzt von boeth () aus folgendem Grund: Sieht so aus als ob der COPY task überschrieben wird. Workaround: Nach dem Start der Container cp client_max_body_size config Datei in das nginx-conf.d Verzeichnis des Volumes als custom_proxy_setting.conf Gibt es eine bessere Lösung?