DecaTec

Home-Server | Linux | Nextcloud | Raspberry Pi | Programmierung | Fotografie

Nextcloud auf Ubuntu Server 20.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban

Nextcloud Logo

In diesem Artikel wird die Installation und Konfiguration von Nextcloud auf Ubuntu Server 20.04 LTS („Focal Fossa“) mit nginx, MariaDB, PHP und Let’s Encrypt beschrieben. Ebenfalls kommen Redis, Fail2ban und ufw zur Verbesserung der Sicherheit und Performance zum Einsatz.

Zum Thema Nextcloud auf Ubuntu Server gab es in diesem Blog bereits zahlreiche Artikel. Die letzte Anleitung Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban hat bereits ein ähnliches Setup beschrieben, basierte jedoch auf der Ubuntu-Version 18.04 LTS. Nach gut zwei Jahren ist nun eine neue LTS-Version von Ubuntu erschienen, so dass diese Artikel-Serie mit der neusten Version der Distribution fortgeführt wird.

Daneben bietet dieses Tutorial einen ganz neuen Ansatz: In vorherigen Artikeln zu diesem Thema wurde Nextcloud immer in einem Unterverzeichnis des Webservers installiert. Hier stieg allerdings die Nachfrage nach einem Setup, bei dem Nextcloud direkt im Root-Verzeichnis einer Domain installiert werden kann. Als positiver Nebeneffekt wird damit auch die Webserver-Konfiguration im einiges einfacher. Daher wird die eigene Cloud in diesem Artikel direkt im Web-Root der Domain installiert und nicht mehr in einem Unterverzeichnis.

Update-Historie (letztes Update: 24.08.2021)
  • 24.08.2021:
    • Nutzung von MariaDB 10.6.
    • MariaDB-Konfiguration: Schreibzugriff auf Tabellen im Compressed-Format zulassen (MariaDB 10.6).
  • 13.08.2021:
    • Anpassungen des virtuellen Hosts von nginx für Nextcloud.
  • 18.06.2021:
    • Konfiguration acme.sh, so dass immer Zertifikate über Let’s Encrypt bezogen werden.
  • 15.04.2021:
    • APCu für PHP/CLI aktiviert. Hier kann es sonst ab Nextcloud 21 zu Problemen führen.
  • 09.04.2021:
    • Installation von ImageMagick für Nextcloud 21 hinzugefügt.
  • 22.02.2021:
    • Anpassungen für Nextcloud 21 (config.php).
  • 30.01.2021:
    • Anpassung des vHost (nginx) für Nextcloud.
  • 04.01.2021:
    • MariaDB wird nun in der Version 10.5 verwendet.
  • 22.06.2020:
    • MariaDB wird nun in Version 10.4 verwendet.
    • Für MariaDB werden nun die Paketquellen von MariaDB eingebunden (Channel: „Stable“).
    • Das Paket php-bcmath wird von Nextcloud 19 vorausgesetzt, daher wird dieses nun bei der Installation von PHP berücksichtigt.
  • 14.05.2020:
    • FAQs: Anleitung zum Hosten weiterer Webanwendungen hinzugefügt.

Inhalt

Motivation, Voraussetzungen und Konzept

Dieser Artikel wird sicherlich wieder lang und umfangreich werden. Wie immer möchte ich hier kein „Copy & Paste Tutorial“ bereit stellen, in dem einfach nur eine Reihe von (Kommandozeilen-)Befehlen aufgeführt wird. Das hauptsächliche Ziel des Artikels ist es daher wieder, Wissen zu vermitteln: Dem Leser soll ein solides Grundlagenwissen vermittelt werden, so dass er sich zu jeder Zeit bewusst ist, warum die Dinge wie hier im Artikel skizziert umgesetzt wurden. Das Wissen um Zusammenhänge und Hintergründe ist ebenfalls bei auftretenden Problemen sehr wichtig. Denn wer eine eigene Cloud betreibt (und hier evtl. noch eigene Anforderungen umsetzen möchte), der wird froh sein, wenn auftretende Probleme eigenständig analysiert und gelöst werden können.

Ziele

Mit diesem Tutorial werden konkret folgende Ziele verfolgt:

  • Installation der eigenen Nextcloud auf Ubuntu Server 20.04 LTS mit nginx, MariaDB und PHP (LEMP-Stack).
  • Erhöhte Sicherheit der Cloud (PHP-Konfiguration, SSL, Nextcloud-Konfiguration laut Nextcloud Administation Manual).
  • Verschlüsselte Verbindung zur eigenen Cloud mittels HTTPS. Dazu kommt ein Zertifikat von Let’s Encrypt zum Einsatz (ECDSA- und RSA-Zertifikate im Hybrid-Betrieb mit TLSv1.3).
  • Nextcloud soll in einem Root-Verzeichnis des Webservers laufen und direkt über die URL https://nextcloud.meinedomain.de erreichbar sein.
  • In der Admin-Oberfläche von Nextcloud sollen keine Warnungen angezeigt werden.
  • Das Datenverzeichnis von Nextcloud soll außerhalb des www-Verzeichnisses liegen.
  • Verbesserung der Performance durch Verwendung von Redis für das Transactional File Locking.
  • Absicherung gegen Brute-Force-Attacken mit Fail2ban.
  • Einrichtung der Firewall ufw.

Zeitaufwand und Programm-Versionen

Zeitaufwand: ca. 3 Stunden

Eingesetzte Programm-Versionen:

  • Ubuntu Server 20.04 LTS („Focal Fossa“)
  • Nextcloud 18.0.3
  • nginx 1.17
  • MariaDB 10.6
  • PHP 7.4
  • Redis 5.0.7
  • Fail2ban 0.11.1
  • OpenSSL 1.1.1f

Änderungen gegenüber älteren Nextcloud-Artikeln

In diesem Blog gab es bereits einige Artikel zur Installation von Nextcloud auf Ubuntu Server. Im aktuellen Tutorial gibt es nun allerdings einige Änderungen, die das gesamte Setup betreffen – natürlich abgesehen, dass eine neue Verison von Ubuntu Server zum Einsatz kommt.

Folgende Punkte wurden nun im Vergleich zu den vorherigen Nextcloud-Artikeln geändert:

  • Nextcloud wird nun nicht mehr in einem Unterverzeichnis, sondern direkt im Root-Verzeichnis von nginx installiert:
    Dies macht die komplette Webserver-Konfiguration wesentlich einfacher, da kein Gateway-Host mehr benötigt wird, der alle Requests entgegen nehmen und weiterleiten muss. Dies verhindert allerdings nicht die Installation weiterer Webanwendungen. Diese benötigen im hier gezeigten Setup jedoch jeweils eigene (Sub-)Domains.
  • Verzicht auf die Konfiguration von open_basedir.
    Mittels open_basedir kann in einer PHP-Umgebung der Zugriff von PHP auf bestimmte Verzeichnisse beschränkt werden. In der Praxis sorgte diese Einschränkung doch immer wieder für Fehler/Probleme. Da dieses Thema in der heutigen Zeit nicht mehr so relevant für die Sicherheit ist, wird die Konfiguration von open_basedir nun ausgelassen.
  • Die Generierung der HTTPS-Zertifikate setzt nun konsequent auf acme.sh mit TLSv1.2 und TLSv1.3 im Hybrid-Betrieb (RSA- und ECDSA-Zertifikate parallel).
    Die älteren Artikel hatten dieses Konzept nicht so konsequent umgesetzt, so dass man die Informationen zu dem Thema ggf. aus weiteren Artikeln zusammen suchen musste. Das Vorgehen dazu wird nun hier direkt im Arikel ausführlich behandelt.

Neben diesen offensichtlichen Änderungen sind aber ebenfalls noch viele kleine Verbesserungen in diesen Artikel eingeflossen.

Voraussetzungen

Betriebssystem und Hardware

Als Betriebssystem kommt Ubuntu Server 20.04 LTS („Focal Fossa“) zum Einsatz. Generell ist hier der Einsatz einer LTS-Version (Long Term Support) zu empfehlen, da durch den verlängerten Support-Zeitraum (in diesem Fall fünf Jahre – bis April 2025) ein solches System über eine lange Zeit betrieben werden kann, ohne dass ein Distributions-Update zwingend erforderlich ist.

Das Betriebssystem sollte bereits installiert sein. Eine genaue Anleitung der Betriebssystem-Installation würde sicherlich den Rahmen des Artikels sprengen.

Alle gezeigten Schritte können allerdings auch mit anderen Linux-Distributionen (z.B Debian) umgesetzt werden. Evtl. sind hier dann kleinere Anpassungen an einigen wenigen Schritten notwendig.

Als Hardware braucht man prinzipiell nur eine Maschine, auf der Linux läuft. Wenn die Anforderungen nicht besonders hoch sind, kann das Tutorial auch auf einem Kleinstrechner wie dem  Raspberry Pi (Affiliate-Link) umgesetzt werden. Wird mehr Leistung benötigt, bietet sich z.B. auch eine Intel NUC (Affiliate Link) an. Die Cloud muss allerdings auch nicht zwingend in den eigenen vier Wänden betrieben werden: Wer einen eigenen Root-Server gemietet hat, kann sich ebenfalls an diesem Artikel orientieren.

Zugriff Per SSH

Ein Server läuft normalerweise „headless“, d.h. ohne angeschlossenen Monitor, Maus und Tastatur. Der Zugriff findet dann in der Regel über SSH statt. Daher sollte man im Rahmen des Ubuntu-Setups gleich einen SSH-Server mit installieren.

Domain und DynDNS/feste IP

Die eigene Cloud soll später ja auch aus dem Internet aus erreichbar sein. Daher ist zunächst eine Domain erforderlich. Im Rahmen des Artikels nutze ich die beispielhafte (Sub-)Domain nextcloud.meinedomain.de.

Diese Domain muss zunächst auf den eigenen Internet-Anschluss verweisen. Wer einen Anschluss mit fester IP hat (meistens Business-Anschlüsse), tut sich hier sehr leicht. In diesem Fall reicht es aus, den A-Record (IPv4) und AAAA-Record (IPv6) von der Domain auf die IPs des Anschlusses zu setzen. Dies wird normalerweise in den Einstellungen beim Domain-Provider erledigt.

Wenn keine feste IP-Adresse vorhanden ist – was bei den meisten privaten Internet-Anschlüssen der Fall ist – muss man auf DynDNS  setzen. Dies sorgt dafür, dass die (öffentliche) IP des Servers/Routers immer auf eine DynDNS-Domain gemappt wird. Dies ist notwendig, da die meisten Provider nach der 24-stündigen Zwangstrennung dem Kunden einen neue IP-Adresse zuweisen.
Ebenfalls benötigt man schon für die Erzeugung der SSL-Zertifikate zwingend eine Domain, da Zertifikate nicht auf IP-Adressen ausgestellt werden können.

Hierzu benötigt man einen sog. DynDNS-Dienst. Hier gibt es zahlreiche kostenlose Anbieter. Ein paar empfehlenswerte Dienste wären dabei:

Trotzdem kann es – gerade bei kostenlosen Diensten – immer mal wieder zu Problemen kommen. Eine meist bessere Alternative ist daher der Einsatz eines bezahlten Angebots, welches dann meistens zuverlässiger ist. Dazu bieten viele Webhoster auch DynDNS-Dienste an. Empfehlen kann ich hier den Hoster All-Inkl.com (Affiliate Link): Hier ist ein DynDNS-Dienst bereits im Webhosting-Paket „Privat Plus“ enthalten.

Im Router muss dann diese DynDNS-Domain noch konfiguriert werden, damit sich dieser korrekt am DynDNS-Dienst anmeldet. Erst nach diesem Schritt ist das eigene Netzwerk per DynDNS-Domain erreichbar. Das Vorgehen zum konfigurieren vom DynDNS hängt vom verwendeten Router-Modell, aber auch vom DynDNS-Dienst ab. Eine Informationsquelle sind hier die Hersteller-Seiten des Routers (z.B. AVM), aber auch die Websites der jeweiligen DynDNS-Dienste (z.B. ddnss.de) bieten meistens Hinweise zu verschiedenen Router-Modellen.

Port-Forwarding

Damit der (lokale) Webserver später auch aus dem Internet erreichbar ist, muss ein sog. Port-Forwarding im Router für die Ports 80 (HTTP) und 443 (HTTPS) für die IP-Adresse des Servers (in diesem Beispiel: 192.168.178.60) konfiguriert werden. Da sich das Vorgehen dazu wieder von Router zu Router unterscheidet, kann hier ebenfalls keine konkrete Anleitung erfolgen. Oftmals beschreiben die Hersteller das genaue Vorgehen auf ihren Internet-Seiten. Beispielsweise findet man die Vorgehensweise für die Einrichtung von Port-Forwardings für eine FritzBox auf den Hilfeseiten vom AVM.

Internet-Anschluss

Der Internet-Anschluss muss auch gewisse Voraussetzungen erfüllen. Hierbei darf es sich nicht um einen Dual-Stack Lite (DS-Lite) Anschluss handeln. Dies ist eine Technik, bei der der Endkunde keine „echte“ IPv4 Adresse bekommt, sondern nur eine IPv6-Adresse. Verbindungen die über IPv4 laufen, werden dann über IPv6 getunnelt. Leider setzen durch die gegebene Knappheit an IPv4-Adressen immer mehr Provider auf DS-Lite.

Mit einem DS-Lite-Anschluss ist der Betrieb eines selbstgehosteten Webdienstes leider nicht direkt möglich.

Daher wird zum Hosten einer eigenen Nextcloud zwingend ein „echter“ IPv4-Anschluss benötigt. Mit einem DS-Lite-Anschluss ist es nicht möglich, mit der hier gezeigten Vorgehensweise eine eigene Cloud aufzusetzen.

Wer doch nur einen DS-Lite-Anschluss hat, kann evtl. eine Zusatz-Option für einen echten IPv4-Anschluss beim Provider dazu buchen. Falls der Provider eine solche Option nicht direkt anbietet, kann es oftmals auch helfen, beim Provider anzurufen und nach einer solchen Option zu fragen, die dann evtl. manuell gebucht werden kann.

Falls dies nicht möglich ist, kann man nur einen Umweg über einen sog. Portmapper gehen. Diese Lösung ist allerdings sehr aufwendig und verursacht zusätzliche Kosten.

Root-Rechte

Für die Installation und die Konfiguration der benötigten Programmen sind unter Linux meist Root-Rechte erforderlich. Unter Ubuntu kann jeder Befehl durch das Voranstellen von „sudo“ mit Root-Rechten ausgeführt werden. Damit dieses „sudo“ nicht immer mit angegeben werden muss, ist es für die Installation empfehlenswert, sich am Anfang der Installation/Konfiguration einmalig Root-Rechte mit dem Befehl sudo -s zu verschaffen.

Konzept

Der folgende Abschnitt erklärt das Konzept, welches diesem Tutorial zugrunde liegt.

LEMP-Stack

Wer sich im Bereich Webhosting ein wenig auskennt, hat sicher schon mal etwas vom sog. LAMP-Stack gehört. Darunter versteht man eine Reihe an Programmen, die oftmals zusammen eingesetzt werden, wenn es um das Hosten dynamischer Webseiten geht: Linux (Betriebssystem), Apache (Webserver), MySQL (Datenbank) und PHP (Skriptsprache). Setzt man die Anfangsbuchstaben dieser Programme zusammen, versteht man, warum dies als LAMP-Stack bezeichnet wird.

Ich setze im Rahmen des Artikels jedoch auf einen sog. LEMP-Stack: Dies eine eine weitere Variante dieses Software-Pakets, bei der zunächst ebenfalls Linux als Grundlage zum Einsatz kommt. Allerdings nutzt man nun keinen Apache, sondern nginx als Webserver. Ebenso setze ich auf MariaDB als Datenbanksystem (statt MySQL). Was gleich bleibt ist der Einsatz von PHP. Die Bezeichnung LEMP-Stack ergibt sich wieder aus dem Anfangsbuchstaben der Programme (das „E“ kommt von der Aussprache von nginx: „Engine-X“).

Warum nutze ich nun abweichend vom Standard einen anderen Webserver und ein anderes Datenbanksystem? Dies bringt meiner Meinung nach folgende Vorteile:

  • Der Webserver nginx ist im Allgemeinen etwas ressourcenschonende als Apache. Letzterer erstellt pro (Client-)Verbindung neue Threads bzw. Prozesse, über die die einzelnen Webrequest abgearbeitet werden. Die Erzeugung neuer Threads/Prozesse ist allerdings teuer, da vergleichsweise viel Rechenleistung benötigt wird.
    nginx dagegen arbeitet mit einem sog. Thread-Pool: Hier werden beim Start des Webservers bereits mehrere Threads angelegt. Diese arbeiten dann die Webrequests ab, können aber im weiteren Verlauf wieder verwendet werden. Dies benötigt im Allgemeinen nicht so viele Ressourcen.
    Darüber hinaus finde ich die Konfiguration von nginx einfacher als die von Apache. Dies ist allerdings meine persönliche Meinung und mit Sicherheit Geschmackssache.
  • Das Datenbanksystem MariaDB ging aus einem Fork von MySQL hervor und ist zu diesem binärkompatibel. MariaDB ist daher ein sog. Drop-In-Replacement für MySQL (sozusagen ein 1:1 Ersatz). Deshalb spielt es für eine Anwendung keine Rolle, ob das dahinter liegende Datenbanksystem nun MySQL oder MariaDB ist. Ebenfalls sind alle Tools und Programme, die für MySQL entwickelt wurde auch automatisch mit MariaDB kompatibel.
    Für unser Vorhaben spielt es daher keine große Rolle, ob nun MySQL oder MariaDB zum Einsatz kommt. Im Gegensatz zu MySQL steht hinter MariaDB jedoch kein großes Unternehmen (bei MySQL ist dies Oracle), sondern es handelt sich dabei um „echte“ Open-Source-Software. Das ist auch der Grund, warum mittlerweile viele Linux-Distributionen MariaDB als Standard-Datenbanksystem einsetzen.
    Da mir dieses System zukunftssicherer erscheint, nutze ich daher im Rahmen des Artikels MariaDB als Datenbanksystem.

Virtuelle Hosts und Konfigurations-Dateien von nginx

Bevor es losgeht, noch ein paar Anmerkungen zu den Konfigurationsdateien bei nginx. Der Webserver verwendet sog. virtuelle Hosts (vHosts). Dies sind zunächst einmal reine Textdateien, die die Konfiguration für genau eine Website oder Anwendung beschreibt. Folgende Dateien/Verzeichnisse sind dabei wichtig:

  • /etc/nginx/nginx.conf: Dies ist die globale Konfiguration von nginx. Hier werden alle globalen Einstellungen definiert, die für alle Websites gelten sollen.
  • /etc/nginx/conf.d: In diesem Verzeichnis erwartet nginx die virtuellen Hosts und lädt diese beim Start. vHosts müssen in diesem Verzeichnis liegen und mit der Dateiendung *.conf gespeichert werden. Andere Dateien, die nicht mit .conf enden, werden beim Start des Webservers ignoriert.
  • Andere Verzeichnisse/Includes: Neben dieses fest definierten Verzeichnissen können aber auch andere Konfigurations-Dateien zum Einsatz kommen. Diese können irgendwo gespeichert sein und in jeder nginx-Konfiguration/vHost eingebunden werden. Ich nutze für solche „Snippets“ immer das Verzeichnis /etc/nginx/snippets. Was es damit auf sich hat und wie die Dateien inkludiert werden, wird im weiteren Verlauf des Artikels deutlich.

Hinweis bei abweichender Verzeichnisstruktur bei nginx

Es kann vorkommen, dass je nach verwendeter nginx-Version die Verzeichnisstruktur etwas anders ist. Nach der Installation sollte daher schnell überprüft werden, wo der default-vHost zu finden ist. Wenn dieses das oben genannten Verzeichnis ist (/etc/nginx/conf.d), kann dieser hier Abschnitt übersprungen werden.

Wenn der default-vHost allerdings nicht in in diesem Verzeichnis zu finden ist, dann liegt dieser meist unter /etc/nginx/sites-enabled. In diesem Fall kommt eine alternative Verzeichnisstruktur bei nginx zum Einsatz. Hier werden die virtuellen Hosts dann folgendermaßen verarbeitet:

  • /etc/nginx/sites-available: In diesem Verzeichnis sind die verfügbaren virtuellen Hosts enthalten, d.h. vHosts, die beim Start von nginx nicht automatisch geladen werden. Die Dateiendung für vHosts ist hier egal und man lässt diese für gewöhnlich einfach weg.
  • /etc/nginx/sites-enabled: Hier sind die virtuellen Hosts gespeichert, die der Webserver beim Starten lädt, die „aktiven vHosts“.
  • Um einen virtuellen Host zu aktivieren, muss sich dieser also im Verzeichnis sites-enabled befinden. Um nun nicht zwei Dateien verwalten zu müssen (unter sites-available und sites-enabled), kann einfach eine symbolische Verknüpfung für einen virtuellen Host angelegt werden. Ein Beispiel: Wenn ein (deaktivierter) vHost /etc/nginx/sites–available/meinedomain.de aktiviert werden soll, dann wird mit folgendem Befehl eine entsprechende Verknüpfung angelegt:
ln -s /etc/nginx/sites-available/meinedomain.de /etc/nginx/sites-enabled/

Wenn diese alternative Verzeichnisstruktur bei nginx zum Einsatz kommt, dann ist im weiteren Verlauf des Artikels darauf zu achten, die Dateien der virtuellen Hosts an der richtigen Stelle zu platzieren.

Installation und Konfiguration benötigter Programme

Genug der Vorrede, nun geht es an die Praxis!

Ubuntu Server 20.04 LTS ist bereits installiert? Gut.
Das System sollte dabei eine statische IP im LAN zugeteilt bekommen haben. Ich nutze im Folgenden die beispielhafte IP 192.168.178.60.

Update des Betriebssystems

Zunächst bringen wir das System auf den neusten Stand und starten den Server anschließend einmal neu:

apt update && apt upgrade -V && apt dist-upgrade && apt autoremove 
reboot now

An dieser Stelle sollte dann auch noch die Zeiteinstellung des Bestriebssystems überprüft werden:

date

Meistens ist die Zeit nach der Neuinstallation von Ubuntu auf UTC eingestellt, dies läst sich dann mit folgendem Befehl korrigieren:

timedatectl set-timezone Europe/Berlin

Programm-Installation

Bevor Nextcloud installiert werden kann, müssen zunächst einmal alle Programme installiert werden, die zum Betrieb der Cloud notwendig sind.

Exkurs: Ubuntu-Paketquellen und Hersteller-Paketquellen

Die meisten benötigten Programme sind bereits in den offiziellen Ubuntu-Paketquellen enthalten. Diese könnte man nun ohne Umwege direkt über apt installieren. Jedoch legt die Distribution Wert auf die Stabilität der Programme, die in den offiziellen Paketquellen enthalten sind. Leider sind diese Programm-Versionen oftmals ziemlich alt und erhalten keine größeren Updates mehr. Daher altert ein solches System recht schnell und man kann keine Features der Programme nutzen, die in neueren Versionen hinzugefügt werden.

Die Hersteller der Programme bieten darüber hinaus auch meistens eigene Paketquellen (Repositories) an. Die hier enthaltenen Versionen sind meistens wesentlich aktueller und werden auch zukünftig mit (Feature-)Updates versorgt. Oftmals unterscheiden die Hersteller dabei nochmals zwischen zwei (oder sogar mehr) Entwicklungs-Branches: Meist gibt es einen Stable-Branch, dessen Programm-Versionen möglichst stabil gehalten werden. Daher sind auch hier meistens keine größeren Updates mehr zu erwarten und neue Features werden erst nach z.T. langer Zeit in diesen Branch mit aufgenommen. Daneben gibt es meist noch einen Mainline-Branch, der zwar auch als stabil betrachtet werden kann, aber zeitnah mit Updates und neuen Features versorgt wird.

Daher muss man nun für sich selbst entscheiden, welche Programm-Versionen/Repositories zum Einsatz kommen:

  • Wenn Stabilität das absolut Wichtigste ist, dann sollten die offiziellen Ubuntu-Paketquellen verwendet werden.
  • Wenn man eine LTS-Version von Ubuntu gewählt hat, bleibt man oftmals sehr lange auf dieser einen Betriebssystem-Version. Hier ist Stabilität ein wichtiger Faktor. Wenn darüber hinaus trotzdem einigermaßen aktuelle Software eingesetzt werden soll, dann ist der Stable-Branch der Hersteller zu empfehlen.
  • Wer von neuen Features aktueller Programm-Versionen profitieren und die Programme auf einem möglichst aktuellen Stand halten möchte, sollte den Mainline-Branch der Software-Hersteller nutzen.

Meiner Erfahrung nach sind die Mainline-Branches der Hersteller allerdings ausreichend stabil, so dass auch der Einsatz in produktiven Umgebungen empfohlen werden kann. Daher nutze ich in diesem Artikel meist die Mainline-Branches aus den Paketquellen der Software-Hersteller.

Wer auf andere Versionen/Branches setzt, muss evtl. die im Artikel gezeigten Schritte geringfügig anpassen, da z.B. einige Programm-Features nicht verfügbar sind.

Hinweis für Raspberry Pi Benutzer: Oftmals verzichten die Software-Hersteller darauf, in ihren Paketquellen Programm-Versionen für die ARM-Architektur bereit zu stellen. In diesem Fall würde ein Hinzufügen der Hersteller-Repositories zu einem Fehler bei der Programm-Installation führen. In diesem Fall muss man auf die Paketquellen von Raspbian/Debian zurückgreifen und kann keine Hersteller-Repositories einbinden.

nginx

Zuerst wird der Webserver installiert. Da ich hier das Mainline-Repository von nginx verwende, muss diese Paketquelle zunächst auf dem System eingebunden werden.

Als erstes fügen wir den Key des Repositories hinzu, da es ansonsten später bei der Installation zu einer Fehlermeldung kommt:

wget -O - http://nginx.org/keys/nginx_signing.key | apt-key add -

Nun kann die Paketquelle selbst hinzugefügt werden. Dazu legen wir eine entsprechende Datei an:

nano /etc/apt/sources.list.d/nginx.list

Diese wird mit folgendem Inhalt gefüllt:

# Nginx (Mainline)
deb [arch=amd64] http://nginx.org/packages/mainline/ubuntu/ focal nginx
deb-src [arch=amd64] http://nginx.org/packages/mainline/ubuntu/ focal nginx

Die Installation des Webservers erfolgt nun über diesen Befehl:

apt update && apt install nginx

Direkt nach der Installation kann man die Funktionsweise des Webservers im Browser testen (einfach durch Aufruf der IP des Servers):

Der Webserver läuft
Der Webserver läuft

MariaDB

Weiter geht es mit dem Datenbanksystem. Wie schon bei nginx pflegt der Hersteller hier seine eigenen Repositories. Hier gibt es die beiden Branches „Stable“ und „Development“ – hier ist auf jeden Fall der „Stable“ Release vorzuziehen. Mehr Informationen zu den Releases von MariaDB gibt es in der MariaDB-Knowledgebase.

Wie schon bei nginx, muss erst einmal der Repository-Key auf dem System bekannt gemacht werden:

sudo apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc'

Die MariaDB-Paketquellen werden kann wieder in einer einzelnen Datei hinzugefügt:

nano /etc/apt/sources.list.d/MariaDB.list
# MariaDB 10.6 repository list
# http://downloads.mariadb.org/mariadb/repositories/
deb [arch=amd64] http://mirror.netcologne.de/mariadb/repo/10.6/ubuntu focal main
deb-src http://mirror.netcologne.de/mariadb/repo/10.6/ubuntu focal main

Die Installation von MariaDB wird dann mit folgendem Befehl durchgeführt:

apt update && apt install mariadb-server

PHP

Als nächstes werden die benötigten PHP-Pakete installiert:

apt install php-fpm php-gd php-mysql php-curl php-xml php-zip php-intl php-mbstring php-bz2 php-json php-apcu php-imagick php-gmp php-bcmath

Werden später weitere PHP-Pakete benötigt (z.B. für einige Nextcloud Apps), so können diese zu einem späteren Zeitpunkt nachinstalliert werden.

Installation weiterer Pakete

Ab Nextcloud 21 wird zusätzlich ImageMagick und ein zusätzliches Modul benötigt. Beides kann einfach über folgenden Befehl installiert werden:

apt install imagemagick libmagickcore-6.q16-6-extra

Let’s Encrypt/acme.sh

Zur Generierung der Zertifikate für HTTPS ist noch ein Let’s Encrypt Client notwendig. Ich empfehle hier den Client acme.sh, da es sich hierbei um ein reines Bash-Skript handelt. Auf diese Weise ist man nicht abhängig von einer „echten“ Programm-Installation, welche zu einem Problem werden kann, wenn die Version in den Paketquellen zu alt ist.

acme.sh sollte dabei nicht mit Root-Rechten (also auch ohne sudo) ausgeführt werden. Daher wird extra für acme.sh ein spezieller User angelegt:

adduser letsencrypt

Für diesen User muss kein Passwort vergeben werden (einfach leer lassen und so oft Enter drücken, bis die Frage erscheint, ob man es nochmal versuchen möchte, hier einfach „N“ wählen). Ebenso können die weiteren Angaben zum User (Name, E-Mail, etc.) weggelassen werden.

Dieser User wird dann noch der Gruppe www-data hinzugefügt:

usermod -a -G www-data letsencrypt

Der User letsencrypt braucht anschließend noch die Rechte, nginx ohne Eingabe eines Root-Passworts neu zu laden. Dies wird mit folgendem Befehl konfiguriert:

visudo

Ganz am Ende der Datei wird nun folgende Zeile hinzugefügt:

letsencrypt ALL=NOPASSWD: /bin/systemctl reload nginx.service

Nun kann auch schon acme.sh installiert werden. Dazu wechseln wir zunächst zum User letsencrypt:

su - letsencrypt

Die Installation wird dann mit folgendem Befehl gestartet:

curl https://get.acme.sh | sh

Nach einem kurzen Augenblick ist die Installation abgeschlossen und wir wechseln wieder zum normalen User:

exit

Konfiguration der Programme

Die Installation aller benötigten Programme ist nun abgeschlossen. Nun müssen diese allerdings noch konfiguriert werden, bevor die Nextcloud-Installation beginnen kann.

Konfiguration nginx

Hier bedarf es ein paar kleineren Anpassungen an der globalen nginx-Konfiguration:

nano /etc/nginx/nginx.conf

Hier sollten folgende Punkte angepasst/kontrolliert werden:

  • user: Gibt den Benutzer an, unter dem der Webserver läuft. Dies sollte immer www-data sein.
  • worker_processes: Die Anzahl der Threads, die nginx dazu verwendet, Client-Requests abzuarbeiten. Die optimale Einstellung ist hier auto, da nginx dann pro CPU-Kern einen Thread verwendet.
  • server_tokens: Mit der Angabe off sorgt man dafür, dass nginx keine Versions-Informationen preisgibt (z.B. auf Fehlerseiten). Wenn diese Variable nicht vorhanden ist, muss man diese im HTTP-Block der Datei einfügen: server_tokens off;

Nun deaktivieren wir gleich noch die Default-Seite von nginx, da dies sowieso nur eine Art Demo-Seite ist:

mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf_disabled 
service nginx restart

Am Schluss wird nginx noch neu gestartet, damit die Änderungen übernommen werden.

Konfiguration MariaDB

Bei der Datenbank muss nicht viel konfiguriert werden, allerdings sollte die Installation auf maximale Sicherheit getrimmt werden:

mysql_secure_installation

An dieser Stelle kann gleich ein Root-Passwort für MariaDB gesetzt werden. Alle weiteren Fragen des Assistenten sollten mit „Ja“ (y) beantwortet werden.

Bei MariaDB 10.6 muss zusätzlich noch der Schreibzugriff auf Tabellen im Compressed-Format zugelassen werden:

nano /etc/mysql/mariadb.conf.d/50-server.cnf

Im Block [mysqld] muss hier noch eine zusätzliche Option mit angegeben werden:

innodb_read_only_compressed=OFF

Damit die Änderung wirksam wird, muss MariaDB einmal neu gestartet werden:

service mariadb restart

Konfiguration PHP

Bei PHP muss einiges mehr konfiguriert werden, da sich die Einstellungen über mehrere Dateien verteilen.

PHP wird bei nginx über FPM (FastCGI Process Manager) betrieben. Dies ist eine performante Möglichkeit der Kommunikation zwischen PHP und dem Webserver. FPM definiert einen sog. Thread-Pool, der die Anfragen abarbeitet (ähnlich wie schon bei nginx). Die Konfiguration ist dazu in folgender Datei zu finden:

nano /etc/php/7.4/fpm/pool.d/www.conf

Folgende Anpassungen sollten hier durchgeführt/kontrolliert werden:

  • user/group: Benutzer unter dem PHP ausgeführt wird. Dies ist wieder der Webserver-User www-data:
    user = www-data
    group = www-data
  • listen: Die Kommunikation zwischen dem Webserver und PHP findet über einen sog. Socket ab. Der Pfad des Sockets wird hier angegeben:
    listen = /run/php/php7.4-fpm.sock
  • Umgebungs-Variablen: Umgebungs-Variablen werden von PHP in der Standard-Einstellung nicht veräußert. Für den Betrieb von Nextcloud ist dies jedoch erforderlich. Daher suchen wir nach Pass environment variables like LD_LIBRARY_PATH. ALL $VARIABLES are taken from the current environment (Shortcut für die Suche in nano: STRG + W). Alle Einträge, die mit env beginnen sind hier auskommentiert. Durch das Entfernen des Semikolons am Zeilenanfang wird die Weitergabe der Umgebungs-Variablen aktiviert:
    env[HOSTNAME] = $HOSTNAME
    env[PATH] = /usr/local/bin:/usr/bin:/bin
    env[TMP] = /tmp
    env[TMPDIR] = /tmp
    env[TEMP] = /tmp

Neben der Pool-Konfiguration gibt es noch zwei weitere Dateien, die allgemeine Einstellungen zu PHP beinhalten. Die erste ist die php.ini für FPM:

nano /etc/php/7.4/fpm/php.ini
  • cgi.fix_pathinfo: Sorgt für eine sichere Interpretation von Pfadangaben:
    cgi.fix_pathinfo = 0
  • memory_limit: Dieser Wert gibt an, wie viel Speicher ein PHP-Skript nutzen darf. Nextcloud benötigt mindestens 512 MB als Memory Limit:
    memory_limit = 512M
  • OPcache: PHP OPcache erhöht bessere Performance durch das Ablegen vorkompilierten Bytecodes in den Arbeitsspeicher. Diese Einträge dazu sollten in der php.ini bereits vorhanden sein (allerdings auskommentiert). Eine Suche in der Datei sollte einiges an Tipparbeit sparen. Folgende Werte sind hier anzugeben:
    opcache.enable = 1
    opcache.enable_cli = 1
    opcache.memory_consumption = 128
    opcache.interned_strings_buffer = 8
    opcache.max_accelerated_files = 10000
    opcache.revalidate_freq = 1
    opcache.save_comments = 1

Es gibt noch eine weitere Datei mit dem Namen php.ini. Diese enthält Einstellungen für PHP-CLI (PHP-Aufrufe direkt über die Kommandozeile):

nano /etc/php/7.4/cli/php.ini
  • cgi.fix_pathinfo: Wie oben beschrieben:
    cgi.fix_pathinfo = 0
  • apc.enable: Hier muss noch explizit APCu (Caching) aktiviert werden. Wenn diese Variable noch nicht in der php.ini vorhanden ist, wird folgende Zeile einfach am Ende der Datei angefügt:
    apc.enable_cli = 1

Nach einem Neustart von PHP werden alle Änderungen übernommen

service php7.4-fpm restart

Konfiguration Let’s Encrypt/acme.sh

Ich empfehle generell die Nutzung von Zertifikaten von Let’s Encrypt. acme.sh nutzt ab dem 01.08.2021 standardmäßig Zertifikate von ZeroSSL (siehe hier). Dieses Standard-Verhalten kann allerdings durch folgenden Befehl geändert werden.

Hier ist zunächst wieder das Wechseln auf den entsprechenden User notwendig:

su - letsencrypt

Nun wird acme.sh so konfiguriert, dass immer Zertifikate von Let’s Encrypt bezogen werden:

acme.sh --set-default-ca --server letsencrypt

Nun kann wieder auf dem normalen User gewechselt werden:

exit

Generierung der Zertifikate für HTTPS

Nachdem alle Vorbereitungen getroffen worden sind, kann es nun an die Generierung der HTTPS-Zertifikate gehen.

Vorbereiten der Verzeichnisstruktur

Zunächst legen wir ein paar Verzeichnisse an und weisen diesen die entsprechenden Rechte zu:

mkdir -p /var/www/letsencrypt/.well-known/acme-challenge
chown -R www-data:www-data /var/www/letsencrypt
chmod -R 775 /var/www/letsencrypt
mkdir -p /etc/letsencrypt/nextcloud.meinedomain.de/rsa
mkdir -p /etc/letsencrypt/nextcloud.meinedomain.de/ecc
chown -R www-data:www-data /etc/letsencrypt
chmod -R 775 /etc/letsencrypt

Das erste Verzeichnis (/var/www/letsencrypt/.well-known/acme-challenge) wird später vom Webserver bereit gestellt. Darüber kann Let’s Encrypt die Domain verifizieren.
Unter /etc/letsencrypt werden die eigentlichen Zertifikate gespeichert. Ich lege hier immer ein Unterverzeichnis pro Domain an. Darunter dann getrennte Verzeichnisse für RSA- und ECDSA-Zertifikate. Damit bleibt es auch übersichtlich, wenn später mehrere Domains durch den Webserver bereit gestellt werden sollen.

Wichtig ist hier noch die Zuweisung der Rechte (chmod -R 775), damit der User für Let’s Encrpyt auch die erforderlichen Schreinrechte hat (dieser ist Mitglied der Gruppe www-data).

Anlegen des ersten virtuellen Hosts (HTTP-Gateway)

Als nächsten braucht man nun den virtuellen Host, der für die Zertifikats-Generierung benötigt wird. Ich nenne diesen Host hier einfach „HTTP-Gateway“, da dieser die gesamte Kommunikation über HTTP (Port 80) behandelt. Auch wenn dieser zunächst einmal für nur eine Domain gilt, kann dieser später ebenfalls erweitert werden, wenn weitere Domains gehostet werden sollen.

nano /etc/nginx/conf.d/HttpGateway.conf

Folgender Inhalt wird hier eingefügt:

upstream php-handler {
    server unix:/run/php/php7.4-fpm.sock;
}

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name nextcloud.meinedomain.de 192.168.178.60;
 
    root /var/www;

    location ^~ /.well-known/acme-challenge {
        default_type text/plain;
        root /var/www/letsencrypt;
    }

	location / {
		return 301 https://$host$request_uri;
	}
}

Anzumerken sind hier noch folgende Dinge:

  • Ganz oben wird ein sog. Upstream für PHP definiert. Durch die Anlage im HTTP-Gateway ist dieser immer verfügbar (und wird später für Nextcloud benötigt).
  • Weiter unten sieht man, wie sämtlicher Traffic, der nichts mit der Generierung der HTTPS-Zertifikate zu tun hat, an HTTPS weitergeleitet wird. Dadurch findet immer eine „Zwangs-Umleitung“ auf HTTPS statt, damit sämtliche Verbindungen stets verschlüsselt sind. Nur für die Zertifikats-Generierung über Let’s Encrypt muss der Traffic unverschlüsselt über Port 80 (HTTP) erfolgen.

Damit die Änderungen übernommen werden, muss der Webserver noch neu gestartet werden.

service nginx restart

Überprüfung des Webserver vor der Zertifikats-Generierung

Bevor man sich nun an der Generierung der Zertifikate macht, sollte die korrekte Konfiguration des Webservers (und der DynDNS-Domain/des Port-Forwardings) erfolgen. Hintergrund ist eine Einschränkung von Let’s Encrypt: Wenn die Generierung fehlschlägt (z.B. weil der Webserver einfach nicht über die DynDNS-Domain erreichbar ist), ist man meistens gewillt, den Befehl zum Generieren der Zertifikate mehrfach hintereinander auszuprobieren. Irgendwann stößt man hier an ein „Rate Limit“, nachdem Let’s Encrypt die Zertifikats-Generierung für 7 Tage sperrt. In diesem Fall muss man mit der Installation der Cloud für eine Woche warten und dies sorgt meist für Frust.

Dazu legen wir eine einfache Text-Datei an der Stelle ab, an der Let’s Encrypt die Verifizierung der Domain vornimmt:

echo "Test" >> /var/www/letsencrypt/.well-known/acme-challenge/test.txt

Nun erfolgt ein einfacher Aufruf dieser Datei im Browser: http://nextcloud.meinedomain.de/.well-known/acme-challenge/test.txt. Wichtig ist hier die Angabe von HTTP (nicht HTTPS). Hier sollte dann der Inhalt der zuvor angelegten Datei angezeigt werden.

Test des Webservers vor der Generierung der Zertifikate
Test des Webservers vor der Generierung der Zertifikate

Am Schluss kann die Text-Datei wieder gelöscht werden:

rm /var/www/letsencrypt/.well-known/acme-challenge/test.txt

Wichtig: Die Generierung der Zertifikate sollte erst nach einem erfolgreichen Test durchgeführt werden.
Wenn der Test nicht erfolgreich ist (und die Datei nicht angezeigt wird), sollte ein Blick in das Log von nginx erfolgen (/var/log/nginx/error.log). Hier sollte ersichtlich werden, an welcher Stelle der die Datei test.txt (erfolglos) sucht. Wenn hier keine passenden Inhalte im Log zu finden sind, liegt das Problem vermutlich an der DynDNS-Domain bzw. dem Port-Forwarding, so dass der Request gar nicht am Webserver ankommt.

Generierung der Zertifikate

Nun können endlich die Zertifikate erzeugt werden. Dazu wechseln wir zunächst wieder auf den User letsencrypt:

su - letsencrypt

Nun werden zunächst die RSA-Zertifikate erzeugt:

acme.sh --issue -d nextcloud.meinedomain.de --server letsencrypt --keylength 4096 -w /var/www/letsencrypt --key-file /etc/letsencrypt/nextcloud.meinedomain.de/rsa/key.pem --ca-file /etc/letsencrypt/nextcloud.meinedomain.de/rsa/ca.pem --cert-file /etc/letsencrypt/nextcloud.meinedomain.de/rsa/cert.pem --fullchain-file /etc/letsencrypt/nextcloud.meinedomain.de/rsa/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"

Wenn dies erfolgreich war, können noch die ECDSA-Zertifikate generiert werden:

acme.sh --issue -d nextcloud.meinedomain.de --server letsencrypt --keylength ec-384 -w /var/www/letsencrypt --key-file /etc/letsencrypt/nextcloud.meinedomain.de/ecc/key.pem --ca-file /etc/letsencrypt/nextcloud.meinedomain.de/ecc/ca.pem --cert-file /etc/letsencrypt/nextcloud.meinedomain.de/ecc/cert.pem --fullchain-file /etc/letsencrypt/nextcloud.meinedomain.de/ecc/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"

An dieser Stelle wird nochmal mittels –server letsencrypt explizit angegeben, dass Zertifikate von Let’s Encrypt erzeigt werden sollen. Dies ist – sofern die Standard-Einstellung von acme.sh geändert wurde (s.o.) – eigentlich überflüssig, schadet an dieser Stelle allerdings auch nicht.

Im Anschluss findet man die Zertifikat-Dateien im Verzeichnis /etc/letsencrypt/nextcloud.meinedoamin.de/rsa bzw. /etc/letsencrypt/nextcloud.meinedoamin.de/ecc:

  • cert.pem: Das öffentliche Zertifikat in Reinform
  • ca.pem: Öffentliches Zertifikat aus der sog. Keychain
  • fullchain.pem: Entspricht cert.pem + chain.pem
  • key.pem: Privates Zertifikat (diese Datei sollte man daher niemals weitergeben)

Im Anschluss wechseln wir wieder auf den normalen User:

exit

Erneuerung der Zertifikate

Die Zertifikate von Let’s Encrypt haben eine Gültigkeit von 90 Tagen und müssen vor Ablauf dieses Zeitraums erneuert werden.

Um diese Erneuerung muss man sich allerdings nicht mehr kümmern, da im Rahmen der Zertifikats-Generierung für den User letsencrypt ein Cronjob eingerichtet wurde, der in regelmäßigen Abständen prüft, ob die Zertifikate bald ablaufen und diese ggf. automatisch erneuert.

Diffie-Hellman-Parameter

Die Sicherheit des Kommunikation mittels HTTPS kann noch durch den Einsatz sog. Diffie-Hellman-Parameter weiter erhöht werden. Mittels dieser Parameter kann einfach gesagt der Schlüsselaustausch beim Verbindungsaufbau weiter abgesichert werden. Da die Generierung eines dafür benötigten Schlüssels recht einfach ist, sollte dieser Schritt auf jeden Fall durchgeführt werden.

Achtung: Auf schwächerer Hardware – z.B. bei einem älteren Raspberry Pi – kann die Generierung des Schlüssels sehr lange dauern (bis zu einigen Stunden). Wer nicht so lange warten möchte, der kann auch einen Schlüssel mit „nur“ 2048 Bit errechnen lassen (die Zahl des zweiten Befehls gibt hierbei die Länge des Schlüssels in Bit an).

mkdir -p /etc/nginx/dhparams 
openssl dhparam -out /etc/nginx/dhparams/dhparams.pem 4096

Webserver für Nextcloud vorbereiten

Nachdem wir nun gültige Zertifikate haben, kann der Webserver für die Installation von Nextcloud vorbereitet werden.

SSL-Konfiguration

Die allgemeine Konfiguration für SSL lagere ich immer in eine spezielle Datei aus. Diese kann dann später einfach in einen vHost eingebunden werden. Durch diese Modularität bleibt man bei der Konfiguration der virtuellen Hosts flexibler. Beispielsweise kann diese allgemeine SSL-Konfiguration später auch in anderen vHosts eingebunden werden, wenn später mehrere Webanwendungen gehostet werden sollen.

Dazu legen wir zunächst ein Verzeichnis für solche Snippets an:

mkdir -p /etc/nginx/snippets

Nun wird eine Datei für die allgemeine SSL-Konfiguration angelegt:

nano /etc/nginx/snippets/ssl.conf

Der Inhalt dieser Datei sieht folgendermaßen aus:

#
# Configure SSL
#

# Diffie-Hellman parameter for DHE ciphersuites, recommended 4096 bits
ssl_dhparam /etc/nginx/dhparams/dhparams.pem;

# Not using TLSv1 will break:
# Android <= 4.4.40 IE <= 10 IE mobile <=10
# Removing TLSv1.1 breaks nothing else!
ssl_protocols TLSv1.2 TLSv1.3;

# SSL ciphers: RSA + ECDSA
# Two certificate types (ECDSA, RSA) are needed.
ssl_ciphers 'TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384';

# Use multiple curves.
ssl_ecdh_curve secp521r1:secp384r1;

# Server should determine the ciphers, not the client
ssl_prefer_server_ciphers on;

# SSL session handling
ssl_session_timeout 1d; 
ssl_session_cache shared:SSL:50m; 
ssl_session_tickets off;

# SSL stapling has to be done seperately, becuase it will not work with self signed certs
# OCSP Stapling fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

# DNS resolver
resolver 192.168.178.1;

Wichtig ist hier die Angabe des richtigen „Resolvers“: Dies ist der lokale DNS-Server, mittels dessen der Webserver Domain-Namen auflösen kann. In den meisten Fällen ist dies einfach die IP des Routers (in diesem Beispiel 192.168.178.1), der einen DNS-Server im lokalen Netzwerk bereit stellt. Alternativ kann hier ein beliebiger DNS-Server angegeben werden. Hier sollte man am besten nicht auf DNS-Server von Google oder Cloudflare setzen, sondern besser auf einen Server, der nicht protokolliert und nicht zensiert. Eine Liste mit empfehlenswerten Servern gibt es z.B. hier.

Header-Konfiguration

Bei jeder Webanwendung sollten vom Webserver gewisse Header gesetzt werden. Diese lagern wir wieder in eine spezielle Datei aus, damit diese später wieder in virtuelle Hosts eingebunden werden kann.

nano /etc/nginx/snippets/headers.conf

Diese Datei wird mit folgendem Inhalt gefüllt:

#
# Add headers to serve security related headers
#  
# HSTS (ngx_http_headers_module is required)
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload;" always; 
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Robots-Tag none always;
add_header X-Download-Options noopen always;
add_header X-Permitted-Cross-Domain-Policies none always;
add_header Referrer-Policy no-referrer always;
add_header X-Frame-Options "SAMEORIGIN" always;

# Remove X-Powered-By, which is an information leak
fastcgi_hide_header X-Powered-By;

Virtueller Host für Nextcloud

Nun setzen wir alle Puzzleteile zusammen und erstellen den vHost für Nextcloud selbst. Diesen benenne ich hier einfach nach dem verwendeten Domain-Namen:

nano /etc/nginx/conf.d/nextcloud.meinedomain.de.conf

Der Inhalt ist diesmal etwas umfangreicher:

server {
	listen 443 ssl http2;
	listen [::]:443 ssl http2;
	server_name nextcloud.meinedomain.de;

	# SSL configuration
	# RSA certificates
	ssl_certificate /etc/letsencrypt/nextcloud.meinedomain.de/rsa/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/nextcloud.meinedomain.de/rsa/key.pem;
	# ECC certificates
	ssl_certificate /etc/letsencrypt/nextcloud.meinedomain.de/ecc/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/nextcloud.meinedomain.de/ecc/key.pem;

	# This should be ca.pem (certificate with the additional intermediate certificate)
	# See here: https://certbot.eff.org/docs/using.html
	# ECC
	ssl_trusted_certificate /etc/letsencrypt/nextcloud.meinedomain.de/ecc/ca.pem;

	# Include SSL configuration
	include /etc/nginx/snippets/ssl.conf;

	# Include headers
	include /etc/nginx/snippets/headers.conf;

	# set max upload size
	client_max_body_size 10G;
	fastcgi_buffers 64 4K;

	# Enable gzip but do not remove ETag headers
	gzip on;
	gzip_vary on;
	gzip_comp_level 4;
	gzip_min_length 256;
	gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
	gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

	# Pagespeed is not supported by Nextcloud, so if your server is built
	# with the `ngx_pagespeed` module, uncomment this line to disable it.
	#pagespeed off;

	# Path to the root of your installation
	root /var/www/nextcloud;

	# Specify how to handle directories -- specifying `/index.php$request_uri`
	# here as the fallback means that Nginx always exhibits the desired behaviour
	# when a client requests a path that corresponds to a directory that exists
	# on the server. In particular, if that directory contains an index.php file,
	# that file is correctly served; if it doesn't, then the request is passed to
	# the front-end controller. This consistent behaviour means that we don't need
	# to specify custom rules for certain paths (e.g. images and other assets,
	# `/updater`, `/ocm-provider`, `/ocs-provider`), and thus
	# `try_files $uri $uri/ /index.php$request_uri`
	# always provides the desired behaviour.
	index index.php index.html /index.php$request_uri;

	# Rule borrowed from `.htaccess` to handle Microsoft DAV clients
	location = / {
		if ( $http_user_agent ~ ^DavClnt ) {
			return 302 /remote.php/webdav/$is_args$args;
		}
	}

	location = /robots.txt {
		allow all;
		log_not_found off;
		access_log off;
	}

	# Make a regex exception for `/.well-known` so that clients can still
	# access it despite the existence of the regex rule
	# `location ~ /(\.|autotest|...)` which would otherwise handle requests
	# for `/.well-known`.
	location ^~ /.well-known {
		# The rules in this block are an adaptation of the rules
		# in `.htaccess` that concern `/.well-known`.

		location = /.well-known/carddav { return 301 /remote.php/dav/; }
		location = /.well-known/caldav  { return 301 /remote.php/dav/; }

		location /.well-known/acme-challenge    { try_files $uri $uri/ =404; }
		location /.well-known/pki-validation    { try_files $uri $uri/ =404; }

		# Let Nextcloud's API for `/.well-known` URIs handle all other
		# requests by passing them to the front-end controller.
		return 301 /index.php$request_uri;
	}

	# Rules borrowed from `.htaccess` to hide certain paths from clients
	location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/)  { return 404; }
	location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console)                { return 404; }

	# Ensure this block, which passes PHP files to the PHP process, is above the blocks
	# which handle static assets (as seen below). If this block is not declared first,
	# then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
	# to the URI, resulting in a HTTP 500 error response.
	location ~ \.php(?:$|/) {
		fastcgi_split_path_info ^(.+?\.php)(/.*)$;
		set $path_info $fastcgi_path_info;

		try_files $fastcgi_script_name =404;

		include fastcgi_params;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		fastcgi_param PATH_INFO $path_info;
		fastcgi_param HTTPS on;

		fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
		fastcgi_param front_controller_active true;     # Enable pretty urls
		fastcgi_pass php-handler;

		fastcgi_intercept_errors on;
		fastcgi_request_buffering off;

		fastcgi_read_timeout 600;
		fastcgi_send_timeout 600;
		fastcgi_connect_timeout 600;

		fastcgi_param PHP_VALUE "upload_max_filesize = 10G
			post_max_size = 10G
			max_execution_time = 3600
			output_buffering = off";
	}

	location ~ \.(?:css|js|svg|gif|png|jpg|ico)$ {
		try_files $uri /index.php$request_uri;
		expires 6M;         # Cache-Control policy borrowed from `.htaccess`
		access_log off;     # Optional: Don't log access to assets
	}

	location ~ \.woff2?$ {
		try_files $uri /index.php$request_uri;
		expires 7d;         # Cache-Control policy borrowed from `.htaccess`
		access_log off;     # Optional: Don't log access to assets
	}

	# Rule borrowed from `.htaccess`
	location /remote {
		return 301 /remote.php$request_uri;
	}

	location / {
		try_files $uri $uri/ /index.php$request_uri;
	}
}

Diese Konfiguration ist an die vorgeschlagene nginx-Konfiguration im Nextcloud Administation Manual angelehnt. Zu beachten ist hier folgendes:

  • Es wird nur ein server für HTTPS (nicht HTTP) definiert. Dies reicht aus, da die Kommunikation mit der Nextcloud ausschließlich verschlüsselt (über HTTPS) ablaufen soll. Der zuvor angelegte HTTP-Gateway nimmt alle Verbindungen über HTTP entgegen und leitet diese an den HTTPS-vHost weiter.
  • Die Let’s Encrypt Zertifikate werden hier in doppelter Ausführung (einmal RSA, einmal ECDSA) angegeben. Beim Verbindungsaufbau wird dann das ECDSA-Zertifikat verwendet, wenn der Client dies unterstützt. Wenn nicht, findet ein „Fallback“ auf das RSA-Zertifikat statt.
  • Die bereits angelegten Dateien für die allgemeine SSL-Konfiguration und die Header werden hier einfach per include eingebunden.

Bitte auch die Kommentare in dieser Datei beachten und ggf. an die eigenen Bedürfnisse anpassen.

Nach diesen Änderung muss der Webserver natürlich noch neu gestartet werden:

service nginx restart

Installation Nextcloud

Endlich sind nun alle Vorbereitungen getroffen worden, damit kann es an die Installation von Nextcloud gehen.

Download

Zunächst laden wir die aktuellste Version von Nextcloud herunter und entpacken diese in das www-Verzeichnis des Webservers:

wget https://download.nextcloud.com/server/releases/latest.tar.bz2
tar -xjf latest.tar.bz2 -C /var/www
rm latest.tar.bz2

Im Anschluss müssen noch die Berechtigungen für den Webserver-User gesetzt werden:

chown -R www-data:www-data /var/www/nextcloud

Anlegen des Datenverzeichnisses

Das Datenverzeichnis von Nextcloud sollte aus Sicherheitsgründen nicht innerhalb des www-Verzeichnisses liegen. Daher legen wir ein eigenes Verzeichnis dafür an und setzen hier ebenfalls die entsprechenden Berechtigungen:

mkdir -p /var/nextcloud_data 
chown -R www-data:www-data /var/nextcloud_data

Datenbank für Nextcloud anlegen

Vor dem Nextcloud-Setup muss noch eine Datenbank für Nextcloud angelegt werden. Dazu melden wir uns einfach an den MySQL-Kommandozeile an:

mysql -u root -p

Nach der Eingabe des Root-Passworts für MariaDB wird zunächst ein spezieller Datenbank-User für Nextcloud angelegt. Anschließend wird eine Datenbank angelegt und dem Nextcloud-Datenbank-User die entsprechenden Rechte zugewiesen. Die Angabe localhost sorgt dafür, dass der Zugriff auf die Datenbank nur auf dem lokalen System erfolgen kann. Ein Remote-Zugriff über das Netzwerk (auf diese Datenbank) ist damit aus Sicherheitsgründen nicht möglich. Die Befehle auf der MySQL-Kommandozeile müssen mit einem Semikolon abgeschlossen werden:

CREATE USER nextcloud_db_user@localhost IDENTIFIED BY 'MeInPasSw0rT';
CREATE DATABASE nextcloud_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL PRIVILEGES on nextcloud_db.* to nextcloud_db_user@localhost;
FLUSH privileges;
exit;

Hier sollte natürlich ein eigenes Passwort für den Nextcloud-DB-User gewählt werden. Beim Anlegen der Datenbank ist auch die Angabe von CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci wichtig, damit die Nextcloud-Datenbank mit 4-Byte-Support erstellt wird.

Nextcloud-Setup

Nun kann das Nextcloud-Setup gestartet werden. Dazu wird einfach die URL der Cloud im Browser aufgerufen (https://nextcloud.meinedomain.de). Hier werden nun folgende Informationen angegeben:

  • Benutzer/Passwort (Administrator): Im Rahmen des Setups wird ein erster Benutzer angelegt, der automatisch Administrator-Rechte für die Cloud besitzt. Der Benutzername ist dabei frei wählbar. Achten sollte man hier auf ein starkes Passwort, da die Cloud ja später öffentlich im Internet erreichbar ist.
  • Datenverzeichnis: Ebenso wird hier nun der Pfad des Datenverzeichnisses angegeben. Standardmäßig will das Setup diesen Datenpfad innerhalb des www-Verzeichnisses erstellen. Allerdings wird aus Gründen der Sicherheit empfohlen, dass das Datenverzeichnis außerhalb des Verzeichnisses /var/www liegen sollte. Daher sollte man hier genau darauf achten, dass hier das richtige Verzeichnis angegeben wird, welches wir zuvor für das Datenverzeichnis von Nextcloud erstellt hatten (/var/nextcloud_data).
  • Datenbank-Verbindung: Hier sind die Zugangsdaten für die soeben angelegte Datenbank anzugeben.
  • Empfohlene Apps: Ganz unten wird noch eine Option angeboten, dass empfohlene Apps gleich im Rahmen des Nextcloud-Setups aktiviert werden („Install recommend apps“). Dabei handelt es sich dann um die Apps Calender, Contacts, Talk, Mail und OnlyOffice. Da für diese Apps aber z.T. weitere Voraussetzungen erfüllt werden müssen, empfehle ich, diese Option im Nextcloud-Setup zu deaktivieren und diese Apps dann bei Bedarf zu einem späteren Zeitpunkt zu installieren.
Nextcloud Setup
Nextcloud Setup

Nach einem Klick auf Installation abschließen wird das Setup ausgeführt. Nach einem kurzen Augenblick wird man dann zur eigenen Cloud weitergeleitet.

Warnungen im Admin-Bereich

Nach der Installation sollte man gleich einen Blick in den Admin-Bereich der Cloud werfen (oben rechts auf das Symbol für den Benutzer Klicken und dann Einstellungen wählen). Weil der erste angelegte Benutzer Admin-Rechte hat, findet man nun auf der linken Seite unter Übersicht eine Zusammenfassung über die Cloud.

Hier werden nach einer frischen Installation mehrere Warnungen angezeigt:

Warnungen im Admin-Bereich nach dem Nextcloud Setup
Warnungen im Admin-Bereich nach dem Nextcloud Setup

Die erste Warnung bemängelt das Fehlen eines Memory-Caches für PHP. Dies ist dabei nicht als Fehler zu verstehen, sondern eher als Hinweis, dass die Performance der Cloud durch einen Memory-Cache verbessert werden kann. Dazu muss einfach nur eine Zeile in der Nextcloud-Konfiguration geändert werden:

nano /var/www/nextcloud/config/config.php

Hier wird einfach am Ende folgende Zeile ergänzt:

'memcache.local' => '\OC\Memcache\APCu',

Die beiden anderen Meldungen beziehen sich auf die Datenbank (fehlende Indizes und fehlende Konvertierung in „big int“ für einige Tabellen). Um diese Warnungen zu beseitigen müssen zwei OCC-Befehle (Kommandozeilen-Interface für Nextcloud) ausgeführt werden:

cd /var/www/nextcloud
sudo -u www-data php occ db:add-missing-indices
sudo -u www-data php occ db:convert-filecache-bigint

Beim zweiten Befehl wird zwar ein Hinweis angezeigt, dass die Konvertierung sehr lange dauern kann, dies ist bei einer komplett neuen Nextcloud-Installation nicht gegeben.

Ab Nextcloud 21 bemängelt die Cloud des weiteren, dass keine Standardtelefonregion in der Konfiguration hinterlegt ist. Um diesem Meldung zu beseitigen, öffnen wir wieder die config.php von Nextcloud:

nano /var/www/nextcloud/config/config.php

Am Ende der Konfiguration wird nun folgende Zeile hinzugefügt:

'default_phone_region' => 'DE',

Wenn die Admin-Übersicht in der Nextcloud nun neu geladen wird, sollten alle Warnungen verschwunden sein.

Nach der Bearbeitung der Hinwiese werden keine Warnungen mehr angezeigt
Nach der Bearbeitung der Hinwiese werden keine Warnungen mehr angezeigt

Wenn mehr Warnungen im Admin-Bereich angezeigt werden: Wenn hier immer noch Warnungen zu sehen sein sollten, dann bitte nochmals alle Schritte dieses Tutorials überprüfen, ob nicht ein kleines Detail ausgelassen wurde (besonders die PHP-Konfiguration). Im Nextcloud Administration Manual findet man auch eine Übersicht aller Warnungen, die hier im Admin-Bereich angezeigt werden könnten und entsprechende Lösungsansätze.

Optimieren der Nextcloud-Konfiguration

Die Konfiguration von Nextcloud sollte über die Datei config.php noch weiter optimiert werden:

nano /var/www/nextcloud/config/config.php

Hier sollten nun folgende Anweisungen eingefügt/kontrolliert werden:

  • HTTPS als Standard definierten: Um alle Verbindungen zur Nextcloud strikt per HTTPS zu behandeln, wird die Verbindung nur über https:// zu forcieren, sollte hier folgende Variable gesetzt werden:
    'overwriteprotocol' => 'https',
  • Zeitzone für Log-Einträge: Die richtige Zeitzone (z.B. für die Zeitangaben der Log-Einträge) wird durch diese Variable konfiguriert:
    'logtimezone' => 'Europe/Berlin',

Installation/Einrichtung Redis

Eine weitere Optimierung, die nun gleich durchgeführt werden sollte, ist die Einrichtung von Redis für Nextcloud. Die Cloud nutzt sog. Transactional File Locking, um Sperren bei parallelem Zugriff auf Dateien zu realisieren. Dateien, die gerade im Zugriff sind, werden dadurch „gelockt“, damit es bei parallelen Zugriffen nicht zu Datenverlusten kommen kann. Ansonsten würde hier immer die letzte Änderung „gewinnen“ und alle parallel durchgeführten Änderungen überschreiben.

Diese Sperren werden standardmäßig in der Datenbank von Nextcloud verwaltet. Um hier Last von der Datenbank zu nehmen und die generelle Performance zu erhöhen, kann hier auch Redis genutzt werden. Diese In-Memory-Datenbank ist genau für solche Aufgaben optimiert, wodurch sich die Performance-Verbesserung ergibt.
Hier sollte man allerdings nicht zu viel erwarten: In kleineren Cloud-Instanzen mit nur wenigen Benutzern wird man hier kaum messbare Änderungen erzielen. Trotzdem empfehle ich den generellen Einsatz von Redis, da die Einrichtung auch nicht besonders aufwändig ist.

Installation und Konfiguration Redis

Zunächst wird Redis und das dazugehörige PHP-Modul installiert:

apt update && apt install redis-server php-redis

Nun erfolgt die Konfiguration der In-Memory-Datenbank:

nano /etc/redis/redis.conf

Analog zur Konfiguration von PHP sollte auch Redis über einen Socket angesprochen werden. Dazu müssen in dieser Konfigurations-Datei folgende Einstellungen gesetzt werden.

port 0 
unixsocket /var/run/redis/redis-server.sock 
unixsocketperm 770

Hiermit wird folgendes konfiguriert:

  • port: Redis lauscht standardmäßig auf dem Port 6379. Wie gesagt wollen wir aber einen Socket nutzen, daher wird das Lauschen auf einem Port deaktiviert.
  • unixsocket: Hiermit wird der eigentliche Socket definiert.
  • unixsocketperm: Berechtigungen für diesen Socket.

Nun muss der.Benutzer www-data noch der Gruppe redis hinzugefügt werden:

usermod -a -G redis www-data

Damit die Änderungen übernommen werden, muss Redis noch neu gestartet werden:

service redis-server restart

Einbinden von Redis in Nextcloud

Damit die eigene Cloud nun auch Redis nutzt, muss dieses noch in der Nextcloud-Konfiguration angepasst werden:

nano /var/www/nextcloud/config/config.php

Am Ende der Datei (aber noch vor der letzten schließenden Klammer) wird nun folgende Konfiguration hinzugefügt:

<?php
$CONFIG = array (
// ...
'filelocking.enabled' => true,
  'memcache.locking' => '\OC\Memcache\Redis',
  'redis' => array (
     'host' => '/var/run/redis/redis-server.sock',
     'port' => 0,
     'timeout' => 0.0,
      ),
// ...
);

Anschließend nutzt Nextcloud nun das Transactional File Locking.

Cronjob für Nextcloud einrichten

Nextcloud benötigt für den einwandfreien Betrieb die regelmäßige Ausführung von Hintergrundaufgaben (z.B. Bereinigung verwaister Datenbank-Einträge, etc.). Diese Aufgaben werden direkt nach der Installation per AJAX ausgeführt: Immer, wenn eine Seite der Cloud aufgerufen wird, wird beim Laden einer Seite geprüft, ob Hintergrundaufgaben anstehen und diese ggf. ausgeführt. Diese Methode hat jedoch zwei Nachteile: Es wird erstens immer ein angemeldeter Benutzer benötigt, denn nur durch diesen können die Hintergrundaufgaben beim Laden der Seite angestoßen werden. Wenn die Cloud nun lange ohne Benutzeranmeldung läuft, dann werden u.U. über einen längeren Zeitraum keine Hintergrund-Jobs ausgeführt. Zum anderen ist die Lösung über AJAX wenig performant.

Daher sollte die Hintergrundaufgaben besser per Cron ausgeführt werden. Hier prüft ein Hintergrund-Dienst in regelmäßigen Abständen, ob Hintergrundaufgaben ausgeführt werden sollten. Besonders auf schwächerer Hardware ist diese Methode deutlich effizienter.

Dazu wird einfach ein Cronjob unter dem Webserver-Benutzer angelegt:

crontab -u www-data -e

Am Ende der Datei wird anschließend folgende Zeile eingefügt:

*/5 * * * * php -f /var/www/nextcloud/cron.php > /dev/null 2>&1

Nach dem Speichern der Datei wird dieser Cronjob alle 5 Minuten automatisch ausgeführt. Theoretisch könnte hier auch eine andere Zeitspanne genutzt werden, allerdings ist die allgemeine Empfehlung 5 Minuten (siehe Nextcloud Admin-Manual).

Nach fünf Minuten kann nun in der Admin-Oberfläche (unter den Grundeinstellungen) der Cloud geprüft werden, ob der Cronjob ausgeführt wurde: Die entsprechende Option sollte nun auf Cron stehen. Ebenso sollte nach jeder Ausführung des Cronjobs unter Letzte Aufgabe ausgeführt folgendes stehen: Gerade eben.

Nextcloud: Ausführung von Hintergrund-Aufgaben per Cron
Nextcloud: Ausführung von Hintergrund-Aufgaben per Cron

Weitere Konfiguration Nextcloud

Damit ist die die grundsätzliche Konfiguration von Nextcloud soweit abgeschlossen. Nun ist es an der Zeit, die Cloud an die eigenen Bedürfnisse anzupassen.

Nextcloud kann nun durch eine große Auswahl an Apps erweitert werden: siehe Nextcloud App Store.

Generell ist bei der erweiterten Konfiguration von Nextcloud ein Blick ins Nextcloud Administration Manual empfehlenswert.

Optimierung der Server-Umgebung für Nextcloud

Die eigene Nextcloud ist nun soweit fertig eingerichtet und kann bereits genutzt werden. Dennoch kann die Server-Umgebung noch weiter optimiert werden.

ufw

ufw (uncomplicated firewall) ist eine Software-Firewall, die auf einer Ubuntu-Installation standardmäßig bereits installiert ist. Im Heim-Bereich übernimmt normalerweise der Router schon die Aufgaben einer Firewall, daher ist die Einrichtung von hier ufw optional. Auf einem Root-Server ist aber in der Regel keine Firewall vor den Server geschaltet, daher sollte die Einrichtung von ufw hier in jedem Fall erfolgen.

Falls ufw noch nicht installiert sein sollte, kann man dies mit folgendem Befehl nachholen:

apt update && apt install ufw

Die Firewall soll sämtlichen eingehenden Traffic blockieren, mit einigen Ausnahmen:

  • SSH (Port 22): Hier soll der Zugriff nur aus dem Heimnetzwerk erlaubt sein.
  • HTTP/HTTPS (Ports 80/443): Da der Zugriff aus dem Web erforderlich ist, muss hier auch eine Ausnahme hinzugefügt werden.

Mit folgenden Befehlen werden diese Regeln umgesetzt:

ufw default deny
ufw allow proto tcp from 192.168.178.0/24 to any port 22
ufw allow 80
ufw allow 443
ufw enable

Nach dem Aktivieren der Firewall können die Regeln nochmal überprüft werden:

ufw status

Wichtig: Wenn auf dem Server weitere Anwendungen installiert sind, die andere Ports nutzen oder z.B. ein abweichender Port für SSH genutzt wird, ist dies natürlich bei der Erstellung der Firewall-Regeln zu beachten. Man sollte also immer im Hinterkopf behalten, dass eine Firewall auf dem System aktiv ist und das diese ggf. angepasst werden muss.

Fail2ban

Nextcloud wird standardmäßig mit einem Brute-Force-Schutz ausgeliefert. Dieser sorgt bei fehlgeschlagenen Logins für eine Verzögerung von Login-Versuchen aus dem betroffenen Subnetz. Bei Brute-Force-Attacken führt dies zu maximal zu einer Verzögerung um 30 Sekunden zwischen Login-Versuchen. Allerdings werden keine IPs gebannt.
Daher ist für eine Absicherung der Cloud der Einsatz von Fail2ban sinnvoll. Gegenüber dem Brute-Force-Schutz der Nextcloud bietet Fail2ban folgende Vorteile:

  • Mit Fail2ban können IPs automatisch gebannt werden. Nach einem solchen Ban kann die betroffene IP nicht mehr auf die Nextcloud-Instanz zugreifen, es wird lediglich eine Fehlermeldung des Browsers angezeigt.
  • Fail2ban arbeitet IP-basiert: Es wird nur die betroffene IP blockiert, von der aus zu viele fehlgeschlagene Login-Versuche unternommen wurden. Andere Nutzer mit abweichenden IP-Adressen aus dem gleichen Netzwerk (Subnet) werden dabei nicht gebannt.
  • Das Einsatzgebiet von Fail2ban ist sehr weit gefächert: Man kann hier nicht nur die Nextcloud-Installation, sondern auch weitere Anwendungen auf dem Server absichern (z.B. Webserver und SSH).

Konfigurations-Dateien von Fail2ban

Vor der Installation noch ein paar Worte zu den Konfigurations-Dateien von Fail2ban: Das Programm unterscheidet zwischen zwei Arten von Konfigurations-Dateien: *.conf und *.local. Die conf-Dateien kommen bei der Installation mit und sind die „Standard-Einstellungen“. Diese Dateien sollten aber nie direkt bearbeitet werden, da diese bei einem Update von Fail2ban überschrieben werden können. Daher nutzt man für individuelle Änderungen Dateien mit gleichem Namen, aber mit der Dateiendung .local. Diese local-Dateien überschreiben dann die Standard-Einstellungen der conf-Dateien. Auf diese Weise geht eine individuelle Konfiguration bei einem Update von Fail2ban nicht verloren.

Deaktivieren des Nextcloud Brute-Force-Schnutzes

Wenn Fail2ban zum Einsatz kommt, kann der integrierte Brute-Force-Schutz von Nextcloud deaktiviert werden. Dazu bearbeiten wir die Konfigurations-Datei von Nextcloud:

nano /var/www/nextcloud/config/config.php

Der Schutz wird durch die Eingabe folgender Zeile deaktiviert:

'auth.bruteforce.protection.enabled' => false,

Hier sollte auch gleich noch kontrolliert werden, ob Nextcloud die richtige Zeitzone für die Einträge im Log nutzt, da es für Fail2ban essentiell ist, dass hier korrekte Zeiten geloggt werden:

'logtimezone' => 'Europe/Berlin',

Installation und Konfiguration Fail2ban

Nun kann Fail2ban installiert werden:

apt update && apt install fail2ban

Anschließend muss ein sog. „Filter“ für Nextcloud definiert werden:

nano /etc/fail2ban/filter.d/nextcloud.local

In dieser Filter-Datei wird nun ein regulärer Ausdruck hinterlegt. Dieser definiert das Format, welches einen fehlgeschlagenen Login-Versuch im Nextcloud-Log identifiziert:

[Definition] 
failregex=^{"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' \(Remote IP: '<HOST>'\)","level":2,"time":".*"}$ 
            ^{"reqId":".*","level":2,"time":".*","remoteAddr":".*","user":".*","app":".*","method":".*","url":".*","message":"Login failed: '.*' \(Remote IP: '<HOST>'\)".*}$ 
            ^{"reqId":".*","level":2,"time":".*","remoteAddr":".*","user":".*","app":".*","method":".*","url":".*","message":"Login failed: .* \(Remote IP: <HOST>\).*}$

Damit dieser Filter zum Einsatz kommt, wird dieser Fail2ban noch bekannt gemacht:

nano /etc/fail2ban/jail.local

Hier fügen wir folgenden Inhalt ein:

[DEFAULT]
maxretry=3
bantime=1800

[nextcloud]
enabled=true
port=80,443
protocol=tcp
filter=nextcloud
logpath=/var/nextcloud_data/nextcloud.log

[nginx-http-auth]
enabled = true

Der Teil unter [DEFAULT] gilt dabei für alle Regel-Sets (Jails). Hier werden die allgemeinen Einstellungen für Bans hinterlegt:

  • maxretry: Anzahl der Fehlversuche, bevor Fail2ban eine IP sperrt.
  • bantime: Zeitraum (in Sekunden), für den eine IP gesperrt werden soll. Durch die Eingabe von -1 werden betroffene IPs dauerhaft gebannt.

Unter [nextcloud] wird dann neues Jail für Nextcloud definiert:

  • enabled: Aktivierung dieser Regel. Falls das Jail später (temporär) deaktiviert werden soll, kann dies einfach durch diese Option erfolgen.
  • port: Port, hier 80 (HTTP) und 443 (HTTPS).
  • protocol: Das verwendete Protokoll, in unserem Fall TCP.
  • filter: Name des Filters aus gleichnamiger Datei unter /etc/fail2ban/filter.d. Der Filter für Nextcloud wurde ja schon im vorherigen Schritt angelegt.
  • logpath: Log-Datei, die Fail2ban für dieses Jail beobachten soll. Auf diese Datei wird der oben definierte Filter angewendet.
  • Hier könnten auch noch Werte für maxretry und bantime hinterlegt werden, die dann sie Standard-Werte überschreiben und nur für das Nextcloud-Jail gelten.

Wir aktivieren hier unter [nginx-http-auth] auch gleich noch die Überwachung der Logs des Webservers. Dieses Jail ist bereits in den Standard-Jails (/etc/fail2ban/jail.conf) definiert und wird an dieser Stelle lediglich „scharf geschaltet“. Dies sorgt für eine Überwachung bei anderen Webanwendungen, bei den eine HTTP-Basic-Authentifizierung zum Einsatz kommt. Die Ban-Optionen (maxretry und bantime) werden hier nicht angegeben, daher gelten die Standard-Werte, die in der Sektion [DEFAULT] angegeben wurden.

Nun fehlt nur noch ein Neustart des Dienstes:

service fail2ban restart

Optional: E-Mail-Versand durch Fail2ban

Fail2ban arbeitet nun „lautlos“ im Hintergrund. Nur ein Administrator kann den aktuellen Status von Fail2ban über die Kommandozeile prüfen.

Sinnvoll ist nun noch eine Erweiterung, damit Fail2ban im Falle eines Bans eine E-Mail an den Server-Administrator verschickt. Die Voraussetzung ist dabei, dass das Linux-System bereits Mails versenden kann. Dies kann ohne großen Aufwand über msmtp realisiert werden. Die Installation und Einrichtung des Programms wurde bereits im Artikel Linux: Einfach E-Mails senden mit msmtp ausführlich erklärt.

Bei Fail2ban ist bereits der Versand von E-Mails vorgesehen, daher reichen hier kleinere Anpassungen, wenn msmtp bereits installiert wurde:

nano /etc/fail2ban/jail.local

Am Anfang werden nun in der Default-Sektion folgende Zeilen eingefügt (hier markiert):

[DEFAULT]
maxretry=3
bantime=1800

# Destination email address used solely for the interpolations in
# jail.{conf,local,d/*} configuration files.
destemail = meineemail@provider.de

# Sender email address used solely for some actions
sender = absenderadresse@provider.de

# E-mail action. Since 0.8.1 Fail2Ban uses sendmail MTA for the
# mailing. Change mta configuration parameter to mail if you want to
# revert to conventional 'mail'.
mta = mail
action = %(action_mwl)s

Folgende Optionen werden damit gesetzt:

  • destemail ist die Mail-Adresse, an die Benachrichtigungen verschickt werden.
  • sender ist die Adresse, von der die E-Mail gesendet werden (Absender).
  • Wichtig ist insbesondere die Zeile action = %(action_mwl)s: Hierdurch werden E-Mails standardmäßig versendet.

Nun würde man bei jeder Aktion von Fail2ban eine E-Mail erhalten, also auch wenn der Dienst z.B. neu gestartet wurde. Wenn Fail2ban ausschließlich beim Bannen einer IP eine Mail versenden soll, müssen noch ein paar Änderungen vorgenommen werden. Die Konfiguration dazu wird wieder über local-Dateien im Verzeichnis /etc/fail2ban/action.d realisiert. Folgende Dateien müssen dafür angelegt werden:

  • mail-buffered.local
  • mail.local
  • mail-whois-lines.local
  • mail-whois.local
  • sendmail-buffered.local
  • sendmail-common.local

Der Inhalt sieht dabei immer gleich aus:

[Definition]

# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#
actionstart =

# Option:  actionstop
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
#
actionstop =

Am Ende noch Fail2ban neu starten:

service fail2ban restart

Test der Funktionalität

Am Schluss sollte noch die Funktionalität von Fail2ban getestet werden. Dies ist insbesondere sinnvoll, damit man auch mal das Entbannen einer IP durchgeführt hat – es könnte ja mal sein, dass man sich selbst „aussperrt“.

Dazu meldet man sich einfach drei mal mit einem nicht vorhandenen Benutzer an der eigenen Cloud an. Beim vierten Versuch sollte wie Webseite dann gar nicht mehr aufrufbar sein. Zeitgleich sollte man eine E-Mail erhalten, die über den Ban informiert. Auf der Kommandozeile kann man sich diesen Ban nun anzeigen lassen:

fail2ban-client status nextcloud

Hier sollte nun die gebannte IP aufgeführt werden. Um den Ban aufzuheben, geben wir nun folgenden Befehl ein:

fail2ban-client set nextcloud unbanip 45.135.54.12

Anschließend sollte man wieder wie gewohnt auf Nextcloud zugreifen können.

Überprüfung der Sicherheit

Die Sicherheit der eigenen Cloud war ja von Anfang an ein wichtiges Ziel dieses Artikels. Nach der Einrichtung von Nextcloud gibt es einige Tools, mit denen dies nochmal kontrolliert werden kann.

Qualys SSL Labs

Mit dem SSL Server Test von Qualys SSL Labs kann die HTTPS-Verschlüsselung auf einfache Weise überprüft werden. Getestet wird hier sowohl die Einbindung der Let’s Encrypt Zertifikate, als auch die SSL-Einstellungen des Webservers.
Wenn alles richtig konfiguriert wurde, sollte hier eine Bewertung von A+ angezeigt werden:

Qualys SSL Server Test
Qualys SSL Server Test

Mozilla Observatory

Ebenfalls ein guter Test ist Mozilla Observatory. Hier sollte ebenso ein Rating von A+ erzielt werden können.

Mozilla Observatory
Mozilla Observatory

Nextcloud Security Scan

Ein weiterer Test ist der Nextcloud Security Scan. Dieses Tool prüft die öffentlich verfügbaren Informationen der Nextcloud-Instanz und kann eventuelle Schwachstellen aufzeigen. Auch hier sollte ein Rating von A+ angezeigt werden:

Nextcloud Security Scan
Nextcloud Security Scan

FAQ

An dieser Stelle sollen die häufigsten Fragen zu diesem Artikel beantwortet werden.

Ich habe bereits eine Nextcloud-Installation unter Ubuntu Server 18.04 LTS am laufen. Soll ich diese nun möglichst schnell auf Ubuntu Server 20.04 LTS updaten?

Ubuntu 18.04 LTS wird noch bis April 2023 unterstützt. Daher ist beim Update auf Ubuntu Server 20.04 LTS keine Eile geboten. Im Gegenteil: Wenn das System ansonsten keine Probleme bereitet, würde ich mit dem Update noch etwas abwarten – zumindest bis zur Version 20.04.1.
Bei komplett neuen Installationen macht es dagegen durchaus Sinn, direkt auf Ubuntu Server 20.04 LTS aufzusetzen.

Der Artikel zeigt, wie man Nextcloud direkt im Root-Verzeichnis des Webservers installiert. Ich möchte die Nextcloud allerdings in einem Unterverzeichnis des Webservers laufen lassen. Was muss ich dazu beachten?

Durch die vereinfachte Webserver-Konfiguration empfehle ich mittlerweile die Installation der eigenen Cloud direkt im Web-Root (z.B. https://nextcloud.meinedomain.de). Wer Nextcloud dennoch in einem Unterverzeichnis des Webservers laufen lassen will (z.B. https://meinedomain.de/nextcloud), der kann sich dazu am vorherigen Artikel Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban orientieren.

Ich möchte eine weitere Webanwendung auf dem gleichen Server installieren. Wie muss ich dazu vorgehen?

Angenommen, man möchte neben Nextcloud (nextcloud.meinedomain.de) noch eine WordPress-Instanz unter (blog.meinedomain.de) aufsetzen. In diesem Fall muss zunächst einmal sicher gestellt sein, dass die zweite Domain auch auf die eigene IP-Adresse verweist. Hier reichen wieder A- bzw. AAAA-Records bei der zweiten Domain aus, wenn es sich um eine fest IP handelt. Falls nicht, muss ein sog. CNAME-Eintrag für die Domain blog.meinedomain.de erstellt werden, der auf die DynDNS-Adresse verweist (in diesem Fall nextcloud.meinedomain.de). Dies ist notwendig, weil die meisten Router nicht die gleichzeitige Verwendung mehrerer DynDNS-Konfigurationen erlauben.

Anschließend muss der HTTP-Gateway erweitert werden, so dass dieser auch auf die neue Domain reagiert:

nano /etc/nginx/conf.d/HttpGateway.conf

Hier fügen wir die neue Domain unter server_name ein:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name nextcloud.meinedomain.de blog.meinedomain.de 192.168.178.60;
    
    #...
}

Nach einem Neustart können nun für die zweite Domain Zertifikate bei Let’s Encrypt beantragt werden. Dies geschieht analog wie im Artikel für die Domain nextcloud.meinedomain.de gezeigt.

Nun kann ein weiterer virtueller Host für die zweite Domain erstellt werden:

nano /etc/nginx/conf.d/blog.meinedomain.de.conf

Hier werden dann die soeben ausgestellten Zertifikate eingebunden. Dank er Modularisierung mit den „Snippets“ für die allgemeine SSL-Konfiguration und den Headern, können diese Bausteine wiederverwendet werden:

server {
	listen 443 ssl http2;
	listen [::]:443 ssl http2;
	server_name blog.meinedomain.de;
 
	# SSL configuration
	# RSA certificates
	ssl_certificate /etc/letsencrypt/blog.meinedomain.de/rsa/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/blog.meinedomain.de/rsa/key.pem;
	# ECC certificates
	ssl_certificate /etc/letsencrypt/blog.meinedomain.de/ecc/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/blog.meinedomain.de/ecc/key.pem;
 
	# This should be ca.pem (certificate with the additional intermediate certificate)
	# See here: https://certbot.eff.org/docs/using.html
	# ECC
	ssl_trusted_certificate /etc/letsencrypt/blog.meinedomain.de/ecc/ca.pem;
 
    # Include SSL configuration
	include /etc/nginx/snippets/ssl.conf;
 
	# Include headers
    include /etc/nginx/snippets/headers.conf;
    
    #...
}

Die weitere Konfiguration des vHosts für blog.meinedomain.de ist abhängig von der jeweiligen Webanwendung, die installiert werden soll. Für WordPress findet man z.B. hier eine Konfiguration, die man als Grundlage verwenden kann.

Auf diese Weise hat man die Konfigurationen zu den einzelnen Webseiten durch den Einsatz von zwei separaten vHosts gut getrennt.

Troubleshooting

Das hier gezeigte Setup ist durchaus umfangreich. Daher kann es passieren, dass nicht alles auf Anhieb klappt. Für diese Fälle hier noch ein paar Tipps und Tricks für die Fehlersuche:

  • Wurden alle Schritte korrekt ausgeführt?
    Die Installation der eigenen Cloud erfordert viele Schritte, die aufeinander aufbauen. Hier kann es leicht vorkommen, dass man einen kleinen Schritt übersieht, oder es während der Ausführung des Schrittes zu einem Fehler gekommen ist, den man aber nicht bemerkt hat. Auch wenn der Schritt noch so unbedeutend aussehen mag: Die kleinste Abweichung kann dazu führen, dass „das große Ganze“ nicht mehr funktioniert. Als ersten Punkt für die Fehlersuche empfehle ich daher immer nochmal die genaue Kontrolle der einzelnen Schritte.
  • Kontrolle der Logs
    Wenn irgend etwas nicht auf Anhieb klappen mag, hilft oftmals ein Blick in die entsprechenden Log-Dateien:  
    • nginx (/var/log/nginx/error.log): Der Webserver führt hier alle Warnungen und Fehler auf. Dies sollte immer die erste Anlaufstelle sein, wenn sich Nextcloud gar nicht aufrufen lässt bzw. Links nicht richtig funktionieren.
    • Nextcloud (/var/nextcloud_data/nextcloud.log): Hier sind Fehler/Warnungen von Nextcloud selbst enthalten. Die Logs können auch direkt über die Admin-Oberfläche von Nextcloud untersucht werden. Die Einträge im Nextcloud-Log sind v.a. dann interessant, wenn die eigene Cloud prinzipiell aufgerufen werden kann (und der Webserver vermutlich korrekt eingerichtet wurde), es aber bei der Benutzung von Nextcloud zu Problemen kommt.
  • Developer-Console im Browser
    Wenn die Kontrolle der Logs zu keinen Erkenntnissen führen, dann es sinnvoll sein, einen Request mit geöffneter Developer-Console im Browser (meist zu öffnen mit F12) auszuführen. Hier wird detailliert aufgelistet, was bei einem Aufruf des Clients passiert. Die Bedienung der Console läuft in jedem Browser etwas anders ab, daher hilft ein Blick in die entsprechende Dokumentation:  

Falls ihr also Probleme bei der Einrichtung von Nextcloud haben solltet, bitte erst einmal diese Punkte überprüfen. Oftmals findet man dann relativ schnell die Ursache. Wenn alles nicht hilft, dann könnt ihr hier natürlich einen Kommentar hinterlassen, vielleicht kann euch schnell weitergeholfen werden.

Falls sich bestimmte Probleme häufen sollte, werde ich den Artikel ggf. anpassen und/oder erweitern.

Nextcloud: Ein sicherer Ort für all deine Daten

Dies ist der bekannte Slogan von Nextcloud und dieser trifft es auch ziemlich genau: Auch wenn der Aufwand zum Aufsetzen der eigenen Cloud nicht zu unterschätzen ist, ist man nach getaner Arbeit jedoch unabhängig von einem (externen) Cloud-Anbieter. Dadurch bleibt man jederzeit Herr über die eigenen Daten, die sicher und einfach in der eigenen Cloud gespeichert werden können.

Jedoch sollte man sich auch im Klaren darüber sein, dass man nun auch für den Betrieb der Cloud verantwortlich ist. Dies erfordert nach dem Aufsetzen von Nextcloud auch einen gewissen administrativen Aufwand. So ist der Cloud-Admin dafür verantwortlich, dass die Cloud und das Betriebssystem auf dem aktuellen Stand gehalten werden. Dennoch sollte sich der Aufwand hierfür in Grenzen halten.

Ich hoffe, dass dieser Artikel hilfreich war und ich einigen unter euch etwas Zeit (und Nerven) bei der Einrichtung der eigenen Cloud ersparen konnte. Für konstruktive Kritik und Verbesserungsvorschläge bin ich immer offen, daher hinterlasst mir doch gern einen Kommentar.

In diesem Sinne heißt es wie immer: Viel Spaß mit eurer eigenen Nextcloud!

Weiterführende Artikel

Links

, , , , , , , , , , , , , , , , , ,

Kommentare: 653

  • Mace sagt:

    Hi Jan!
    Erstmal auch von mir ein Lob für die ausführliche und verständliche Anleitung. Nur ein Profi kann solch komplexen Themen in solch einer Art und Weise schreiben :)
    Ich habe zurzeit Probleme dabei, die test.txt anzuzeigen, ähnlich wie schon DJay.
    Dyndns ist eingerichtet, funktioniert auch auf meinen Router (Speedport w724v). Wenn ich meine IP-Adresse des Pi’s eingebe, komme ich auf die Seite, die anderen sind mit 403 Forbidden gesperrt. (/.well-known & /acme)
    Das interessante ist nun, dass ich nach dem Öffnen der Ports mit Eingabe meiner Dyndns-Domäne bei den Seiten /.well-known & /acme einen „404 Not Found“ Error sehe und bei der test.txt zeigt er „Hmmm…diese Seite ist leider nicht erreichbar“ an.
    Weißt du denn, an was es liegen könnte?

    • Jan sagt:

      Hi,

      das ist in der Tat seltsam. Liefert hier die Browser-Console ein wenig mehr Infos? Ansonsten müsstest du hier echt mal in die Logs (des Webservers) sehen, was er hier genau treibt, bzw. auf welche Ordner/Dateien er hier versucht zuzugreifen.

      Gruß,
      Jan

  • Alex sagt:

    Bei mir startet nginx einfach nicht. Ich folge den ersten paar Schritten der Anleitung und beim testen der Webseite erscheint einfach nichts…

    Aktuelles Image habe ich und die neusten Updates durchgeführt.

    • Jan sagt:

      Hi Alex,

      wenn nginx nicht mehr startet, dann einfach mal mit nginx -t auf Fehlersuche gehen. Hier wird dann immer sehr präzise angezeigt, was ihm an der Konfiguration nicht passt.

      Gruß,
      Jan

      • Alex sagt:

        Hi Jan, danke für die schnelle Antwort!

        Ich musste nur den nginx Dienst starten, das hat er nicht von alleine..

        Danke für die gute Anleitung, die hat mir echt gefallen!

  • Hans sagt:

    Hallo Jan,
    vielen Dank für die Anleitung. Wie immer super.
    Ich habe noch die 18.04 Installation. Ich möchte aber das System auf die Sub-Domain Variante umstellen.
    Muss ich dann Nextcloud neu installieren oder muss ich im virtuellen Host für Nextcloud lediglich die Variable

    # Path to the root of your installation

    auf

    root /var/www/;

    belassen?

    Grüße
    Hans

    • Jan sagt:

      Hi Hans,

      dafür müsstest du v.a. den vHost für Nextcloud abändern, d.h. sämtliche Verweise auf das Unterverzeichnis „/nextcloud“ aus den location Blöcken entfernen. Darüber hinaus sollten auch nur minimale Anpassungen an der config.php von Nextcloud notwendig sein, da hier ja z.T. auch die Verweise auf das Unterverzeichnis angegeben werden.

      Eine Neuinstallation ist hier definitiv nicht notwendig.

      Gruß,
      Jan

  • Clemens sagt:

    Hi. Vielen Dank für die super Anleitung.
    Leider hatte mein alter dyndns Anbieter Probleme gehabt und ich habe mich entschieden den Server einmal komplett neu aufzusetzen.
    An sich klappt auch alles super. Doch leider ist der Zugriff auf Nextcloud über IP und Dyndns ultra langsam.
    Ich sitze mittlerweile seit 2 Monaten daran und versuche das Problem zu lösen. Das Problem geht erst dann los, nach dem ich das Setup der Nextcloud abgeschlossen habe, sprich ich mich das erste Mal Einloggen kann.
    Es gibt keine Fehlermeldung, es dauerteinfsch ca. 10 Minuten bis sich eine Seite aufbaut.
    Alle anderen Anwendungen laufen reibungslos.
    Ich bin genau nach der Anleitung gegangen. Habe mittlerweile 7 oder 8 mal neu installiert, php, nginx, mariadb versucht anzupassen. Alles ohne Erfolg.
    Deswegen nun meine Frage. Ist dieses Problem vielleicht bekannt? Und kennt jemand die Lösung???

    Ich verzweifel langsam.

    • Jan sagt:

      Hi Clemens,

      du könntest mal ausprobieren, den Brute-Force-Schutz bei Nextcloud über die config.php auszuschalten. Das kann meiner Erfahrung nach dafür sorgen, dass Nextcloud viel langsamer reagiert, da die Requests verzögert werden.
      Wenn die Cloud dann wieder normal funktioniert, hast du auf jeden Fall den Grund gefunden. Dann gilt es nur noch herauszufinden, wer (oder welches Gerät) sich permanent mit falschen Anmeldedaten anmeldet.

      Ansonsten sind mir hier keine generelle Probleme mit der Performance von Nextcloud bekannt.

      Gruß,
      Jan

  • Udo sagt:

    Hallo Jan,

    erstmal großes Lob mit dieser Anleitung. Ich habe eine Nextcloud Instanz aufgesetzt, die seit 3 Monaten problem los läuft. Jetzt habe ich aber das Problem, das ich nur noch direkt, also mit angeschlossenem Monitor und Tastatur auf die Konsole zugreifen kann. Über funktioniert es nicht mehr. Ich habe auch versucht, in der sshd_config den Eintrag #PermiRootLogin zu ändern in without-password bzw. yes. Beides ohne Erfolg. Hast du eine Idee, an was das liegen könnte?

    Grüße

    Udo

    • Udo sagt:

      Ich habe vergessen, das daß ssh Programm Putty ist

      • Jan sagt:

        Hi Udo,

        kommt hier irgendeine Fehlermeldung auf der Client- oder Server-Seite (SSH-Logs oder syslog)? Hast du Server-seitig irgendwas geändert, nachdem der SSH-Zugriff nicht mehr geklappt hat?
        Das kann nämlich an vielen Dingen liegen. Der „Klassiker“ wäre natürlich, dass man sich selbst durch das Scharfschalten der Firewall (ufw) ausgesperrt hat, wenn man den Port für SSH nicht mit freigegeben hat.

        Gruß,
        Jan

        • Udo sagt:

          Ich werde morgen im Laufe des Tages den PC nochmal anschließen und schau mir die Logs an. Ich melde mich dann.

          Gruß
          Udo

          • Udo sagt:

            Hallo, es hat etwas gedauert. Also folgendes, in den Logs bei Nextcloud steht kein Fehler drin. Nur bei Putty im Log steht als letztes:
            Event Log: Password authentication failed.
            Was auch komischerweise geht, das ich mich mit dem User Letsencrypt und einem weiterem User problemlos über Putty einloggen kann, nur mit dem User Root nicht.

          • Jan sagt:

            Hi Udo,

            „PermiRootLogin“ hattest du ja so gesetzt, dass Logins per Root möglich sind, oder? Den SSH-Dienst danach nochmal neu gestartet?

            Gruß,
            Jan

  • Hi,
    Tolle Anleitung, vielen lieben Dank, das hat mir die Arbeit schon sehr erleichtert!

    Ich hatte mit Redis aber noch ein Problem.
    Sobald Redis aktiviert war, erhielt ich einen Fehler beim NC-Login:

    Interner Serverfehler
    Der Server konnte die Anfrage nicht fertig stellen.
    Sollte dies erneut auftreten, sende bitte die nachfolgenden technischen Einzelheiten an Deinen Server-Administrator.
    Weitere Details können im Server-Protokoll gefunden werden.
    Technische Details
    Entfernte Adresse: xx.xxx.xx.xxx
    Anfragekennung: zL3GpqClhWVqNEOLUbcc

    Der Fehler scheint bekannt, ich finde aber nur Anleitungen, wie das unter Docker zu beheben ist und bin nicht sicher, ob ich das 1:1 hätte übernehmen können.

    Für’s Erste habe ich wie hier beschrieben:
    https://help.nextcloud.com/t/solved-latest-docker-image-broke-the-installation-redis-password-auth/87598/15
    die 3 Zeilen aus
    /var/www/nextcloud/lib/private/RedisFactory.php
    auskommentiert, damit funktioniert es erst mal wieder.
    Aber vielleicht hast Du eine bessere Idee?
    Danke
    Sascha

    • Jan sagt:

      Hi Sascha,

      wie es aussieht muss man hier Redis ein Passwort zuweisen und dann mit docker-compose neu starten.
      In einer non-Docker-Umgebung ist mir das Problem nicht bekannt. Dazu muss ich sagen, dass ich kein Fan der Docker-Variante von Nextcloud bin. Einige Installationen haben gezeigt, dass es doch schon sehr umständlich ist, wenn man hier ein paar besondere Anforderungen hat.
      Änderungen am Source von Nextcloud sollten auf jeden Fall vermieden werden. Das ist dann nach jedem Update wieder weg und du wirst hier auch eine Warnung in der Admin-UI erhalten. Das sollte dann also nur ein temporärer Workaround sein.

      Gruß,
      Jan

      • Hi Jan,
        bin ganz Deiner Meinung, was Docker angeht, deshalb wird das bei mir auch nicht verwendet.
        Der Fehler taucht eben aber auch mit Deiner Anleitung auf, vielleicht erst seit der neuesten NC-Version.
        die besprochenen 3 Zeilen in /var/www/nextcloud/lib/private/RedisFactory.php auszukommentieren, hilft übrigens auch nicht nachhaltig. Zwar kann man sich dann zunächst wieder einloggen, aber bei nächster Gelegenheit (neues plugin installiert) ist das login wieder kaputt.
        Ich habe redis nun erstmal komplett aus der NC-Konfig entfernt, damit läuft ja alles stabil.

        Danke
        Sascha

        P.S.: Ich glaube übrigens, dass Johannes, weiter unten, wahrscheinlich das selbe Problem hat.

        • Jan sagt:

          Hi Sascha,

          auf welchem OS/Distribution bist du aktuell? Ein generelles Problem ist mir hier nicht bekannt, obwohl ich in letzter Zeit sehr viele Cloud-Instanzen aufgesetzt habe. Wenn es ein generelles Problem wäre, wäre ich vermutlich auch schon drüber gestolpert.

          Gruß,
          Jan

          • Hi,
            bin ganz regulär auf Ubuntu 20.04.1 LTS
            Installation von der „server“.iso

            momentan ist redis wie gesagt auskommentiert in meiner config.php, dann läuft es:

            […]
            ‚installed‘ => true,
            ‚auth.bruteforce.protection.enabled‘ => false,
            ‚memcache.local‘ => ‚\OC\Memcache\APCu‘,
            ‚overwriteprotocol‘ => ‚https‘,
            ‚logtimezone‘ => ‚Europe/Berlin‘,
            # ‚filelocking.enabled‘ => ‚true‘,
            # ‚memcache.locking‘ => ‚\OC\Memcache\Redis‘,
            # ‚redis‘ =>
            # array(
            # ‚host‘ => ‚/var/run/redis/redis-server.sock‘,
            # ‚port‘ => 0,
            # ‚timeout‘ => 0.0,
            # ),
            );

            Oder haqb ich hier irgendeinen Fehler gemacht?

            lg
            Sascha

          • also das ist seltsam.
            Ich bin gerade noch mal Deine Anleitung durchgegangen und habe den Redis-Teil neu gebaut.
            Ich habe wirklich keinen einzigen Unterschied zu vorher entdecken können, aber jetzt funktioniert es :-)
            Keine Ahnung, Danke für Deine Hilfe!!!
            LG
            Sascha

    • Flo sagt:

      In der Anleitung hat sich ein Fehler eingeschlichen, der dieses Problem verursacht:

      „usermod -a -G redis www-data“

      müsste

      „usermod -a -G www-data redis“

      heißen. Dem redis nutzer fehlen so die Berechtigungen für den Zugriff auf das Nextcloud Verzeichnis.
      Das Problem ist ersichtlich in /var/log/nginx/error.log:

      *10 FastCGI sent in stderr: „PHP message: PHP Fatal error: Uncaught RedisException: Permission denied in /var/www/nextcloud/lib/private/RedisFactory.php:92

      Ansonsten aber tolle Anleitung!

      • Jan sagt:

        Hi Flo,

        nein, dass passt schon so. Der Nutzer www-data soll der Gruppe redis hinzugefügt werden (siehe hier). Die Berechtigungen kommen dann über den Parameter unixsocketperm in der redis-Konfiguration.

        Gruß,
        Jan

  • Johannes sagt:

    Hey, wollte nur sagen, dass irgendwas, bei deiner redis konfiguration in der Nextcloud config irgendwas nicht stimmt. Sobald ich die da reinpacke, bekomme ich nen internal server error bei Nextcloud. Hast du ne Ahnung woran das liegt?

    • Jan sagt:

      Hi Johannes,

      hast du hier bei Redis die richtigen Berechtigungen gesetzt? Das ist meist der große Knackpunkt, wenn man das vergisst, funktioniert Nextcloud mit Redis gar nicht mehr.

      Gruß,
      Jan

      • Wolfram sagt:

        Die Angaben zum MemCache mit Redis müssen unbedingt vor den letzten beiden Klammern eingefügt werden – also


        ),
        );

        Ich bin seinerzeit bald wahnsinnig geworden, da sämtliche Einstellungen korrekt waren, alle Services liefen etc. – bis ich dann irgendwann auf folgenden Artikel von Jack Wallen auf TheNewStack gestoßen bin: https://thenewstack.io/performance-tune-nextcloud-with-caching/

        Sollte hier im Tut vielleicht auch noch einmal eindeutiger angesprochen werden, da die aktuelle Formulierung „… Ende der Datei (noch vor der letzten schließenden Klammer) wird nun folgende Konfiguration hinzugefügt“ eventuell Potenziale für eine Fehlinterpretation enthält.

        @Jan: Auch wenn ich Dein Tutorial gar nicht genutzt habe – die Ressource ist klasse, viele (richtige) Informationen gut aufbereitet. Instant Bookmark!

  • Wolfgang sagt:

    Hallo Jan,
    ich habe den Server vor einigen Wochen von Ubuntu18 auf 20 angehoben. Alles lief auch einwandfrei. Gestern habe ich den Server neu gestartet und bekomme nun die FM: „Can’t connect to local MySQL server through socket ‚/var/run/mysqld/mysqld.sock'“. Die Datei ist nicht im genannten Verzeichnis zu finden. MariaDB kann nicht mehr gestartet werden.
    Hast du eine Idee?
    Gruß
    Wolfgang

    • Jan sagt:

      Hi Wolfgang,

      die Aussage „MariaDB konnte nicht gestartet werden“ ist hier etwas dürftig. Was kommen denn für Fehler im Log?

      Gruß,
      Jan

      • Wolfgang sagt:

        Hallo Jan,
        ich finde folgende Meldungen:
        Job for mariadb.service failed because a fatal signal was delivered causing the control process to dump core.
        Dann unter systemctl status mariadb.service:
        Process: 2222291 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=dumped, signal=ABRT)
        Main PID: 2222291 (code=dumped, signal=ABRT)
        Und unter journalctl -xe:
        Jan 11 20:10:17 nextcloud sshd[2225251]: pam_unix(sshd:auth): check pass; user unknown
        Jan 11 20:10:17 nextcloud sshd[2225265]: Received disconnect from 121.139.69.202 port 46696:11: Bye Bye [preauth]
        Jan 11 20:10:17 nextcloud sshd[2225265]: Disconnected from authenticating user root 121.139.69.202 port 46696 [preauth]
        Jan 11 20:10:18 nextcloud sshd[2225267]: Received disconnect from 180.76.175.234 port 36638:11: Bye Bye [preauth]
        Jan 11 20:10:18 nextcloud sshd[2225267]: Disconnected from invalid user panel 180.76.175.234 port 36638 [preauth]
        Jan 11 20:10:18 nextcloud kernel: ata1.00: exception Emask 0x0 SAct 0x2000 SErr 0x0 action 0x0
        Jan 11 20:10:18 nextcloud kernel: ata1.00: irq_stat 0x40000008
        Jan 11 20:10:18 nextcloud kernel: ata1.00: failed command: READ FPDMA QUEUED
        Jan 11 20:10:18 nextcloud kernel: ata1.00: cmd 60/20:68:e0:35:bc/00:00:00:00:00/40 tag 13 ncq dma 16384 in
        res 41/40:20:e8:35:bc/00:00:00:00:00/00 Emask 0x409 (media error)
        Jan 11 20:10:18 nextcloud kernel: ata1.00: status: { DRDY ERR }
        Jan 11 20:10:18 nextcloud kernel: ata1.00: error: { UNC }
        Jan 11 20:10:18 nextcloud kernel: ata1.00: configured for UDMA/133
        Jan 11 20:10:18 nextcloud kernel: sd 1:0:0:0: [sdb] tag#13 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
        Jan 11 20:10:18 nextcloud kernel: sd 1:0:0:0: [sdb] tag#13 Sense Key : Medium Error [current]
        Jan 11 20:10:18 nextcloud kernel: sd 1:0:0:0: [sdb] tag#13 Add. Sense: Unrecovered read error – auto reallocate failed
        Jan 11 20:10:18 nextcloud kernel: sd 1:0:0:0: [sdb] tag#13 CDB: Read(10) 28 00 00 bc 35 e0 00 00 20 00
        Jan 11 20:10:18 nextcloud kernel: blk_update_request: I/O error, dev sdb, sector 12334568 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
        Jan 11 20:10:18 nextcloud kernel: ata1: EH complete
        Jan 11 20:10:19 nextcloud systemd[1]: mariadb.service: Main process exited, code=dumped, status=6/ABRT
        — Subject: Unit process exited
        — Defined-By: systemd
        — Support: http://www.ubuntu.com/support

        — An ExecStart= process belonging to unit mariadb.service has exited.

        — The process‘ exit code is ‚dumped‘ and its exit status is 6.
        Jan 11 20:10:19 nextcloud systemd[1]: mariadb.service: Failed with result ‚core-dump‘.
        — Subject: Unit failed
        — Defined-By: systemd
        — Support: http://www.ubuntu.com/support

        — The unit mariadb.service has entered the ‚failed‘ state with result ‚core-dump‘.
        Jan 11 20:10:19 nextcloud systemd[1]: Failed to start MariaDB 10.3.25 database server.
        — Subject: A start job for unit mariadb.service has failed
        — Defined-By: systemd
        — Support: http://www.ubuntu.com/support

        — A start job for unit mariadb.service has finished with a failure.

        — The job identifier is 805738 and the job result is failed.
        Jan 11 20:10:19 nextcloud sshd[2225251]: Failed password for invalid user usuario from 173.202.155.247 port 44682 ssh2
        Hilft das weiter?
        Grß
        Wolfgang

        • Jan sagt:

          Hi Wolfgang,

          hier sehe ich auch keinen direkten Fehler, bzw, die Meldung ist wenig aussagekräftig. Du könntest mal ausprobieren, MariaDB zu deinstallieren (mit „remove“, nicht „purge“!) und neu zu installieren. Die DBs sollten dabei erhalten bleiben.

          Gruß,
          Jan

  • sommersonnekaktus sagt:

    Hej,

    ich wollte mich für die großartige Anleitung bedanken!
    Ich hatte bisher nur ein einziges mal einen jitsi server auf einem alten Laptop aufgesetzt um mir anzugucken wie so etwas überhaupt funktioniert. Mit Hilfe deiner Anleitung habe jetzt auf einem alten Dell All-in One PC hinterm Sofa eine Nextcloud-Instanz laufen, die im ganzen Freundeskreis (auch viele Menschen, die nicht so informatikaffin sind täglich genutzt wird. Ich wurde sogar schon angesprochen, ob und wie das denn eigentlich möglich wäre, nextcloud auch in anderen Zusammenhängen zu nutzen, weil „das alles mit Google zu machen ist ja eigentlich nicht so gut…“. :D

    Deine Erklärungen sind genau so ausführlich, dass ich dabei richtig viel gelernt habe und sogar motiviert war mich noch weiter in die Details reinzuarbeiten, aber nicht so ausschweifend, dass ich abgeschreckt war und die „wall of text“ weggeklickt habe. Vielen Dank für die Mühe und die Arbeit die du da reingesteckt hast. Du hast mehreren Menschen ein nützlichen Tool zugänglich gemacht, dass das Leben signifikant besser und leichter macht und endlose Möglichkeiten bietet.

    Danke!

  • Gast sagt:

    Hallo,
    ich habe versucht, die Nextcloud, wie im alten Artikel, in enem Unterverzeichnis zu installieren, bin dabei aber aber an die Grenzen meiner Linux Kenntnisse gestossen. Die X- header kommen nicht im Browser an, obwohl sie in den .conf Dateien eingebunden sind. Ich habe sowohl die neue Variante, mit den snippets, als auch die Alte, wo die header direkt in der .conf stehen. Error.log zeigt beim Aufruf einer Seite nichts. Gibt es einen Anhaltspunkt oder eine Einstellung, die ich außer Acht gelassen haben könnte? Ich habe vorher die obige Anleitung komtplett durchgearbeitet und danach gab es keinerlei Probleme – erst im unterverzeichnis.
    LG

    • Jan sagt:

      Hi,

      versuch mal die Header nicht per nginx zu setzen. Denn wenn Header doppelt gesetzt werden, werden diese gerne mal ignoriert und das wird dann angemeckert.

      Gruß,
      Jan

  • Gnan sagt:

    Hallo
    Super Anleitung. Danke.
    folgende Fehlermeldungen sind bei mir auf der Nextcloud Seite noch zu sehen. Alle anderen Fehlermeldungen sind nach deiner ANleitung behoben.

    – Dein Web-Server ist nicht richtig eingerichtet um „/.well-known/caldav“ aufzulösen. Weitere Informationen findest Du in der Dokumentation.
    – Dein Web-Server ist nicht richtig eingerichtet um „/.well-known/carddav“ aufzulösen. Weitere Informationen findest Du in der Dokumentation.

    Kannst du mir sagen, wo der Fehler liegt?

    • Jan sagt:

      Hi,

      damit diese Meldungen weg gehen, muss auf der Root-Domain der DAV-Endpunkt mit den genannten Well-Known-URLs erreichbar sein. Hier stimmt also vermutlich etwas mit der Webserver-Konfiguration nicht so ganz.
      Das ist meines Wissens nach aber nur für Mac-Clients interessant. Dies ist also nur als Warnung und nicht als echter Fehler zu verstehen. Wenn du keine Apple-Geräte einsetzt, dann kannst du die Meldungen auch genau so gut ignorieren.

      Gruß,
      Jan

      • Bernhard Gnan sagt:

        Hallo,

        danke für die Info.
        ich habe den Server Ubuntu Server ganz neu installiert, auch Nginx usw genau nach der Anleitung. Ich finde hier den fehler nicht. In welcher Conf-Datei würden Sie sagen, dass der Fehler sein muss?

        Danke

        Gruß

        Gnan

        • Jan sagt:

          Hi,

          das müsste dann der vHost seiner Nextcloud-Installation sein (also unter /etc/nginx/conf.d/).
          Du kannst die Well-Known-URLs auch mal im Browser aufrufen und dann im Webserver-Log (/var/log/nginx/error.log) schauen, ob hier irgendwelche Fehler kommen.

          Gruß,
          Jan

  • Jens Walter sagt:

    Hallo Jan,
    erstmal besten Dank für Deine tolle Anleitung! Bei mir hat auch alles gut geklappt und ich war sehr zufrieden. Dann ist mir leider die Root Partition mit Backups voll gelaufen. Dabei wird wohl die /var/www/nextcloud/config/config.php zerstört. Das war bei mir auch der Fall. Da ich noch keine Sicherung gemacht hatte, habe ich /var/www/nextcloud/, den Nextclouddatenordner und die Datenbank gelöscht und wollte alles neu installieren.
    Das hat auch geklappt, aber die Neuinstallation ist unfassbar langsam. Eigentlich bin ich mir ziemlich sicher, dass ich die Erstellung der Datenbank und die Installation mit den Rechten richtig gemacht habe. Hast Du eine Idee, wo ich suchen könnte?
    Besten Dank und schöne Grüße!
    Jens

    • Jan sagt:

      Hallo Jens,

      Performance-Probleme sind leider schwierig ausfindig zu machen. Wenn die Nextcloud an sich funktioniert und es keine Fehler/Warnungen in der Admin-UI gibt, dann würde ich mal darauf tippen, dass die Konfiguration korrekt ist.
      Evtl. kann es aber auch sein, dass eine andere Systemkomponente einen Treffer hat und das Volllaufen der Partition nicht schadlos überstanden hat.
      Ich würde hier zunächst mal die Auslastung des Systems beobachten und sämtliche Logs checken, ob hier was Auffälliges zu finden ist.

      Gruß,
      Jan

  • Jürgen Gohl sagt:

    Hallo Jan,

    vielen Dank für diese Super Anleitung! Ich habe aber eine Anmerkung. In deiner /etc/nginx/conf.d/nextcloud.meinedomain.de.conf würde ich die Zeile 85 ( location ~ ^\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+)\.php(?:$|\/) { )
    hierhin >
    ( location ~ ^\/nextcloud\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy)\.php(?:$|\/) { )
    abändern.
    Warum? Weil bei der Installation standardmäßig der Haken bei „Empfohlene Apps Installieren“ aktiviert ist und das Collabora Online Office samt Collabora Online – Built-in CODE Server installiert wird. Jetzt ist der Built-in CODE Server aber nicht erreichbar und die Benutzung seeeeehhhhr langsam.
    Dieses konnte ich auf mehrere Rechnern reproduzieren.

    Hier noch die Quelle meiner Recherche : https://www.collaboraoffice.com/online/connecting-collabora-online-built-in-code-server-with-nginx/

    MFG Jürgen

    • Jan sagt:

      Hi Jürgen,

      danke für den Hinweis!
      Allerdings bin ich kein Fan der „integrierten“ Lösung, da diese Erfahrungsgemäß nicht so stabil läuft. Hier empfehle ich immer noch die Nutzung per Docker, siehe hier.

      Ich habe den Artikel aber trotzdem mal dahingehend angepasst.

      Gruß,
      Jan

  • Philesiv sagt:

    Hallo,

    erstmal danke für deine ausführliche Anleitung!
    Ich bekam gerade, nach dem aktivieren von Redis, einen internen Server Error von Nextcloud. Anscheinend hat das Paket php-memcache gefehlt (https://help.nextcloud.com/t/cannot-setup-and-configure-redis-for-memory-caching-internal-server-error/72793). Nach der Installation funktioniert jetzt wieder alles. Vielleicht kannst du das noch in deinem Tutorial ergänzen :)

    Viele Grüße

    • Jan sagt:

      Hi,

      in diesem Tutorial nutze ich APCu für den lokalen Memcache. Hier wird das Paket eigentlich nicht benötigt. Scheint nur notwendig zu sein, wenn für den lokalen Memcache Redis genutzt wird.

      Gruß,
      Jan

      • Philesiv sagt:

        Hallo,

        ich habe eigentlich fast alle Einstellungen von dir übernommen und benutze auch APCu als lokalen Memcache. Trotzdem ging die Nextcloud bei mir nicht mehr sobald ich ‚memcache.locking‘ auf redis gestelt habe.

  • Manuel sagt:

    Hallo und vielen Dank für die Anleitung.

    Bei mir läuft ein Reverse Proxy und die SSL Zertifikat Erstellung auf einem anderen Server.

    Wie würde dann eine Nginix Konfiguration aussehen ?
    Virtueller Host ohne SSL.

    Kannst du oder jemand mit hier weiterhelfen ?

    Vielen Dank

    • Jan sagt:

      Hi Manuel,

      genau, normalerweise findet die „SSL-Terminierung“ am Proxy statt. An diesem vHost findet dann einfach nur eine Weiterleitung an das „Backend“ statt. Im Nextcloud-Backend wird dann ein vHost aufgesetzt, der dem aus dem Tutorial ziemlich gleicht, aber nur per HTTP/Port 80 erreichbar ist.
      Bei Bedarf kann aber auch der Backend-Server per HTTPs abgesichert werden: Hier nimmt man dann am besten selbst signierte Zertifikate, da ja nur der „Frontend-Proxy“ direkt an das Internet angebunden ist und die echten TLS-Zertifikate über Let’s Encrypt ausstellen kann.

      Gruß,
      Jan

      • Manuel sagt:

        Hi Jan und vielen Dank für deine Antwort.
        Hab alles mögliche getestet, komme hier jedoch einfach nicht weiter.

        Einen Proxy habe ich bereits installiert und wird auch für WordPress mit SSL Verschlüsselung usw verwendet.

        Problem ist für mich die vHost Datei des Backend für das Nginx der Nextcloud.

        Aus deiner Anleitung oben: nano /etc/nginx/conf.d/nextcloud.meinedomain.de.conf

        Hast du mir dazu ein Beispiel für meinen Anwendungsfall ?

        Da ich die Nextcloud Seite nicht aufrufen kann, ist bei mir auch noch keine /var/www/nextcloud/config/config.php vorhanden.

        Führt das zu Problemen ?

        Grüße
        Manuel

        • Jan sagt:

          Hi Manuel,

          die nextcloud.meinedomain.de.conf ist eigentlich genau gleich, nur dass eben rein auf HTTP gesetzt wird.
          Schau mal in die Logs (vermutlich eher auf dem Backend). Ohne „richtige“ Fehlermeldung wird es schwierig, das Problem zu analysieren.

          Gruß,
          Jan

      • Manuel sagt:

        Hi Jan,

        vielen Dank für die Antwort.
        Leider komme ich hier nicht weiter.

        Proxyserver mit Zertifikat Erstellung läuft bereits auf einem anderen Server für andere Anwendungen ohne Probleme.

        Mit der vHost aus deinem Beispiel funktioniert es leider nicht, obwohl ich den SSL part und den Prot auf 8080 umgestellt habe.

        Fehler beim Anruf der Website:
        Internal Server Error

        The server encountered an internal error and was unable to complete your request.
        Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
        More details can be found in the webserver log.

        Hast du mir vielleicht eine Beispiel vHost Datei ?

        Nextcloud Setup ist noch nicht gelaufen, bedeutet, es ist noch keine config.php vorhanden.

        Grüße
        Manuel

        • Jan sagt:

          Hi Manuel,

          du kommst also anscheinend schon an der Nextcloud-Maschine raus. Das ist erst einmal gut.
          Eigentlich müsste es reichen, alles mit Zertifikaten/SSL/Headern am Proxy zu behandeln. Dann einen allgemeinen location block (location / { ... }), der dann einen proxy_pass auf das Backend vornimmt.
          Einen Beispiel-vHost habe ich nun leider nicht zur Hand. Hier sollte aber ein Blick in die Webserver-Logs (Proxy und Backend) helfen, hier sollten Meldungen enthalten sein, mit denen sich das Problem eingrenzen lassen sollte.

          Gruß,
          Jan

  • Rene sagt:

    Hallo Jan,

    danke für deine ausführliche Anleitung, ich frag mich wirklich immer wie man sowas so schön erklären kann. Auch der rote Faden in deiner Anleitung ist wirklich klar zu erkennen.
    Doch habe ich ein Problem, ich bin an der Stelle wo ich zum ersten Mal meine nextcloud.domain.de im Browser aufrufe und dann kommt das hier:

    Anmerkung: xxx.xxx.xxx.xxx steht jedes Mal für die Ip-Adresse meines Routers

    Interner Serverfehler
    Der Server konnte die Anfrage nicht fertig stellen.
    Sollte dies erneut auftreten, sende bitte die nachfolgenden technischen Einzelheiten an Deinen Server-Administrator.
    Weitere Details können im Server-Protokoll gefunden werden.
    Technische Details
    • Entfernte Adresse: xxx.xxx.xxx.xxx
    • Anfragekennung: J4YtCIbyIvwV7Oxet4k6

    Wenn ich mir dann die Error.log anschaue bekomme ich folgende Fehlermeldung.
    Wäre echt super cool, wenn du vielleicht eine Idee hättest woran es liegen könnte?
    Ich danke dir an dieser Stelle schon mal für deine Antwort.

    Error.log
    2021/02/04 16:52:06 [notice] 3839#3839: signal process started
    2021/02/04 16:54:13 [notice] 4693#4693: signal process started
    2021/02/04 17:26:47 [error] 4940#4940: *6 FastCGI sent in stderr: „PHP message: {„reqId“:“1zcYGEvn6shp86HZcnFI“,“level“:3,“time“:“2021-02-04T16:26:47+00:00″,“remoteAddr“:“xxx.xxx.xxx.xxx“,“user“:“–„,“app“:“PHP“,“method“:“GET“,“url“:“/“,“message“:{„Exception“:“Error“,“Messag>
    2021/02/04 17:26:47 [error] 4940#4940: *6 FastCGI sent in stderr: „Evn6shp86HZcnFI“,“level“:3,“time“:“2021-02-04T16:26:47+00:00″,“remoteAddr“:“xxx.xxx.xxx.xxx“,“user“:“–„,“app“:“index“,“method“:“GET“,“url“:“/“,“message“:{„Exception“:“Doctrine\\DBAL\\DBALException“,“Message“>
    2021/02/04 17:26:47 [error] 4940#4940: *6 FastCGI sent in stderr: „PHP message: {„reqId“:“1zcYGEvn6shp86HZcnFI“,“level“:3,“time“:“2021-02-04T16:26:47+00:00″,“remoteAddr“:“xxx.xxx.xxx.xxx“,“user“:“–„,“app“:“PHP“,“method“:“GET“,“url“:“/“,“message“:“fopen(/var/www/nextcloud/da>
    2021/02/04 17:29:15 [error] 5003#5003: *1 FastCGI sent in stderr: „PHP message: {„reqId“:“o4bDelHuR3cP6xjsnYxa“,“level“:3,“time“:“2021-02-04T16:29:15+00:00″,“remoteAddr“:“xxx.xxx.xxx.xxx“,“user“:“–„,“app“:“PHP“,“method“:“GET“,“url“:“/“,“message“:{„Exception“:“Error“,“Messag>
    2021/02/04 17:29:15 [error] 5003#5003: *1 FastCGI sent in stderr: „lHuR3cP6xjsnYxa“,“level“:3,“time“:“2021-02-04T16:29:15+00:00″,“remoteAddr“:“xxx.xxx.xxx.xxx“,“user“:“–„,“app“:“index“,“method“:“GET“,“url“:“/“,“message“:{„Exception“:“Doctrine\\DBAL\\DBALException“,“Message“>
    2021/02/04 17:29:15 [error] 5003#5003: *1 FastCGI sent in stderr: „PHP message: {„reqId“:“o4bDelHuR3cP6xjsnYxa“,“level“:3,“time“:“2021-02-04T16:29:15+00:00″,“remoteAddr“:“xxx.xxx.xxx.xxx“,“user“:“–„,“app“:“PHP“,“method“:“GET“,“url“:“/“,“message“:“fopen(/var/www/nextcloud/da>
    2021/02/04 17:32:32 [error] 5003#5003: *3 FastCGI sent in stderr: „PHP message: {„reqId“:“d8ecgaPhc1b6xCx628hm“,“level“:3,“time“:“2021-02-04T16:32:32+00:00″,“remoteAddr“:“xxx.xxx.xxx.xxx“,“user“:“–„,“app“:“PHP“,“method“:“GET“,“url“:“/“,“message“:{„Exception“:“Error“,“Messag>
    2021/02/04 17:32:32 [error] 5003#5003: *3 FastCGI sent in stderr: „aPhc1b6xCx628hm“,“level“:3,“time“:“2021-02-04T16:32:32+00:00″,“remoteAddr“:“xxx.xxx.xxx.xxx“,“user“:“–„,“app“:“index“,“method“:“GET“,“url“:“/“,“message“:{„Exception“:“Doctrine\\DBAL\\DBALException“,“Message“>
    2021/02/04 17:32:32 [error] 5003#5003: *3 FastCGI sent in stderr: „PHP message: {„reqId“:“d8ecgaPhc1b6xCx628hm“,“level“:3,“time“:“2021-02-04T16:32:32+00:00″,“remoteAddr“:“xxx.xxx.xxx.xxx“,“user“:“–„,“app“:“PHP“,“method“:“GET“,“url“:“/“,“message“:“fopen(/var/www/nextcloud/da>

    • Jan sagt:

      Hi Rene,

      das Log ist teilweise abgeschnitten, aber es sieht so aus, dass es ein Problem beim Zugriff auf die Datenbank gibt. Also würde ich erst einmal an dieser Stelle kontrollieren.

      Gruß,
      Jan

  • Thomas Zimmermann sagt:

    Hi Jan,

    estmal großes lob an dich für das erstklassige How-Too.

    da ich mir einen neuen Server zugelegt habe, habe ich mir gedacht ich setzte Nc mal neu auf, hat auch alles geklappt und lauft sehr gut, bis auf eine Sache und zwar wenn ich PDF Dateien aus einem SMB Share öffnen will geht der CPU Load extrem hoch und es dauert je nach Datei 2 min bis diese geöffnet wird, woran könnte das liegen an den technischen spec. kann es nicht liegen. ssd 32gb ram 4kerne usw. Seitenaufbau geht ratz fatz.

    gruß
    Thomas

    • Jan sagt:

      Hi Thomas,

      das lässt sich pauschal leider nicht beantworten. Hier würde ich verschiedenen ausprobieren, um den „Übeltäter“ ausfindig zu machen:
      Was passiert, wenn du andere Dateiarten vom SMB-Share öffnest? Ist das dann auch langsam?
      Was passiert, wenn du PDF Dateien lokal öffnest (also nicht über den SMB-Share gehst)?

      Gruß,
      Jan

      • Thomas Zimmermann sagt:

        HI Jan,

        Also ich habe es etwas lokalisieren können es liegt an der External Storage APP in Verbindung mit SMB Client, PDF daten mit 100mb wenn ich hochlade kein Problem auch beim öffnen nicht, an der Anbindung kann es auch nicht liegen 4GBits’s. Git es da Punkte wo man schauen kann ?

        Gruß
        Thomas

        • Jan sagt:

          Hi Thomas,

          welche Optionen sind denn aktiv für den externen Speicher (die drei Punkte ganz rechts beim Einbinden des Storages)?
          Klingt mir aber eher wie ein Bug o.ä. Dazu am besten mal einen Issue bei GitHub aufmachen.

          Gruß,
          Jan

          • Thomas Zimmermann sagt:

            Hi Jan,

            also ich habe das Problem “ lösen “ können, warum und Wiso das jetzt geht kann ich leider nicht sagen oder wie das im Hintergrund zusammenspielt, und zwar habe ich in den Optionen vom Share die Vorschau ausgeschaltet und schon geht’s wieder Flüssig habe zudem nach die alte nc als Backup eingebunden um die Einstellungen zu vergleichen da geht es mit Vorschau wobei das die Standard Einstellung ist.

            Gruß
            Thomas

  • Claudius sagt:

    Hallo Jan,

    seit etwa einem Jahr läuft meine Nextcloud nach deiner Anleitung.
    Vor kurzem ergab sich aber das Problem, dass sich Ubuntu nicht mehr updaten ließ (unmet dependencies …). Grund war ein Problem mit den MariaDB-Fremdquellen. Ich musste MariaDB de- und wieder neuinstallieren um das Problem zu beheben (zum Glück ohne Datenverlust).
    Als Einsteiger habe ich damals Dein Tutorial 1:1 befolgt; inkl. Fremdquellen. Zwar erklärst Du sehr gut die unterschiedlichen Branches und den Sinn, „stable“ zu nutzen, aber auch beim Nachlesen fehlt mir der Hinweis auf die möglichen Komplikationen. Gerade Einsteigern wird in Linux-Tutorials von Fremdquellen abgeraten, wie ich mittlerweile weiß.
    Das soll jetzt weniger Kritik sein, als dass ich andere Nutzer vor dem Problem bewahren will, das ich hatte.
    Vielleicht wäre also ein Hinweis dazu in Deinem (tollen!) Tutorial gut!?
    Und vielleicht sogar eine Anleitung (eigenes Tutorial?) wie man die Paketquelle nachträglich ändert, falls das geht!?

    Vielleicht finden das auch anderen hilfreich.
    Viele Grüße und Gesundheit!
    Claudius

    • Jan sagt:

      Hi Claudius,

      hier hatte ich (besonders mit den MariaDB-Paketquellen) noch nie ein Problem.
      Eigentlich sollte da aber apt remove mariadb-*, anschließend ein Update der Paketquellen (z.B. von 10.3 auf 10.5) und ein Neuinstallieren der benötigten Pakete ausreichen. Nur /var/mysql sollte nicht angefasst werden, da hier die Dateien der DB liegen. Diese werden nach einem Update aber auch wieder gefunden.
      Welche Dependencies konnte er bei dir denn konkret nicht mehr finden?

      Gruß,
      Jan

      • Claudius sagt:

        Hallo Jan,

        ich habe die ganze Situation im Startposting hier zusammengefasst: https://forum.ubuntuusers.de/topic/unerfuellte-abhaengigkeiten-versch-versionen-v/

        Was da genau schiefgelaufen ist verstehe ich nicht. Scheinbar hatte sich mein Server einmal bei Canonical und einmal bei MariaDB bedient?

        Aber wo Du 10.3 und 10.5 ins Spiel bringst: Ich erinnere mich, meine Installation nach deiner Anleitung für Ubuntu 18.0.4 gemacht zu haben (20.0.4 war schon draußen, deine neue Anleitung aber noch nicht) und lediglich „bionic“ gegen „focal“ getauscht zu haben. Das heißt, ich habe MariaDB 10.3 installiert (weil ich auch gar nicht recherchiert hatte, dass es 10.5 schon gab).
        Aber auch 10.3 findet man als offiziell supportet bei MariaDB, deswegen wundert mich trotzdem, dass es hier Fehler gibt.

        Dazu noch eine Frage: Wenn ich die MariaDB-Quellen je nach Version angeben muss, wie bekomme ich dann mit, wenn es eine neue Version gibt, bzw. dass die installierte Version nicht mehr supportet wird?

        Gruß
        Claudius

        • Jan sagt:

          Hi Claudius,

          ich schau hin und wieder beim MariaDB Repo Tool vorbei. Hier taucht hin und wieder eine neue Version auf, die als [Stable] gekennzeichnet ist. Trotzdem besteht hier kein dringender Handlungsbedarf, wenn du noch auf einer „Old Stable“ Version bist. Diese werden weiterhin supported.

          Gruß,
          Jan

          • Claudius sagt:

            Hallo Jan,

            danke, die Seite kenne ich sogar schon. Ich fände es als fauler Mensch halt schöner, wenn sich MariaDB über die Ubuntu-Oberfläche, melden würde. Naja, ab und an da mal nachzuschauen kriegt man schon hin.

            Nochmal kurz zum Quellen-Wechsel:
            Die Deinstallation über apt -remove hatte damals nicht funktioniert (Details im o. g. Thread), ich musste erst über dpkg gehen. Das wirkt auf mich schon wieder nicht ganz so einfach und verwirrte mich auch etwas, weil ich danach doch noch apt – remove nutzen musste. Ich hätte erwartet, dass nach dpkg -purge alle Pakete weg wären.
            Da werde ich mich nochmal einlesen müssen.

            Gruß
            Claudius

  • Peter sagt:

    Hallo Jan
    vielen Dank für Deine Arbeit.
    Hat Alles wunderbar geklappt.
    Nun habe ich noch das Problem, dass ich LDAP nicht ans Laufen bekomme.
    Auf einem anderen Server von mir, jedoch nach anderer Anleitung aufgesetzt läuft es einwandfrei.
    Ich benötige LDAP in meiner Umgebung, da Windows AD bereits aktiv ist und ich nicht die User doppelt verwalten möchte.
    Danke für deine Anregungen.
    Lg
    Peter

    • Jan sagt:

      Hi Peter,

      ohne Fehlermeldung o.ä. wird es hier schwierig. Das Paket php-ldap hast du installiert? Das ist für die LDAP-Integration Voraussetzung.

      Gruß,
      Jan

      • Peter sagt:

        Hallo Jan
        ja, php-idap ist installiert und auch akriviert.

        Alleine schon wenn ich auf die Port-Suche gehe orgelt ohne ende.
        Gibt es irgendwo ein Fehlerprotokoll, wo ich nachschauen kann?
        Danke
        LG
        Peter

        • Jan sagt:

          Hi Peter,

          in der LDAP-App gibt es keine Fehler-/Hinweismeldungen?
          Ansonsten würde ich erst einmal in das Nextcloud-Log schauen.

          Gruß,
          Jan

          • Peter sagt:

            Hallo Jan

            danke für deine Hilfe.
            Ich kann in den logs nichts erkennen.
            Ich denke es liegt an den geänderten Pfaden der Certificate und nginx.

            Ich habe das ganze nun wieder unter Apache laufen u. es funzt.

            Vielleicht hast du ja noch einen Ansatz. Habe auch im Netz bisher nichts gefunden.

            Gruss
            Peter

          • Jan sagt:

            Hi,

            OK, dann muss man weiter suchen. Was ergibt ein Ping vom Server selbst auf die Cloud-Domain? Wird die IP korrekt aufgelöst?

            Gruß,
            Jan

  • Sebastian sagt:

    Moin!
    Habe gestern meinen Raspberry mit den Kommandos:
    „apt update && apt upgrade -V && apt dist-upgrade && apt autoremove“
    auf den neuesten Stand gebracht. Ich dachte, ich muss nur die PHP-Dateien wieder anpassen, aber anscheinend ist dem nicht so!
    Leider hat es mir so ziemlich alles zerschossen und ich komme nicht mehr auf meine Nextcloud. Es sieht fast so aus, als wären alle Nginx-Configs verschwunden…
    Kann mir jemand weiterhelfen? Muss ich die Nextcloud neu aufsetzen? Komme ich noch irgendwie an meine Daten / Kontakte / Kalender heran?
    Besten Dank im Voraus für euren Support / Tipps wo ich anfangen kann…

    • Jan sagt:

      Hi Sebastian,

      was kam denn bei dem Update alles mit?
      Neu aufsetzen musst du die Cloud vermutlich nicht, die sollte ja noch da sein. Hier würde ich mich „von außen nach innen“ vorarbeiten und alles Stück für Stück kontrollieren: Webserver, PHP, DB, NC.
      Auch ein Blick in die Logs kann u.U. helfen, das Problem einzugrenzen.

      Gruß,
      Jan

      • Sebastian sagt:

        Gute Frage – es war jedenfalls einiges. Es kamen 2 Warnungen, dass die PHP Dateien geändert werden (die habe ich aber sofort manuell wieder auf den Stand in deinem Guide gebracht). Ansonsten scheint noch alles beim alten zu sein – meine Nginx conf Dateien sind noch da (hatte im falschen Ordner /conf.d anstatt /sites-enabled gesucht)

        Die Fehlermeldung bei Aufruf der Nextcloud:
        „Internal Server Error
        The server encountered an internal error and was unable to complete your request.
        Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
        More details can be found in the server log.“

        Das Nextcloud-Error-Log ist picke-packe-voll. Aus den Nginx-Logs geht (für mich) nur wenig hervor. Es scheint, als würden sämtliche Anfragen abgelehnt werden. Eventuell kann von euch jemand was damit anfangen? An den Berechtigungen hat sich nichts geändert. Muss ich die letsencrypt Zertifikate irgendwie aktualisieren?

        2021/02/18 09:34:56 [error] 590#590: *7429 access forbidden by rule, client: 45.zzz.zzz.zzz, server: cloud.meinedomain.de, request: „GET /console/ HTTP/1.1“, host: „149.xxx.xxx.xxx“, referrer: „http://149.xxx.xxx.xxx:80/console/“
        2021/02/18 16:53:03 [error] 590#590: *9343 access forbidden by rule, client: 45.zzz.zzz.zzz, server: cloud.meinedomain.de, request: „GET /console/ HTTP/1.1“, host: „149.xxx.xxx.xxx:443“
        2021/02/19 00:52:15 [crit] 590#590: *11399 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 192.yyy.yyy.yyy, server: 0.0.0.0:443
        2021/02/19 03:58:00 [error] 590#590: *12149 access forbidden by rule, client: 45.zzz.zzz.zzz, server: cloud.meinedomain.de, request: „GET /console/ HTTP/1.1“, host: „149.xxx.xxx.xxx“, referrer: „http://xxx.xxx.xxx.xxx:80/console/“
        2021/02/19 08:57:22 [error] 590#590: *13432 access forbidden by rule, client: 45.zzz.zzz.zzz, server: cloud.meinedomain.de, request: „GET /console/ HTTP/1.1“, host: „149.xxx.xxx.xxx:443“
        2021/02/19 13:53:57 [warn] 471#471: „ssl_stapling“ ignored, host not found in OCSP responder „r3.o.lencr.org“ in the certificate „/etc/letsencrypt/cloud.meinedomain.de/ecc/fullchain.pem“
        2021/02/19 13:53:57 [warn] 471#471: „ssl_stapling“ ignored, host not found in OCSP responder „r3.o.lencr.org“ in the certificate „/etc/letsencrypt/cloud.meinedomain.de/rsa/fullchain.pem“
        2021/02/19 13:53:57 [warn] 471#471: „ssl_stapling“ ignored, host not found in OCSP responder „r3.o.lencr.org“ in the certificate „/etc/letsencrypt/blog.meinedomain.de/ecc/fullchain.pem“
        2021/02/19 13:53:57 [warn] 471#471: „ssl_stapling“ ignored, host not found in OCSP responder „r3.o.lencr.org“ in the certificate „/etc/letsencrypt/blog.meinedomain.de/rsa/fullchain.pem“
        2021/02/19 13:53:57 [warn] 558#558: „ssl_stapling“ ignored, host not found in OCSP responder „r3.o.lencr.org“ in the certificate „/etc/letsencrypt/cloud.meinedomain.de/ecc/fullchain.pem“
        2021/02/19 13:53:57 [warn] 558#558: „ssl_stapling“ ignored, host not found in OCSP responder „r3.o.lencr.org“ in the certificate „/etc/letsencrypt/cloud.meinedomain.de/rsa/fullchain.pem“
        2021/02/19 13:53:57 [warn] 558#558: „ssl_stapling“ ignored, host not found in OCSP responder „r3.o.lencr.org“ in the certificate „/etc/letsencrypt/blog.meinedomain.de/ecc/fullchain.pem“
        2021/02/19 13:53:57 [warn] 558#558: „ssl_stapling“ ignored, host not found in OCSP responder „r3.o.lencr.org“ in the certificate „/etc/letsencrypt/blog.meinedomain.de/rsa/fullchain.pem“

        • Jan sagt:

          Hi Sebastian,

          irgendwas versucht hier auf cloud.meinedomain.de/console zuzugreifen. Das sieht mir nicht nach Nextcloud aus.
          Die anderen Sachen mit SSL sollten führen hier nicht zu einem Verbindungsabbruch, sonst würde hier auch die Nextcloud-Fehlerseite nicht angezeigt werden. Zertifikate sollten noch gültig sein und müssen nicht erneuert werden, sonst würdest du ebenfalls nicht ohne Warnung im Browser soweit kommen.
          Aus diesem Log ist der Fehler nicht ersichtlich, hier musst du wohl ins Nexcloud-Logs schauen und den Fehler hier suchen.

          Gruß,
          Jan

          • Sebastian sagt:

            Hey Jan,
            vielen vielen Dank für deine schnellen Antworten! :)

            Das NC Log zeigt eigentlich immer die gleichen Fehler an (leider wird keione der Meldungen komplett dargestellt in nano…). Den vorderen Teil mit Uhrzeit und reqID hab ich weggelassen.

            „app“:“remote“,“method“:“GET“,“url“:“/status.php“,“message“:{„Exception“:“Doctrine\\DBAL\\DBALException“,“Message“:“$
            „app“:“PHP“,“method“:“GET“,“url“:“/status.php“,“message“:“You are using a fallback implementation of the intl extens$
            „app“:“PHP“,“method“:“PROPFIND“,“url“:“/remote.php/dav/files/Sebbe/“,“message“:“Error: Class ‚OCA\\DAV\\Connector\\S$
            „app“:“PHP“,“method“:“PROPFIND“,“url“:“/remote.php/dav/files/Sebbe/“,“message“:“You are using a fallback implementat$
            „app“:“PHP“,“method“:“PROPFIND“,“url“:“/remote.php/dav/files/Sebbe/“,“message“:“Error: Class ‚OCA\\DAV\\Connector\\S$
            „app“:“PHP“,“method“:“PROPFIND“,“url“:“/remote.php/dav/files/Sebbe/“,“message“:“You are using a fallback implementat$
            „app“:“remote“,“method“:“PROPFIND“,“url“:“/remote.php/dav/addressbooks/users/Sebbe/contacts/“,“message“:{„Exception“$
            „app“:“core“,“method“:“PROPFIND“,“url“:“/remote.php/dav/addressbooks/users/Sebbe/contacts/“,“message“:{„Exception“:“$
            „app“:“core“,“method“:“PROPFIND“,“url“:“/remote.php/dav/addressbooks/users/Sebbe/contacts/“,“message“:{„Exception“:“$
            „app“:“PHP“,“method“:“PROPFIND“,“url“:“/remote.php/dav/addressbooks/users/Sebbe/contacts/“,“message“:“You are using $
            „app“:“remote“,“method“:“GET“,“url“:“/status.php“,“message“:{„Exception“:“Doctrine\\DBAL\\DBALException“,“Message“:“$
            „app“:“PHP“,“method“:“GET“,“url“:“/status.php“,“message“:“You are using a fallback implementation of the intl extens$
            „app“:“PHP“,“method“:“PROPFIND“,“url“:“/remote.php/dav/files/Sebbe/“,“message“:“Error: Class ‚OCA\\DAV\\Connector\\S$
            „app“:“PHP“,“method“:“PROPFIND“,“url“:“/remote.php/dav/files/Sebbe/“,“message“:“You are using a fallback implementat$
            „app“:“remote“,“method“:“GET“,“url“:“/status.php“,“message“:{„Exception“:“Doctrine\\DBAL\\DBALException“,“Message“:“$

            Für mich sieht es also nach einem PHP Fehler aus. Ich habe daraufhin die Pakete neu installieren wollen (waren aber alle da). Aufschlussreich war allerdings „apt list –installed | grep php.

            In der folgenden Liste tauchten neben den php7.X einträgen auch php8.0 Einträge auf. Könnte der Fehler daher kommen? Hast du einen Tipp, wie ich das unabsichtliche upgrade wieder rückgängig machen kann, ohne das System zu gefährden?

            Falls es irgendwo die Möglichkeit für ne Spende gibt, lass es mich wissen! Dein Support hier hat mir schon öfters die Haut gerettet ;)
            VG, Sebastian

          • Jan sagt:

            Hi Sebastian,

            PHP 8 würde ich erst einmal wieder vom System entfernen, wenn es nicht benötigt wird (kommt vermutlich durch die Verwendung eines PPAs?). Daher am besten PPA deaktivieren, PHP komplett deinstallieren und neu installieren/konfigurieren.
            Ansonsten sieht die Fehlermeldung eher so aus, als ob das Paket „php-intl“ fehlt. Dieses vielleicht mal nachinstallieren.

            Einen Spenden-Button gibt es oben in der Leiste unter „Unterstützen“. ;-)

            Gruß,
            Jan

  • Sandro sagt:

    Good morning !
    I’ve used your tutorial and all works great, thank you !
    I have one problem on TSL 1.0 and 1.1 when I control it on https://www.ssllabs.com/ssltest/
    It says „This server supports TLS 1.0 and TLS 1.1. Grade capped to B“
    How can I fix it? There’s no „TLSv1.0“ after „ssl_protocols“
    Thank you

    • Jan sagt:

      Hi Sandro,

      when you deactivated TSLv1.0/1.1 and the webserver still answers with these old versions, I guess that there is another webserver in front of your installation handling these requests.

      Best regards,
      Jan

      • Sandro sagt:

        Thank you four your reply.

        I’ve tried to intercept the apps listening on port 443 with the command
        sudo lsof -nP -iTCP -sTCP:LISTEN

        but I haven’t found any other process exept nginx (master and worker processes)
        Any other tip ?
        Thank you!

        Best regards,
        Sandro

        • Jan sagt:

          Hi Sandro,

          no, I didn’t mean on the same machine. I assume that this is some other machine/proxy which acts in front of your Nextcloud server.

          Best regards,
          Jan

  • John sagt:

    Vielen Dank für den umfangreichen Guide und vor allem die detaillierten Erklärungen zu jedem Schritt!

    Für den Fall, dass ich auf die Erreichbarkeit der Cloud außerhalb des eigenen Netzwerkes verzichten möchte: einfach die Schritte Domain und DynDNS sowie Port-Forwarding auslassen? Oder ändert sich an der weiteren Installation etwas?

    • Jan sagt:

      Hi John,

      nicht ganz: Hier können dann ja keine Let’s Encrypt Zertifikate erzeugt werden. Hier kann man dann z.B. selbst signierte Zertifikate verwenden, aber wenn diese nicht auch auf den Clients „installiert“ sind, dann wirst du z.B. immer eine Warnung im Browser bekommen.
      Ansonsten könntest du aber auch das Port-Forwarding auf 443 entfernen (80 aber offen lassen). Dann brauchst du Netzwerl-intern aber einen DNS-Server, der die „richtige“ Domain auf die lokale IP umlenkt (damit Domain und Zertifikate zusammen passen).

      Gruß,
      Jan

  • Sebastian sagt:

    Hi Jan,

    klasse Anleitung – werde etwas spenden. Habe jetzt auf NC 21 geupdatet und bekomme in der Übersicht folgende Fehler:

    Dein Web-Server ist nicht richtig eingerichtet um „/.well-known/webfinger“ aufzulösen. Weitere Informationen findest Du in der Dokumentation.
    Dein Web-Server ist nicht richtig eingerichtet um „/.well-known/nodeinfo“ aufzulösen. Weitere Informationen findest Du in der Dokumentation.

    Hast du eine Idee? Falls nicht, auch kein Stress, jedoch bin ich trotz Suche noch nicht weitergekommen.

    • Jan sagt:

      Hi Sebastian,

      schau dir mal den vHost für NC an und gleiche das mal mit deinem vHost ab. Den vHost habe ich hier mal komplett überarbeitet (Update des Artikels am 30.01.21). Da hat sich einiges geändert. Ich denke, dass genau das dein Problem sein wird.

      Gruß,
      Jan

      • Martin sagt:

        Hi Jan,

        ich hatte das gleiche Problem wie Sebastian und das Ändern des vHosts für die NC hat die Lösung gebracht.
        Vielen Dank wieder mal!

        Grüße
        Martin

        • Sebastian sagt:

          Danke, habe es jetzt auch hinbekommen: Den entsprechenden Bereich in der alten vHost Config durch ein paar Zeilen der neuen vHost Config ersetzt.

          Super, dass du dir hier Zeit nimmst.

  • Denilson Schneider sagt:

    Olá Jan!
    Muito obrigado !
    Ótimo trabalho !
    Estou muito contente com a sua ajuda!
    Através do seu tutorial agora tenho um servidor com OpenMediaVault funcionando com o Nextcloud+Nginx+ssl com duckdns ! , só tive que adicionar “ –dns dns_duckdns “ ao comando acme e uma variável de ambiente DuckDNS_Token=
    Desejo que o Sr. e a equipe do Nextcloud tenham muito sucesso!
    Saudaçoes do Brasil !

  • Ricardo sagt:

    Hey,

    Erstmal, super Anleitung.

    Nach dem ich alles befolgt habe, wie deine Anleitung bekomme ich folgende Fehlermeldung:
    Dem Modul php-imagick fehlt die SVG-Unterstützung. Für eine bessere Kompatibilität wird empfohlen, es zu installieren.

    Der PHP-imagick ist installiert und die php-Einstellungen habe ich mehrere Male überprüft und noch mal die php-imagick installiert. Leider ohne erfolgt.

    Weiss du, warum das so ist? bzw. hast du eine Empfehlung, wonach ich schauen kann?

    Danke

1 3 4 5 6 7 8

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.