Wer meinen Blog kennt, der weiß, dass ich bereits seit Jahren Nextcloud auf der Synology DiskStation betreibe. Lange zeit habe ich das direkt über den Webserver der DiskStation gemacht. Die Einschränkungen von Synology sind zwar mit der Zeit weniger geworden, aber sie sind immer noch da und für die zusätzlichen Services wie Nextcloud Office/Collabora und Imaginary, kommt man um Docker sowieso nciht herum. Nextcloud auf einer Synology DiskStation per Docker zu betreiben, bietet eine flexible, performante und zugleich gut wartbare Lösung. Zwar gibt es auch hier wieder einige Besonderheiten, dennoch lässt sich recht einfach eine komplette Cloud-Umgebung einrichten.
Die Anleitung führt Schritt für Schritt durch den vollständigen Aufbau einer produktiven Nextcloud‑Installation – inklusive Datenbank, Caching (Redis), Office‑Integration (Collabora Code) und Vorschaubildgeneration (Imaginary). Ich verwende dabei das Community Docker Image von Nextcloud und nicht das AIO-Image.

Vorbereitung

Bevor wir mit der eigentlichen Arbeit beginnen, müssen wir noch einige Dinge vorab einrichten. Zuallererst benötigt ihr das DSM-Paket “Container Manager”, sofern ihr es noch nicht installiert habt. Mit diesem Paket erhaltet ihr Docker samt Benutzeroberfläche für eure DiskStation. ACHTUNG: für einige schwächere Modelle steht das Paket nicht zur Verfügung.
Außerdem müsst ihr wissen, wie ihr auf die Kommandozeile bzw. das SSH-Terminal euer DiskStation zugreift.

Mit dem Container Manager wird auch ein neuer freigegebener Ordner erstellt: /docker. Dort legt ihr Ordner an, die ihr dann in euren Docker-Containern mounten könnt. Ihr könnt aber auch andere freigegebene Ordner bzw. Ordnerpfade mounten, müsst aber die entsprechenden Rechte setzen.
Erstellt unter /docker einen Ordner nextcloud und darunter die Ordner: mariadb, config, data und app.

/data-Verzeichnis auslagern

Auch als Docker Container, macht es Sinn, das /data-Verzeichnis auszulagern, also außerhalb des Projektordners anzulegen. Das ist grundsätzlich kein Problem, erfordert aber einige zusätzliche Schritte.

• Erstellt euch einen neuen Freigegebenen Ordner. Diesen solltet ihr nur für das /data-Verzeichnis verwenden um Probleme vorzubeugen.
• Erstellt im neuen Freigegebenen Ordner ein neues Verzeichnis z.B. /data. Ihr könnt auch einen Ordner als Zwischenebene erstellen z.B. /nextcloud1/data/ falls ihr die /data-Verzeichnisse mehrerer Nextcloud-Instanzen im Freigegebenen Ordner ablegen wollt (oder doch andere Verzeichnisse im Freigegebenen Ordner anlegen müsst).

Jetzt gibt es noch ein kleines Problem, nämlich die Berechtigungen. Das Problem können wir an dieser Stelle aber nicht lösen, ich komme also später nochmal darauf zu sprechen.

Domains und Reverse Proxy

Für Nextcloud benötigt ihr eine Subdomain, wollt ihr auch Collabora als Office-Lösung einrichten, benötigt ihr zwei Subdomains. Wie ihr den Zugriff auf eure DiskStation via Domain samt SSL-Zertifikat konfiguriert, könnt ihr in diesem Artikel nachlesen.
Genauer gesagt benötigen wir einen Reverse Proxy. Diesen richten wir in der Systemsteuerung unter Anmeldeportal > Erweitert > Reverse Proxy ein. Klickt auf Erstellen und gebt folgende Werte ein:

• Reverse-Proxy-Name: ein beliebiger Name
• Quelle
  • Protokoll: HTTPS
  • Hostname: die Subdomain die ihr für eure Cloud vorgesehen habt
  • Port: 443
• “HSTS aktivieren” anhaken
• Ziel
  • Protokoll: HTTP
  • Hostname: localhost
  • Port: wählt hier eine freie Portnummer, 80 und 443 sind bereits vom Webserver der DiskStation belegt, beliebt sind die Ports 8080, 8181, 8282 usw.

Im Reiter Benutzerdefinierte Kopfzeile klickt auf Erstellen > Web Socket. Im Reiter Erweiterte Einstellungen empfiehlt es sich, die Timeouts auf 600 zu erhöhen. Solltet Ihr für die Subdomain noch kein Zertifikat erstellt haben, müsst ihr das noch nachholen. Wie das geht erfahrt ihr hier. Vergesst nicht, das Zertifikat dem Reverse Proxy zuzuordnen indem ihr unter Systemsteuerung > Sicherheit > Firewall > Einstellungen den erstellten Reverse Proxy in der Liste sucht und das zugehörige Zertifikat im Dropdown auswählt.

Benötigte Docker Container definieren

Da Nextcloud einige Docker Container benötigt, empfiehlt sich, die Container mit Docker Compose zu konfigurieren. Das ist bequemer als die einzelnen Container über die Benutzeroberfläche zu erstellen, außerdem lassen sich so einfach Änderungen vornehmen, Updates durchführen oder das Projekt neu erstellen.

Öffnet das Menü Projekt im Container Manager und klickt auf Erstellen. Vergebt einen Projektnamen und wählt als Pfad /docker/nextcloud und als Quelle “docker-compose.yml erstellen” aus. Ein Texteditor zur Erstellung der compose-Datei wird eingeblendet. Alternativ könnt ihr die compose-Datei auch in einem Texteditor eurer Wahl erstellen und an dieser Stelle hochladen.

Datenbank

Nextcloud benötigt eine Datenbank, der erste Container den wir erstellen, ist also MariaDB (alternativ könnt ihr auch Postgres verwenden, die benötigten Container-Parameter müsst ihr der Doku des Postgres-Images entnehmen). Ihr könnt auch einen bereits bestehenden Datenbank-Container verwenden. Ich selbst bevorzuge für jedes Projekt einen eigenen Container zu konfigurieren. Das kapselt die einzelnen Projekte stärker ab und ich kann den komplette Datenbank-Server (Container samt Daten) löschen und neu erstellen anstatt einzelne Datenbanken und Nutzer zu löschen. Außerdem kann ich so verschiedene Datenbank-Versionen verwenden.
Gebt folgendes in den Texteditor ein:

services:
  mariadb:
    image: mariadb:11.8
    container_name: nextcloud_mariadb
    restart: unless-stopped
    networks:
      - nextcloud
    volumes:
      - ./mariadb:/var/lib/mysql
    environment:
      - MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=1
  
networks:
  nextcloud:
    name: nextcloud
    driver: bridge

Achtet auf das korrekte Einrücken, verwendet werden 2 Leerzeichen. Der Texteditor hat eine Syntax- und Format-Kontrolle, die euch auf Fehler in der Struktur eurer Compose.yml hinweist. Auf nicht unterstützte Keys oder falsche Values weißt euch der Editor natürlich nicht hin.

Erklärung:

• Image-Version: Hier seht ihr, mit welchen MariaDB-Versionen die aktuelle Nextcloud-Version getestet wurde. Das ist nicht immer die neueste MariaDB-Version. Üblicherweise gibt es keine Probleme, wenn ihr das neueste MariaDB-Image (mariadb:latest) verwendet. Wenn ihr auf Nummer Sicher gehen wollt, nehmt die Version aus der Doku.
• Container-Name: der Name kann beliebig gewählt werden, es empfiehlt sich ein sprechender Name, gerade wenn ihr mehrere MariaDB-Container betreibt.
• Restart: Hier könnt ihr angeben, ob der Container bei einem Absturz, Update oder einem Neustart des Hosts (DiskStation) immer automatisch neu gestartet werden soll (always) oder nicht (never). Ich bevorzuge unless-stopped, stoppe ich den Container im Container Manager manuell, stoppt der Container nicht, wenn die DiskStation neu gestartet wird.
• Netzwerk: Um das komplette Projekt abzukapseln (sowohl vom Host als auch von anderen Containern), soll es in einem eigenen Bridge-Netzwerk laufen. Dieses Netzwerk müsst ihr
  • selbst erstellen, entweder vorher im Container Manager oder wie hier über den networks-Block
  • die Container über den Key networks: in das entsprechende Netzwerk eingliedern
• Gemountete Volumes: Da wir unsere Datenbank persistent halten, also durch ein löschen des Containers nicht verlieren und auch einfach Backups erstellen können wollen, mounten wir das vorbereitete Verzeichnis /docker/nextcloud/mariadb auf das Container-Verzeichnis /var/lib/mysql. Da wir den Projektpfad mit /docker/nextcloud festgelegt haben, müssen wir im Compose.yml nicht den vollen Pfad angeben.
• Umgebungsvariablen: Es ist möglich, bereits über die Umgebungsvariablen Datenbank und Benutzer zu erstellen. Ich bevorzuge die manuelle Installation. Mit MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=1 hat der root-User anfangs kein Passwort, dieses kann bei der anschließenden Installation selbst gesetzt werden, ohne den Parameter wird das root-Passwort bei der Erstellung des Containers generiert und im Container-Log ausgegeben.

Caching

Für effizientes File-Caching benötigt Nextcloud Redis, auch diesen Service werden wir als Container zur Verfügung stellen. Fügt den Block für Redis ein:

services:
  mariadb:
    ...

  redis:
    image: redis:alpine
    container_name: nextcloud_redis
    restart: unless-stopped
    command: redis-server --requirepass Das-Passwort-für-den-Redis-Server
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 3
    networks:
      - nextcloud
  
networks:
  ...

Erklärung:

• Container-Befehle: Über command könnt ihr Befehle angeben, die vom Container beim Starten ausgeführt werden sollen. Hier legen wir ein Passwort für den Redis-Server fest.
• Health-Check: der Health-Check ist nicht erforderlich, lässt euch aber einen Container gewisse Überprüfungen unterziehen und Docker frühzeitig mit einem Abbruch des Startvorganges reagieren. Das ist dann hilfreich, wenn euer Compose.yml viele Container enthält, die voneinander abhängig sind bzw. Container die sehr lange beim Starten benötigen. Warum ewig warten bis alle Container gestartet sind, wenn ein grundlegender Container bereits nicht richtig funktioniert?
  Im Health-Check für Redis wird geprüft, ob der Redis-Server über die Kommandozeile gepingt werden kann.

Weitere Konfiguration ist für den Container nicht notwendig, daher können wir gleich zum Nächsten Thema springen.

Office-Support

Für den Office-Support, also das Betrachten und Bearbeiten von Office-Dokumenten direkt in der Cloud bzw. dem Webbrowser, ist Collabora Code notwendig.
Für den Collabora-Code-Server benötigen wir wieder einen eigenen Reverse Proxy. Was früher ohne ging, geht jetzt nur noch mit Domain und Zertifikat. Die Angaben entnehmt ihr dem Screenshot. Auch hier müsst ihr wieder einen Web Socket hinzufügen, das Timeout sollte genügen, bei etwas schwächeren DiskStations könnt ihr auch ein höheres Timeout setzen. Vergesst nicht auch hier wieder das passende Zertifikat zu hinterlegen.

Jetzt könnt ihr das Compose.yml um den nächsten Block erweitern.

services:
  mariadb:
    ...

  redis:
    ...
  
  collabora:
    image: collabora/code:latest
    container_name: nextcloud_collabora
    restart: unless-stopped
    privileged: true
    ports:
      - 9980:9980
    environment:
      - dictionaries=en_US,de_DE
      - aliasgroup1=https://cloud.mydomain.net:443
      - domain=cloud\\.mydomain\\.net
      - username=username
      - "password=ein passwort"
      - extra_params=--o:ssl.enable=false --o:ssl.termination=true --o:termination.strict_isolation=false --o:security.capabilities=false --o:security.seccomp=false
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9980/hosting/discovery"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 30s
    networks:
      - nextcloud

networks:
  nextcloud:
    name: nextcloud
    driver: bridge

Erklärung:

• Ports: Jeder Container hat einen (oder mehrere) internen Port, über den ein bestimmtes Service erreichbar ist. Da die Container in einem Bridge-Netzwerk laufen, sind diese Ports im Host-Netzwerk (ihrem LAN, bzw. dem localhost, also der DiskStation) nicht erreichbar. Für die meisten Container die wir hier verwenden ist das auch nicht weiter gewollt, denn auf die Datenbank oder Redis muss nur der Nextcloud-Container zugreifen können. Da wir für Collabora Code ein SSL-Zertifikat über den Reverse Proxy bereitstellen, muss darüber aber der Zugriff auf den Container funktionieren. Daher mappen wir den internen Port (9980 rechts vom Doppelpunkt) auf einen anderen, externen Port (9980 links vom Doppelpunkt), der kann gleich lauten wie der interne Port, sofern er im Host-Netzwerk noch frei ist oder aber auch anders lauten etwa 9988:9980. Wichtig ist nur, dass der externe Port, mit dem Zielport des Reverse Proxy übereinstimmt. Der interne Port selbst, kann nicht verändert werden.
• Mit den Umgebungsvariablen setzt ihr die Domain eurer Nextcloud, damit Collabora Dokumente von dieser Domain akzeptiert. Seht nochmal in der Doku nach, welche Umgebungsvariable Collabora Code dafür nutzt. Seit ich Collabora im Einsatz habe, wurde die entsprechende Umgebungsvariable mehrmals umbenannt.
  Auch einen Benutzernamen und ein Passwort könnt ihr hier festlegen. Wichtig sind aber die extra_params. Hier müsst ihr die Generierung eines eigenen SSL-Zertifikats deaktivieren, da ihr das Zertifikat ja über den Reverse Proxy liefert. Außerdem muss SECCOMP deaktiviert werden, denn das unterstützt die DiskStation leider nicht.
• Auch hier macht ein Health-Check wieder Sinn, statt einem Ping wird hier aber CURL verwendet, da der Zugriff ja per SSL erfolgt.

Bilder-Vorschau generieren

Das Vorschaubilder beschleunigen den Zugriff auf eure Cloud, die Generierung eben jener ist aber Ressourcen- bzw. Zeitaufwendig. Auch hier zahlt sich die Auslagerung aus. Nextcloud unterstützt Imaginary, bzw. gibt es dafür ein eigenes Image. Ergänzt euer Compose.yml um folgenden Block:

services:
  mariadb:
    ...

  redis:
    ...
  
  collabora:
    ...

  imaginary:
    image: ghcr.io/nextcloud-releases/aio-imaginary:latest
    container_name: nextcloud_imaginary
    environment:
      - PORT=9000
    command: -concurrency 50 -enable-url-source
    restart: unless-stopped
    networks:
      - nextcloud
  
networks:
  nextcloud:
    name: nextcloud
    driver: bridge

Nextcloud Docker Container definieren

Wirt haben jetzt alle benötigten Dienste angegeben, jetzt wird es Zeit die Einstellungen für den Nextcloud-Container im Compose.yml vorzunehmen:

services:
  mariadb:
    ...

  redis:
    ...
  
  collabora:
    ...

  imaginary:
    ...

  nextcloud:
    image: nextcloud:latest
    container_name: nextcloud_app
    restart: unless-stopped
    ports:
      - 8080:80
    links:
      - mariadb
      - redis
      - collabora
      - imaginary
    networks:
      - nextcloud
    volumes: 
      - ./config:/var/www/html/config:rw
      - ./data:/var/www/html/data:rw
      - ./app:/var/www/html:rw
    environment:
      - PHP_MEMORY_LIMIT=4048M
      - PHP_UPLOAD_LIMIT=4048M
      - TRUSTED_PROXIES=192.168.0.1  #IP des Hosts/der DiskStation einsetzen
      - OVERWRITEHOST=cloud.mydomain.net
      - OVERWRITEPROTOCOL=https
      - OVERWRITECLIURL=https://cloud.mydomain.net
      - REDIS_HOST=nextcloud_redis
      - REDIS_PORT=6379
      - REDIS_HOST_PASSWORD=Das-Passwort-für-den-Redis-Server
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/login"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 30s
    depends_on:
      mariadb:
        condition: service_started
      redis:
        condition: service_healthy
      collabora:
        condition: service_healthy
      imaginary:
        condition: service_started
  
networks:
  nextcloud:
    name: nextcloud
    driver: bridge

Erklärung:

• Ports: Auch hier müssen wir wieder einen externen Port mappen, da wir ja die Cloud über den Reverse Proxy/die Subdomain erreichen wollen. 80 ist hier der interne Port, der externe Port muss mit dem Zielport des Reverse Proxy übereinstimmen, den ihr während den Vorbereitungen angelegt habt.
• Gemountete Volumes: Auch die Daten des Nextcloud-Containers wollen wir persistent halten, vorallem unsere eigenen Daten, die wir in die Cloud hochladen. Ihr habt dabei mehrere Möglichkeiten. Ihr könnt die komplette Nextcloud-Installation samt Konfigurationsdatei und Daten in einem Ordner mounten:

- ./app:/var/www/html:rw

Ihr könnt aber auch Konfiguration und Daten in separate Ordner auslagern. Das würde dann dem Ordner-Setup aus der Vorbereitung bzw. dem Nextcloud-Block im Compose.yml oben entsprechen.

- ./config:/var/www/html/config:rw
- ./data:/var/www/html/data:rw
- ./app:/var/www/html:rw

Zusätzlich könnt ihr noch die Ordner für eigene Apps und für eigene Themes mounten um diese z.B. separat zu sichern.

- ./apps:/var/www/html/custom_apps
- ./themes:/var/www/html/themes/custom

• Umgebungsvariablen: Über die Umgebungsvariablen könnt ihr die Konfigurationsdatei eurer Nextcloud bereits vorab mit Werten füllen. Ihr könnt euch dabei auf die wichtigsten Werte konzentrieren und die Config.php später über die Kommandozeile bearbeiten oder aber die komplette Konfiguration in der Compose.yml vornehmen. Ich habe mich hier auf die wichtigsten beschränkt. Die Konfiguration kann auch später noch jeder Zeit über die Compose.yml angepasst werden.
• Health_Check: Auch für den Nextcloud-Container schadet ein Health-Check nicht, ähnlich wie bei Collabora Code prüfen wir hier den HTTPS-Zugriff bzw. das Zertifikat via CURL.
• Abhängigkeiten: Unser Nextcloud-Container ist von einigen anderen Containern abhängig. Der Datenbank Container ist dabei essentiell, die anderen Services sind zwar optional, würden die Funktionsweise der Nextcloud aber beeinträchtigen, daher wollen wir den Container gar nicht erst ausführen, wenn nicht alle anderen Container in Ordnung sind. Unter depends_on listen wir also alle Contaienr auf, von denen Nextcloud abhängt. Wichtig: ihr müsst hier den Service-Namen aus der Compose.yml verwenden also dem Namen vor dem Doppelpunkt, dem dann der Konfigurationsblock folgt und nicht den Container-Namen den ihr vergeben habt. Mit condition geben wir an, welchen Zustand der jeweilige Container haben soll. MariaDB und Imagniary sollen einfach laufen, daher verwenden wir hier service_started. Für Collabora und Redis haben wir Health-Checks definiert, auf diese beziehen wir uns hier mit service_healthy.

Projekt erstellen

So das wars auch schon mit unserer Compose.yml. Wir können das Projekt jetzt erstellen und prüfen ob alles richtig definiert ist. Der Container Manager lädt die angegebenen Images, das kann mitunter einige Zeit dauern, der Fortschritt wird euch aber im Ausgabefenster angezeigt.

Sollte ein Container nicht erstellt werden können, müsst ihr euch auf Fehlersuche begeben. Fehlerhafte Container starten automatisch neu. Stoppt das Projekt um in Ruhe das Protokoll auswerten zu können, dort findet ihr den Grund für den Fehler.

MariaDB-Installation

Wie schon weiter oben geschrieben, bevorzuge ich die Installation von MariaDB selbst durchzuführen, anstatt Datenbank und Benutzer in der Compose.yml zu definieren. Das lässt mich die Sicherheit noch etwas erhöhen.

• Klickt im Container Manager unter Container auf den MariaDB Container und anschließend auf Aktion > Terminal öffnen > Erstellen.
• Gebt jetzt folgenden Befehl ein:

/bin/mariadb-secure-installation

• Im Installationsdialog macht ihr folgende Eingaben, die ihr mit Enter bestätigt:
  • Enter current password for root –> nichts, da das root-Passwort ja leer ist
  • Enable unix_socket authentication? –> n
  • Set root password? –> y
  • Gebt ein sicheres Passwort/Passphrase ein und bestätigt durch erneute Eingabe.
  • Remove anonymous user? –> y
  • Disallow root login remotely? –> y
  • Remove test database and acces to it? –> y
  • Reload privilege tables now? –> y
• Jetzt könnt ihr euch bei MariaDB mit dem root-User anmelden:

mariadb -u root -p

• Gebt das zuvor angelegt root-Passwort ein.
• Zuerst erstellen wir eine Datenbank:

CREATE DATABASE nextcloud;

• Anschließend einen Benutzer für die Datenbank. Dieser hat nur Zugriff aus dem Bridge-Netzwerk unseres Projekts, das erhöht die Sicherheit. Um die Netzadresse herauszufinden, öffnet im Container Manager den Bereich Netzwerk und klappt dort das Bridge-Netzwerk eures Projekts auf. Ihr könnt mit dem % den Zugriff aus dem ganzen Projekt-Netzwerk erlauben. Ihr könntet auch im Nextcloud-Container die konkrete IP ablesen, die könnte sich aber ändern und Nextcloud würde den Zugriff auf die Datenbank verlieren und ihr müsstet den Benutzerzugriff bearbeiten.

CREATE USER 'oc_nextcloud'@'XX.XX.XX.%' IDENTIFIED BY 'Some-Secure-Passphrase';

• Jetzt geben wir dem Benutzer Zugriff und Berechtigungen für die Datenbank:

GRANT ALL PRIVILEGES ON nextcloud.* TO oc_nextcloud@'XX.XX.XX.%';

• Jetzt stellen wir sicher, dass die Änderungen auch sofort inkraft treten, ohne dass wir den Datenbank-Server neu starten müssen:

FLUSH PRIVILEGES;

Nextcloud-Installation

Zwischenschritt: Berechtigungen für das ausgelagerte /data-Verzeichnis

Dieser Schritt ist nur notwendig, wenn ihr euch entschlossen habt, das /data-Verzeichnis auszulagern. Weiter oben habe ich erwähnt, dass wir noch die richtigen Berechtigungen setzen müssten, da der Nextcloud-Container einen Benutzer verwendet, der auf in DSM nicht existiert. Mehr dazu könnt ihr im Abschnitt Zusatzinfos zu Benutzer und Berechtigungen nachlesen.

Im Verzeichnis /docker kann der Container diese Berechtigung selbst setzen. Um den Benutzer bzw. dessen ID herauszufinden, öffnet die File Station und navigiert im Freigegebenen Ordner /docker in den Ordner eures Nextcloud-Projekts und klickt dort mit der rechten Maustaste auf einen der Unterordner (außer /mariadb) etwa /config und öffnet die Eigenschaften. Unter Berechtigung seht ihr einen Eintrag “Unbekannte(r) Benutzer/Gruppe:” gefolgt von einer Zahl, das ist die ID des Benutzers. (Da ich nicht weiß ob die ID zufällig vergeben wird oder auf allen Geräten gleich ist, konnte ich sie euch nicht schon im Abschnitt Vorbereitung verraten.)

Mit dieser können wir die Berechtigung über die Kommandozeile/SSH-Terminal setzen:

chown -R xx:xx /volumex/pfad/data    #Gebt hier euren korrekten Pfad ein und ersetzt XX durch die ID des unbekannten Benutzers.
chmod -R 770 /volumex/pfad/data      #Gebt hier euren korrekten Pfad ein und ersetzt XX durch die ID des unbekannten Benutzers.

Installationsassistent

Jetzt können wir endlich den Installationsassistenten von Nextcloud ausführen. Gebt dazu die Subdomain, die ihr für Nextcloud eingerichtet habt im Browser auf.

• Gebt Benutzerdaten für den Amin eurer Cloud an.
• Den Datenordner könnt ihr an dieser Stelle nicht ändern. Der Pfad bezieht sich auf einen Ordner im Docker-Container, den Ordner, der auf eurer DiskStation benutzt werden soll, legt ihr in der Compose.yml fest.
• Als Datenbank wählt ihr MariaDB aus und verwendet die Benutzerdaten die ihr zuvor eingerichtet habt. Als Datenbankhost gebt ihr den Container-Namen eures MariaDB-Containers an. Docker löst in Bridge-Netzwerken die Container-Namen automatisch auf die richtige IP auf. Als Port gebt ihr 3306 an.

Schließt dann den Installationsdialog ab und wartet, bis die Installation abgeschlossen ist. Ihr habt jetzt die Möglichkeit aus der Liste der Empfohlenen Apps jene auszuwählen, welche ihr installieren wollt. Anschließend können wir uns um den Abschluss der Installation, die Basiskonfiguration und weitere Einrichtung kümmern. Welche Schritte genau notwendig sind, könnt ihr den Einrichtungswarnungen entnehmen. Die genauen Schritte können je nach Nextcloud-Version abweichen. Die Einrichtungswarnungen findet ihr in den Administrationseinstellungen > Übersicht, zu erreichen über das Benutzermenü.

Datenbank-Einrichtung abschließen

Einige Schritte zur Einrichtung und Optimierung der Datenbank werden nicht während der Installation selbst abgeschlossen sondern müssen manuell durchgeführt werden. Dazu ist es notwendig occ-Commands (Nextclouds CLI) auszuführen. Die könnt ihr aber nicht direkt auf der Kommandozeile der DiskStation ausführen, sondern müsst auf die Kommandozeile des Nextcloud-Containers zugreifen. Dazu habt ihr zwei Möglichkeiten:

1. Über die Benutzeroberfläche des Container Managers – markiert dazu im Container Manager den Nextcloud-Container und klickt auf Details > Aktion > Terminal öffnen > Erstellen und wechselt dann auf die neu erstellte Kommandozeile (bash). Jetzt könnt ihr über PHP-CLI die occ-Befehle ausführen:

php occ ...

2. Über die Kommandozeile/SSH-Terminal der DiskStation – Hab ich nicht ein paar Zeilen weiter oben geschrieben das geht nicht? Naja zumindest könnt ihr nicht direkt php occ … eingeben, sondern müsst zuerst auf die Kommandozeile des Containers zugreifen, außerdem müsst ihr einen Benutzer, der im Container den gewünschten Befehl ausführen soll. Dazu verwenden wir den Benutzer www-data, also den Benutzer des Webservers, der im Container installiert ist. Das ganze sieht dann so aus:

docker exec -u www-data <Container-Name> php occ...

Der Container Manager bietet einen schnellen und einfachen Zugriff auf die Kommandozeile des Containers, hat aber den Nachteil, dass das Terminal-Fenster den Container Manager blockiert, ihr könnt also auf kein anderes Menü zugreifen, oder ein Terminal für einen zweiten Container öffnen, ohne das erste zu schließen.
Der Zugriff über die Kommandozeile der DiskStation erlaubt es euch auch Befehle über den Aufgabenplaner auszuführen bzw. zu automatisieren oder in Skripte einzubauen.

Zurück zur Einrichtung unserer Cloud. Nach der Installation müssen wir üblicherweise zwei occ-Befehle ausführen, zum einen müssen wir die Einrichtung der Datenbank abschließen:

php occ maintenance:repair -include-expensive

Zum anderen müssen wir noch einige Indices hinzufügen:

php occ db:add-missing-indices

Um sicher zu gehen, dass die beiden Befehle in der von euch verwendeten Version auch wirklich ausgeführt werden müssen, könnt ihr in Nextclouds Selbsüberprüfung nachsehen,

E-Mail Benachrichtigungen

Als nächstes kümmern wir uns um die E-Mail-Benachrichtigungen. Bevor ihr die Mail-Einstellungen vornehmen könnt, müsst ihr dem Administrator-Konto eine E-Mail-Adresse hinzufügen. Geht dazu in die persönlichen Einstellungen und gebt eine E-Mail-Adresse an. Anschließend wechselt ihr im Administrationsbereich in die Grundeinstellungen. unter E-Mail-Server könnt ihr jetzt die Server-Daten und den Login eures Mail-Kontos eingeben, über das die Cloud Benachrichtigungen verschicken soll. Habt ihr dem Administrator-Konto keine E-Mail-Adresse hinzugefügt, erhaltet ihr beim Klick auf Test-E-Mail senden eine Fehlermeldung (AxiosError 400).

Konfigurationsdatei bearbeiten

Ihr könnt die Mail-Einstellungen auch in der Compose.yml angeben, wie auch fast alle anderen Einstellungen die in der Konfigurationsdatei gemacht werden können. Für nachträgliche Änderungen muss dazu aber das Projekt gestoppt, die Änderungen in der Compose.yml vorgenommen und dann neu erstellt werden. Alternativ könnt ihr aber auch einfach die Konfigurationsdatei direkt bearbeiten. In der Kommandozeile/SSH-Terminal eurer DiskStation öffnet ihr die Konfig einfach über den gemappten Ordner:

vi /volumeX/docker/nextcloud/config/config.php    #Beispielpfad

Neue Parameter müsst ihr immer innerhalb des geschwungenen Klammer-Blocks nach $config = array einfügen, die Reihenfolge der Parameter ist dabei egal. Abschließen muss die Zeile aber immer mit einem Beistrich, außerdem müsst ihr die geraden einfachen Anführungszeichen (#-Taste) verwenden und nicht die Akzent-Zeichen (Taste zwischen ß und Backspace).
Folgende Änderungen werden empfohlen:

'serverid' => 1,    #Eine Zahl zwischen 0 und 515

'default_phone_region' => 'AT'    #Country Code für die gewünschte Region

'maintenance_window_start' => 23,    #Stunde, wann die Wartung ausgeführt werden soll

Was genau die Parameter bewirken, könnt ihr hier nachlesen. Als nächstes aktivieren wir noch das Caching via Redis, immerhin haben wir ja einen Redis-Container bereitgestellt. Folgende Einträge müsst ihr hinzufügen:

'memcache.distributed' => '\\OC\Memcache\\Redis',
'memchache.locking' => '\\OC\\Memchace\\Redis',
'redis' =>
array {
  'host' => 'nextcloud_redis',    #Hier den Container-Namen vom Redis-Container verwenden
  'password' => 'Das-Passwort-für-den-Redis-Server',    #Das Passwort, dass ihr in der Compose-yml für den Redis-Server angegeben habt
  'port' => 6379,
},

Auch die Vorschaugenerierung via Imaginary müssen wir in der Konfigurationsdatei eintragen:

'enabledPreviewProviders' =>
  array (
    0 => 'OC\\Preview\\Imaginary',
    1 => 'OC\\Preview\\OpenDocument',
    2 => 'OC\\Preview\\ImaginaryPDF',
    3 => 'OC\\Preview\\MSOfficeDoc',
    4 => 'OC\\Preview\\MarkDown',
    5 => 'OC\\Preview\\MP3',
    6 => 'OC\\Preview\\MP4',
    7 => 'OC\\Preview\\AVI',
    8 => 'OC\\Preview\\Movie',
    9 => 'OC\\Preview\\MKV',
    10 => 'OC\\Preview\\XCF',
  ),
'preview_imaginary_url' => 'http://nextcloud_imaginary:9000',

well-known/

Als nächstes müssen wir noch ein kleines Problem fixen. Ein Problem, dass schon lange existiert und bei den verschiedenen Installationsformen von Nextcloud immer wieder auftritt, die well-known/carddav bzw. caldav URL stimmt nicht. Warum das im Docker Container der Fall ist, der ja einen fix fertig konfigurierten Webserver mitbringt, entzieht sich meiner Kenntnis, auch die Tatsache, dass bei mir nur ein Fehler für die CardDAV-URL angezeigt wird, nicht aber die CalDAV, ist mir schleierhaft. Lösungswege gibt es dafür unzählige, die aber nicht immer Funktionieren. An dieser Stelle hat es glücklicherweise mit einer der einfacheren Methoden geklappt. Die URL muss einfach nur in der .htaccess-Datei der Nextcloud angepasst werden. Auf diese könnten wir über die Kommandozeile zugreifen und die URL(s) einfach anpassen. Allerdings wird diese Änderung jedes mal überschrieben, wenn wir den Nextcloud-Container neu erstellen. Das passiert, wenn das Image, also unsere Nextcloud aktualisiert wird. Damit wir nicht jedes Mal per Kommandozeile die Anpassung erneut vornehmen müssen, erstellen wir uns dafür ein kleines Skript.

1. Öffnet in der Systemsteuerung eurer DiskStation den Aufgabenplaner. Wählt Erstellen > Geplante Aufgabe > Benutzerdefiniertes Skript.
2. Vergebt einen Namen, wählt als Benutzer “root” und entfernt den Haken bei “Aktiviert” (es handelt sich um eine geplante Aufgaben, wir wollen diese aber nicht nach Zeitplan ausführen lassen, sondern per Hand).

3. Unter Aufgabeneinstellung könnt ihr die E-Mail-Benachrichtigung aktivieren. Ich verwende die Benachrichtigung immer, nach einem erfolgreichen Test aktivieren ich zusätzlich die Option die Benachrichtigung nur im Fehlerfall zu schicken.
4. Fügt dann folgende Befehle in das Textfeld ein:

sed -i 's_caldav /remote_caldav https://cloud.mydomain.net/remote_g' /volumeX/docker/nextcloud/nextcloud_app/.htaccess
sed -i 's_carddav /remote_carddav https://cloud.mydomain.net/remote_g' /volumeX/docker/nextcloud/nextcloud_app/.htaccess

5. Speichert die Aufgabe und führt sie manuell aus (markieren und Ausführen klicken).

Ihr könnt die Aufgabe jetzt jedes mal, wenn die .htaccess überschrieben wurde erneut ausführen. Der Such- bzw. Ersatz-Text könnte kürzer Ausfallen, allerdings habe ich ihn so gestaltet, dass er die URL nur einmal ersetzt. Sollte das Skript versehentlich öfter ausgeführt werden, bzw. die URLs bereits angepasst sein, hinterlässt das Skript keine falschen URLs in der Datei.

Cron einrichten

Wenn wir schon im Aufgabenplaner sind, können wir auch gleich den Cron für unsere Nextcloud aktivieren.

1. Erstellt wieder eine geplante Aufgabe mit einem benutzerdefinierten Skript.
2. Diesmal lasst ihr den Haken bei “Aktiviert” gesetzte und erstellt einen Zeitplan dafür. Die Aufgabe soll täglich ausgeführt werden und alle 5 Minuten wiederholt werden. Gebt als Startzeit 00:00 und als Endzeit 23:55 an.
3. Fügt dann folgenden Befehl ins Textfeld ein:

docker exec -u www-data nextcloud_app php /var/www/html/cron.php

4. Speichert die Aufgabe.

Das wars auch schon. Der Cron wird jetzt alle 5 Minuten ausgeführt. Wird das Projekt bzw. der Container gestoppt (z.B. für ein Update) kann der Cron natürlich nicht ausgeführt werden. Solltet ihr längere Wartungsarbeiten an euer Cloud vornehmen könnt ihr die Aufgabe pausieren, indem ihr sie im Aufgabenplaner vorübergehend deaktiviert.

Office aktivieren

Der Collabora Code Container läuft und braucht selbst keine weiter Einrichtung. Wir müssen nur in der Nextcloud die entsprechende App installieren (falls ihr sie nicht schon bei der Nextcloud-Installation als “Empfohlene Apps” installiert habt), und mit dem Collabora Container verknüpfen.

Die App heißt Nextcloud Office, ihr findet Sie im Bereich Apps > Büro & Text. Hier wählt ihr als bevorzuge Office Suite “Nextcloud Office” aus. Sobald die App installiert ist, geht ihr wieder in die Administrationseinstellungen und dort in den Bereich Office. Wählt dort “Verwenden Sie Ihren eigenen Office Server” und gebt anschließend die URL ein, die ihr im Reverse Proxy für Collabora konfiguriert habt. Anschließend klickt ihr auf Save”. Habt ihr alles richtig gemacht, erhaltet ihr eine grüne Meldung. Unter “Vom Browser verwendete URL” muss die Collabora-Reverse-Proxy-Subdomain angezeigt werden und unter “Von Collabora verwendete Nextcloud-URL”, die Nextcloud-Reverse-Proxy-Subdomain. Sollte hier etwas nicht stimmen, kontrolliert noch einmal eure Reverse Proxy Einstellungen und die Compose.yml. Auch ein Blick in die Firewall schadet nicht (der Reverse Proxy sollte von der Firewall nicht geblockt werden).

Anschließend scrollt ihr noch ein Stück nach unten und tragt unter “Allow list for WOPI requests”, das Bridge-Netzwerk ein, indem euer Nextcloud-Projekt läuft. Die IP der Netzwerks könnt ihr im Container Manager einsehen, entweder über einen Blick in den Detail-Bereich eines der Container oder im Bereich Netzwerk, indem ihr das entsprechende Netzwerk aufklappt. Nach einem Klick auf Speichern habt ihr die Office-Unterstützung in eurer Cloud aktiviert.

Das wars auch schon, ihr habt jetzt Nextcloud mit Redis-Caching und Collabora-Office eingerichtet. Wenn ihr in den Administrationseinstellungen in den Bereich Übersicht schaut. Seht ihr dort, welche Nextcloud-Version ihr installiert habt. Dort wird euch auch angezeigt, wenn eine neuere Version verfügbar ist. Allergings könnt ihr dort auch lesen, dass der Web-Updater deaktiviert ist. Der ist nämlich in der Docker-Version von Nextcloud nicht verfügbar. Wollt ihr eure Cloud aktualisieren, müsst ihr das via Docker erledigen und wie das geht, zeige ich euch als nächstes.

Updates installieren

In eurer Nextcloud-Umgebung gibt es verschiedene Komponenten die aktualisiert werden können, dazu zählen:

• Apps die ihr in Nextcloud installiert habt, die könnt ihr wie üblich direkt in Nextcloud aktualisieren.
• Abhängige Services (MariaDB, Redis, Collabora, etc.) – Update via Docker
• Nextcloud selbst – Update via Docker

Updates von Nextcloud und der benötigten Services werden als neue Images ausgeliefert. Im Container Manager im Bereich Images, seht ihr, für welche Images neue Versionen vorliegen.

Egal ob Ihr Nextcloud oder ein anderes Image aktualisiert, der Vorgang ist immer gleich:

1. Aktiviert den Maintenance-Mode in Nextcloud. Der Schritt ist zwar nicht zwingend erforderlich, aber er Benachrichtigt alle verbundenen Clients, dass die Nextcloud vorübergehend nicht erreichbar ist. Das erspart euch gegebenenfalls Fehlermeldungen (oder Nachrichten von anderen Nutzern der Cloud).
2. Pausiert den Cron-Job, indem ihr ihn im Aufgabenplaner deaktiviert, auch das reduziert die Fehlermeldungen.
3. Stoppt im Container Manager das Nextcloud-Projekt und wartet, bis es vollständig gestoppt wurde.

4. Wechselt in den Bereich Images und klickt Update verfügbar > Aktualisieren und bestätigt die Meldung.
5. Wartet, bis die Aktualisierung durchgeführt wurde. Der Container Manager übernimmt dabei das Löschen des Containers, das Herunterladen des neuen und Löschen des alten Images.
   • Habt ihr mehrere Container, die auf einem Image basieren, werden alle Container aktualisiert. Container die Ihr über die GUI des Container Managers erstellt habt, werden mit den dort vorgenommenen Einstellungen ebenfalls neu erstellt.

6. Sobald die Aktualisierung fertig gestellt wurde, könnt ihr das Projekt über Aktion > Erstellen, neu erstellen, das erzeugt die Container mit den neuen Images und der Konfiguration aus der Compose.yml neu.

7. Aktiviert den Cron wieder.
8. Deaktiviert den Maintenance-Mode.
9. Solltet ihr Nextcloud aktualisiert haben, wird beim Start des neue Containers der interne Update-Vorgang ausgelöst. Wartet, bis dieser abgeschlossen wurde (siehe Screenshot). Solltet ihr eure Cloud vorher aufrufen, erhaltet ihr eine Fehlermeldung vom Webserver der DiskStation. Nachdem der Vorgang abgeschlossen wurde, könnt ihr eure Cloud aufrufen und auch dort den Update-Vorgang beenden. Prüft unter Administrationseinstellungen > Übersicht ob neue Meldungen vorliegen. Gegebenenfalls müsst ihr die Konfiguration anpassen oder die Datenbank aktualisieren (siehe Schritt Nextcloud-Installation)

Bonus: Andere Ordner der DiskStation in die Nextcloud einbinden

Das /data-Verzeichnis solltet ihr nur über die Nextcloud nutzen, also keine Dateien über DSM-Schnittstellen/Pakete dort ablegen und daraus lesen. Dateien solltet ihr nur über Nextcloud-Schnittstellen (WebUI, Client) hinzufügen bzw. darauf zugreifen. Sonst könnte es einerseits Berechtigungsprobleme geben, da DSM die Berechtigung des genutzten Benutzers anwendet, das /data-Verzeichnis aber den Benutzer www-data verwendet bzw. voraussetzt, den DSM ja eigentlich nicht kennt.
Andererseits bekommt Nextcloud Änderungen über das Dateisystem (also neue Dateien die nicht über die NC-Methoden hinzugefügt werden) nicht direkt mit. Es gibt zwar einen occ-Befehl, der ist aber für Ausnahmen gedacht bzw. die Migration größer Datenmengen.

Möchtet ihr dennoch einen bestehenden DSM-Ordner in eure Nextcloud integrieren bzw. eine Schnittstelle schaffen, dann könnt ihr diesen Ordner als “externen Speicher” in eure Nextcloud einbinden. Externen Speicher wird anders Verwaltet und externe Änderungen werden auch in der Cloud abgebildet. Ihr könntet den Ordner über die Compose.yml mounten und dann als lokalen Speicher hinzufügen, das ist zwar der einfachste Weg, allerdings werden Dateien, die über Nextcloud hinzugefügt werden nicht vom Indizierungsdienst erfasst, ihr seht die Dateien zwar in der File Station aber nicht in anderen DSM-Anwendungen (z.B. Synology Photos). Es gäbe zwar auch hierfür eine Kommandozeilen-Lösung aber auch die ist nicht für eine Nahtlose Einbindung geeignet, außerdem müsstet ihr dem eingebundenen Ordner die selbe Berechtigungs-Behandlung zuteil werden lassen, wie dem /data-Verzeichnis, was wiederum zu Problemen mit DSM führt.

Wollt ihr einen Ordner eurer DiskStation naht- und problemlos einbinden, dann via WebDAV. Dateien die per Nextcloud über WebDAV auf die DiskStation gelangen, werden vom Indizierungsdienst erfasst, außerdem spart ihr euch spezielle Berechtigungen, da ihr einen DSM-Nutzer mit WebDAV-Berechtigung benutzt.

Die Voraussetzung ist also, dass ihr WebDAV auf eurer DiskStation eingerichtet habt und einen Benutzer parat habt, der WebDAV nutzen kann (es empfiehlt sich, einen separaten Nutzer zu verwenden der nur die WebDAV-Berechtigung besitzt, ihr solltet auf keinen Fall einen DSM-Benutzer mit Admin-Berechtigung verwenden).

Habt ihr den WebDAV-Server auf eurer DiskStation aktiviert, könnt ihr in Nextcloud die App “External Storage support” (zu finden unter Apps > Vorgestellte Apps) aktivieren in den Administrationseinstellungen > Externer Speicher (Abschnitt “Administration”) könnt ihr dann den externen Speicher – sprich Ordner – hinzufügen:

• Vergebt einen Namen, unter dem der Ordner in Nextcloud angezeigt werden soll.
• Wollt ihr den Ordner oder Inhalte in der Teilen-Funktion von Nextcloud verwenden, müsst ihr das unter “Einhänge-Optionen” explizit aktivieren.
• Ihr könnt den externen Ordner auf bestimmte Benutzer begrenzen.
• Wählt als Externer Speicher Typ “WebDAV” aus.
• Als Authentifizierung wählt ihr “Anmeldename und Passwort”.
• Gebt als URL die URL eurer DiskStation ein, gefolgt von einem : und dem Port 5006. Die URL muss über ein SSL-Zertifikat abgesichert sein.
• Gebt jetzt den Pfad zum Ordner ein. Ihr könnt direkt mit dem Namen des Freigegebenen Ordners beginne und müsst nicht /volumeX/davor setzen, oder mit /homes/… auf die einzelnen home-Verzeichnisse und deren Unterordner der Benutzer zugreifen.
• Vergewissert euch dass “Sicheres https://” aktiviert ist.
• Anschließend gebt ihr noch den DSM-Benutzer und das Passwort ein. Der Benutzer muss Berechtigungen für WebDAV, sowie Lesen und Schreibberechtigungen für den Ordner haben.

Alternativ könnt ihr auch “Personen erlauben, externen Speicher einzubinden” aktivieren. Dann bekommt jeder Benutzer in seinen Einstellungen einen Menüpunkt Externer Speicher und kann dort selbst Ordner einbinden (die dann nur der jeweilige Benutzer sieht).

Zusatzinfos zu Benutzer und Berechtigungen

Nachfolgend noch ein paar Hintergrund-Infos zur Situation mit den Berechtigungen bei ausgelagertem /data-Verzeichnis. Ich freue mich über Feedback, sollte hier jemand mehr wissen als ich bzw. andere Lösungen gefunden hat.

Nextcloud verwendet im Container (und auch für den Zugriff auf die gemounteten Ordner) den Standard Systemuser des Apache www-data. Diesen gibt es aber auf der DiskStation nicht, bzw. auch wenn es ihn gäbe, wäre dadurch nicht gesagt, dass beide die selbe UID und GID hätten, denn darum geht es eigentlich. Das ist übrigens keine spezielle Situation die auf das Nextcloud Image oder Synology zurückzuführen ist, sondern ist Standard bei Docker unter Linux.
Um dieses “Problem” zu lösen, gibt es verschiedene Lösungswege und wer schon länger mit einer DiskStation arbeitet kanns vielleicht erraten, keine davon funktioniert mit DSM bzw. nicht richtig.

Für den Ordner /docker scheint Synology eine eigene Lösung implementiert zu haben, die automatisch funktioniert. Möchte man aber Ordner außerhalb von /docker mounten, muss man, wie in diesem Fall, die Berechtigungen selbst setzen. Das geht dann eben nicht über die DSM-GUI da der User ja nicht existiert sondern nur über die Kommandoziele. Auch hier ist man wieder limitiert, da man die Ownership des Ordners auf den nicht-existenten Benutzer übertragen muss. Es gibt unter Unix zwar die Möglichkeit über die Kommandozeile einen Benutzer als berechtigt einzutragen, ohne die Ownership zu ändern, aber – ihr habts erraten – auf der DiskStation geht das nicht.

Laut Nextcloud-Community sollte es möglich sein über Docker Compose eine UID und GID anzugeben, die dann vom Nextcloud Container verwendet wird. Das scheint aber nicht immer (bzw. auf DiskStations gar nicht) zu funktionieren und außerdem Probleme mit Redis verursachen, die wieder einen Workaround benötigen.

Eine weitere Alternative: Es ist möglich einen Benutzer anzulegen und nachträglich die UID und GID zu ändern. Das ist aber riskant. Die UID und GID des Nextcloud-Containers liegen unter 1024, also im Bereich den DSM als Systemreserviert betrachtet. Es kann also durchaus sein, dass diese UID bereits in Verwendung ist oder durch Installation von Paketen, oder DSM-Updates, nachträglich beansprucht wird. Das würde im schlimmsten Fall dazu führen, dass die DiskStation bzw. das betroffene Service nicht funktioniert. Außerdem könnte die Änderung (wie viele DSM-Workarounds) durch ein DSM-Update rückgängig gemacht werden. Was aber letzten Endes gegen diese “Lösung” spricht (ja ich hab sie getestet). Der Benutzer und die Gruppe, deren UID/GID man nachträglich ändert verschwinden aus der DSM-GUI. Berechtigungen müssen also erst recht wieder über die Kommandozeile bearbeitet werden. Man gewinnt dadurch also nichts.

Ich habe die im Artikel beschriebene Lösung seit einigen Monaten in Verwendung und keinerlei Probleme, sowohl in Nextcloud als auch DSM/Synology Paketen feststellen können. Neustarts bzw. Updates sowohl von DSM als auch Nextcloud haben bisher auch keine Probleme verursacht.

Als andere Alternative könnt ihr noch das Nextcloud-Image von Linuxserver verwenden. Das Image unterstützt die Übergabe von UID/GID als Parameter. Das Image funktioniert auf der DiskStation, ich selbst konnte es aber nicht zum Laufen bringen.

Fazit

Ihr habt jetzt Nextcloud als Docker-Container auf eurer Synology DiskStation eingerichtet. Ihr könnt eure Nextcloud erweitern, indem ihr Apps installiert, erforderliche Services könnt ihr als Docker-Container dem Projekt hinzufügen. Eure Cloud ist von DSM weitestgehend abgekapselt und ihr könnt die Cloud aktualisieren, ohne andere Services auf der DiskStation zu beeinträchtigen. Ihr könnt das Cloud-Projekt ganz einfach über Hyper Backup oder andere Methoden sichern und wenn ihr einmal etwas falsch konfiguriert habt, könnt ihr den entsprechenden Container einfach löschen und neu erstellen.