USB-Stick, SDD in Nextcloud docker einbinden

Ich kenne zwar weder Nextcloud, noch Docker, aber gemountet wird üblicherweise mit "mount" und "umount" hängt die Partition wieder aus.

Gemounted wird auf einen Mountpoint, der vom Admin mit mkdir zu erstellen ist.

Soll auch neben root ein User mounten dürfen, ist die Option user bzw. users in den Mountbefehl aufzunehmen.

Grundsätzlich soll nicht mit dem Device-Deskriptor (/dev/sda1), sondern mit der UUID, PARTUUID, oder dem LABEL der zu mountenden Partition gemounted werden.

Die Option "nofail" verhindert das Anhalten des Mount Programmes beim Abarbeiten der fstab, falls das Gerät nicht angeschlossen ist.

< man mount > und < man fstab > beschreibt die Verwendung des mount Befehles und den Eintrag in die /etc/fstab

Die alternative Verwendung einer systemd-mount Unit ist nur für versierte Admins zu empfehlen.

Servus !

Mir ist nicht ganz klar, wie du die Verzeichnisse deines NextCloud Containers auf deinen USB Stick/Drive mappst.

Normalerweise geschieht das im Docker über sogenannte "Bind Mounts" oder "Volumes". Sie werden beim Erstellen eines Containers mit `docker create ...` oder `docker run ...`mit dem paramater --mount, oder --volume, bzw -v festgelegt. Damit lässt sich dein gewünschtes Verzeichnis auf der USB-Festplatt dem NextCloud Datenverzeichnis zuweisen.

Der erste Start von NextCloud könnte dann irgendwie so aussehen:

docker run -d -v /media/usbstick/var/html:/var/www/html nextcloud

Sowas fehlt mir bei all dem was du geschrieben hast.

Auf diese Art werden die Daten auf dem USB Stick, bzw. Festplatte/Stick beim löschen des Containers dann auch nicht gelöscht. Wie das unter Portainer bewerkstelligt wird weiss ich allerdings auch nicht, da ich Portainer nicht nutze.

Ich sehe, da gibt es unter NextCloud offenbar ganz viele Verzeichnisse, die irgendwie zugeordnet werden müssen. Da ich NextCloud nicht kenne, kann ich dazu nicht viel sagen. Ich kann dir höchstens sagen, wie Docker die Daten verwaltet.

Dazu zuerst eine kurze Erklärung. Ohne weiteres zutun verwaltet Docker seine Objekte alle unter dem Verzeichnis /var/lib/docker/. Darin gibt es verschiedene Unterverzeichnisse, wobei containers, image, network, volumes und overlay2 zu den wichtigsten gehören. Die Dateien in diesen Verzeichnisse beschreiben die Docker-Objekte, oder enthalten selber Verzeichnisstrukturen mit den zu einem Container oder einem Docker Volume gehörenden Dateien.

Docker verwendet normalerweise zur Verwaltung des Inhalts der Container den overlay2 Storage Driver. Wird jetzt z.B. ein Container mit dem Namen mein-container angelegt, dann werden unter /var/lib/docker/containers/main-container/ diverse Dateien angelegt, die den Container beschreiben.

Gleichzeitig werden unter /var/lib/docker/overlay2 mehrere Unterverzeichnisse mit den Verzeichnis- und Datenstrukturen innerhalb des Containers angelegt. Da diese Verzeichnisse über Schlüssel angelegt sind, ist es nicht ganz trivial, zu erklären, welches Verzeichnis zu welchem Container gehört.

Werden im erstellten Container Dateien angelegt oder verändert, so sind die auch noch vorhanden nachdem der Container gestoppt und wieder gestartet wurde.

Wird ein Container aber gelöscht, dann werden auch seine Verzeichisse mit allen darin enthaltenen Daten unwiederbringlich gelöscht!

Dabei soll gleich mal gesagt werden, dass man NIEMALS in diese Verzeichnisse eingreifen sollte. Alles was sich unter /var/lib/docker/ befindet gehört Docker!!!

Damit man seine Daten aber getrennt von Container, aber immer noch unter innerhalb des Docker Systems halten kann, gibt es die Docker Volumes. Sie befinden sich unter /var/lib/docker/volumes. Wird ein Container gelöscht, dann bleiben die Volumes immer noch erhalten und können einem anderen Container wieder zugeordnet werden. So kann ich z.B. eine alte Version eines Containers, oder eine geänderte Konfigurtion einfach durch eine neue Version ersetzen und beim Erstellen des neuen Containers das Volume wieder zuordnen. Das ist der Weg den ich meistens nutze. Das gibt mir grosse Flexibilität.

Es gibt allerdings noch einen heiklen Punkt. Der Befehl docker volume prune löscht sämtliche zum Zeitpunkt nicht benutzten Volumes.

Die nächste Möglichkeit, mit der man jetzt seine Daten völlig ausserhalb des /var/lib/docker/ Verzeichnisses halten kann, sind die Bind Mounts. Es mag Gründe geben --bind zu verwenden, aber ich benutze immer die Form -v /verzeichnis-auf-host/:/docker-internes-verzeichnis/, wobei die Angabe des Host-Verzeichnisses auch relativ zum Verzeichnis sein kan, aus welchem der Container gestartet wird.

Noch kurz zu den Rechten. Es kommt jetzt drauf an wie dein Docker konfiguriert ist, bzw. wie deine Container laufen. Läuft alles privilegiert unter root ab, dann ist root sowieso der Owner und kann alles überschreiben. Läuft der Container aber unter einem unprivilegiertem User, dann muss das Verzeichnis bereits bestehen und der User muss die Rechte auf dieses Verzeichnis haben.

Wie auch immer, das angegebene Verzeichnis muss natürlich in deinem Fall zum Zeitpunt bei dem der Container gestartet wid bereits gemountet sein und für den Zugriff als User, unter dem der Container läuft, mit allen benötigten Rechten zugänglich sein.

Abschliessend muss ich noch erwähnen, dass ich noch nie versucht habe, Daten auf ein anderes Laufwerk, als dem auf dem auch der Container läuft, auszulagern. Ich habe leider keinen Pi zur Hand mit dem ich das gerade ausprobieren könnte.

Wenn du dich mit Docker unsicher fühlst, dann würde ich dir raten, dir ein paar Tage Zeit zu nehmen und dich damit ganz ohne Portainer und NextCloud zu befassen. Einfach mal ein paar Container hochziehen um damit zu spielen, Ports zuweisen, Verzeichnisse mounten, Volumes und evtl. sogar Networks zu nutzen. Portainer würde ich erst nutzen, wenn ich das, was darunter liegt, verstanden habe und nicht umgekehrt. Und "last, but not least", mach dir auch Gedanken darüber, wie du deine NextCloud am besten sichern kannst.

Post

RE: NextCloud, neue HDD Daten verschieben

[…]

hyle

Mar 23rd 2021

Servus !

Hier gibt es auch noch etwas zum Thema:

Post

Portainer Volume Externe HDD

Hallo zusammen, ich bin neu hier im Forum und hoffe, dass mir hier der eine oder andere weiterhelfen kann.


Mein System sieht folgendermaßen aus:

Hardware: RP4 8GB Speicher mit einer 128 GB MicroSD Speicherkarte + Externe USB Festplatte 6 TB WD

Software: Openmediavault (Docker + Portainer) und Nextcloud V24

Über den Portainer konnte ich bereits Nextcloud und den Plex Server installieren. Das hat auch alles wunderbar geklappt.

Die Nextcloud greift auf die Ext. HDD via SMB zu. Ich würde aber gerne…

erkanovicz

Oct 17th 2022

Um der Sache auf die Sprünge zu helfen, habe ich heute auf einer frischen 32GB µSD Karte Raspberry Pi OS (64 bit) mit Docker, sowie Portainer und NextCloud installiert. Nachdem soweit alles geklappt hat, bin ich einen Schritt weiter gegangen und habe eine freie 64 GB Partition von meiner USB SSD eingebunden. In einem letzten Schritt habe ich einen neuen NextCloud Container angelegt, bei dem ich die Konfiguration so angepasst habe, dass alle Daten von NextCloud auf der freien Partion der SSD liegen.

Bei meinem Vorgehen habe ich möglichst alles was störenden Einfluss haben könnte bei Seite gelassen. Das heisst insbesondere, dass ich Docker als voll-privilegierten Dienst und nicht im Rootless Modus betreibe. Nicht privilegierte User, wie pi, können Docker aber trotzdem ausführen, wenn sie Mitglied der Gruppe docker sind. Das bedeutet aber auch, dass sie über Docker uneingeschränkte root-Rechte haben (was pi mit sudo ohnehin hat).

Ähnliches gilt für Portainer und NextCloud. D.h. ich habe die Doku nicht auf sicherheits-relevante Massnahmen geprüft, die ggf zu treffen sind. Unter Portainer habe ich keine zusätzlichen User angelegt. Ich habe alles mit den Rechten eines Admins unter dem Administrations-Account gemacht, der beim ersten Login erstellt wurde. Und wiederum gilt dasselbe für NextCloud. Es gibt nur einen User und das ist der, welcher beim ersten Login angelegt wurde und Benutzer anlegen kann etc..

Mein Vorgehen war im Einzelnen wie folgt, wobei ich bei den trivialen Dingen nicht auf Details eingehe, diese aber gerne nachliefere.

Schritt 1: Vorbereitung Pi 4

Ich habe eine frische 32GB µSD Karte mit Raspberry Pi OS (64 bit) bespielt, damit meinen Pi 4 gestartet, mich über ssh in einer Terminal-Situng mit dem User pi auf den Pi4 eingeloggt und den Pi mit raspi-config vorkonfiguriert (Expand Filesystem, locals, etc).

Danach habe ich den Pi neu gestaret.

Schritt 2: Updates und Docker installieren

Nach dem Reboot und erneutem Login habe ich den Pi mit sudo apt update && sudo apt upgrade zuerst noch auf den neusten Stand gebracht.

Dann habe ich mit dem Convenience-Script Docker installiert:

pi@pi4:~ $ curl -fsSL https://get.docker.com -o get-docker.sh
pi@pi4:~ $ sudo sh get-docker.sh

Anschliessend habe ich die docker-Gruppe erstellt und den User pi hinzugefügt.

pi@pi4:~ $ sudo groupadd docker
pi@pi4:~ $ sudo usermod -aG docker $USER

Danach habe ich den Pi wieder neu gestartet!

Schritt 3: Docker testen

Jetzthabe ich eine neue ssh-Termnal-Session eröffnet und sofort Docker getestet.

pi@pi4:~ $ docker run hello-world

Das hello-world Image wurde jetzt vom Docker Hub geholt und ist in einem neuerstellten Container mit einem zufällig gewählten Namen abgelaufen. An dieser Stelle düfen keine Fehler auftreten. Da keine Fehler aufgetreten sind, war ich bereit zur Installation von Portainer.

Schritt4: Portainer installieren

Als Erstes habe ich mit unter https://hub.docker.com/r/portainer/portainer-ce die Dokumentation zum Container inlusive der darin enthaltenen Verweise auf weitere Dokumentationen zu Portainer angeschaut.

Daraus ging hervor, dass für Portainer ein Docker Volume mit dem Namen portainer_data erstellt werden sollte, so dass auch ein neuer Container mit einem aktualisierten Image oder anderen Parametern erstellt werden kann, ohne dass die Daten verloren gehen. Dieses Volume kann dann beim Erstellen des Containers verwendet werden. Es wird in der Dokumentation zudem auch die Bedeutung der sonstigen Parameter und die Verwendung der Ports erklärt.

Also erstellte ich ein Volume und erstellte/startete einen Container mit dem Namen portainer dessen Daten im Volume portainer_data verwaltet werden.

pi@pi4:~ $ docker volume create portainer_dataverwaltet 
pi@pi4:~ $ docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always \
-v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

Jetzt konnte ich mich mit meinem Browser im LAN mit https://pi3:9443 zum ersten Login auf den Portainer verbinden. Da Portainer ein eigenes, aber ungültiges Zertifikat verwendet, musste ich natürlich zuerst meinen Browser überlisten, damit er die Verbindung überhaupt zuliess.

Nach der ersten Anmeldung als Administrator stand mir Portainer offen zur Verfügung und ich konnte Portainer so besser kennenlernen. Es ist sehr lange her, dass ich da zum letzten mal reinblicken konnte ;).

Nachdem mir klar war, wie die Images geholt und unter Portainer verwaltet werden, konnte ich mich an den nächsten Schritt wagen: dem Erstellen eines NextCloud Containers.

Schritt 5: NextCloud Container installieren und konfigurieren

Und wieder habe ich mir als Erstes auf dem Docker-Hub unter https://hub.docker.com/_/nextcloud die Dokumentation zum Container angeschaut, wobei für mich der Abschnitt Persistent data von besonderem Interesse war.

Da steht nämlich, unter anderem: "... /var/www/html/ folder where all Nextcloud data lives...".

Das sagt mir, auf das Problem mit den Verzeichnissen bezogen, schon fast alles.

Das Ziel war jetzt einen NextCloud Container mit SQLite zu erstellen, dessen Daten sich aus der Sicht des Containers im Verzeichnis /var/www/html/ befinden, das sich aber auf dem Host ausserhalb der von Docker verwalteteten Daten (unter /var/lib/docker) befinden soll.

Um Nextcloud überhaupt mal kennen zu lernen erstellte ich im Portainer einfach mal einen neuen Container mit dem namen nextcloud aus dem oben verlinkten Image vom Docker Hub. Ich nahm keine weiteren Konfigurationen vor und liess Portainer einfach mal machen.

Und das Ergebnis war nicht mal so schlecht. Es wurde automatisch ein Port mit einer etwas ungewohnten Port-Nummer (32767 oder so) auf den Docker internen Port 80 gemappt und es wurde ein Volume mit einer unverständlichen ID anstelle eines sinnvollen Namens erstellt. Mit der Portnummer konnte man jedenfalls zugreifen und es hat soweit alles geklappt.

Aufgrund der gemachten Erfahrung stoppte und löschte ich den Container und erstellte ihn mit einer anderen Konfiguration neu, wobei ich drei Dinge änderte:

1. Unter Network Ports Configuration setzte ich die Einstellung auf Manuell und erstellte einen neuen Eintrag mit Port 8080 auf der Host-Seite und Port 80 auf der Container-Seite.

2. Unter Advanced Settings/Volumes erstellte ich einen neuen Volume mapping Eintrag vom Typ Bind mit /var/www/html auf der Container Seite und /ssd/var/www/html vom Typ Writeable auf der Host-Seite. Das Prefix /ssd habe ich nur gewählt weil es stellvertretend für meine SSD Festplatte am USB-Port stehen sollte. Es könnte auch anders heissen.

3. Unter Advanced container settings/Restart policy setzte ich den Wert von Restart policy auf Unless Stopped. Es ist natürlich immer eine Überlegung wert, was für die Awendung am Besten ist. Gerade wenn es noch nicht rund läuft ist es natürlich doof, wenn der Container immer wieder neu gestarted wird wenn er crashed und sich dieser Vorgang dann endlos wederholt.

Da der Container mit root-Rechten läuft, ging ich davon aus, dass damit auf der µSD-Karte ein Verzeichnis /ssd/var/www/html/ erstellt wird unterdem sich alle NextCloud Daten befinden werden. Also startete ich den Container und es funktionierte. Das Volume mit der langen ID im Namen, das mit dem alten Container erstellt wurde, löschte ich mit dem Befehl docker volume remove <name>. (wobei <name> für diese ID steht.

Jetzt stoppte ich den Container wieder und löschte alles, was zum gegenwärtigen Zeitpunkt innerhalb des Verzeichnisses /ssd/ lag um ab jetzt, das Verzeichnis /ssd als Mount Point für die freie Partition auf meiner SSD zu benutzen.

Im Portainer habe ich ansonsten die Container Definition so belassen wie sie ist.

Schritt 6: SSD an USB anschliessen und fest integrieren

Als Erstes habe ich meine SSD Festplatte an einem der USB 3.0-Ports angeschlossen. Ich wusste bereits, dass die freie 64 GB linux Partition über /dev/sda4 adressiert werden kann. Sie war zwar als Linux Partition partitioniert, hatte aber noch kein File-System. Somit erstelle ich ein ext4-Filesystem und mountete die Partition auf das leere Verzeichnis /ssd als Mount Point.

pi@pi4:~ $ sudo mkfs.ext4 /dev/sda4
pi@pi4:~ $ sudo mount /dev/sda4 /ssd

Natürlich testete ich an dieser Stelle noch ob alles richtig ist und da das Verzeichnis auf der SSD mit root-Rechten beschreibbar war, löschte ich die Test-Daten wieder und unmountete die Partition wieder mit sudo umount /ssd.

Mit lsblk -o NAME,PATH,PARTUUID versuchte ich dann zuerst die PARTUUID der Partion herauzufinden, die ich von meiner SSD mounten möchte. Das Resultat für /dev/sda4 war in meinem Fall eine PARTUUID mit dem Wert 12939a7f-04.

Damit erstellte ich einen passenden Eintrag in der Datei /etc/fstab, so dass die Partition bei jedem Systemstart gemountet wird. Das bedeutet auch, dass ab jetzt die SSD fester Bestandteil meiner Installation ist und NICHT mehr entfernt werden darf.

So hat danach meine /etc/fstab ausgesehen (die vierte Zeile ist neu dazugekommen).

proc                 /proc           proc    defaults          0       0
PARTUUID=9c174a96-01 /boot           vfat    defaults          0       2
PARTUUID=9c174a96-02 /               ext4    defaults,noatime  0       1
PARTUUID=12939a7f-04 /ssd            ext4    defaults,noatime  0       2
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

Da soweit alles geklappt hat, kam jetzt als letzter Schritt ein Neustart!

Schritt 7: Neustart - ab jetzt mit NextCloud Daten auf SSD

Ich hatte den Pi 4 neu gestartet und als erstes geprüft ob die Festplatte richtig gemountet wurde und bereit für den Einsatz ist.

Dann habe ich mich im Portainer eingeloggt und den bereits fertig konfigurierten Container mit dem Namen nextcloud wieder gestartet!

Ich war etwas versunsichert und fragte mich was passiert, da doch jetzt alle Daten weg sind und nur noch ein leeres Verzeichnis vorhanden ist.

Aber es geschah was ich erwartet hatte. Als ich mich über das Web einloggen wollte, musste ich meinen ersten User wieder neu erstellen und alles wurde neu konfiguriert, wie nach dem ersten Start eines neuen leeren NextCloud Containers.

Es ging dann alles ohne weitere Probleme über die Bühne und nachdem alles neu installiert war, habe ich mit sudo ls -al /ssd/var/www/html/ kontrolliert, was da vorhanden ist und es sah gut aus. Man könnte jetzt meinen, dass alles erledigt ist, aber da fehlt doch noch etwas.

Schritt 8: Neustart wie im Echt-Betrieb

Neustart und Test. Ja, ohne vorher die Container zu stoppen, habe ich den Raspberry Pi neu gestartet. Ich konnte mich danach problemlos wieder in den Portainer sowie meinen NextCloud Account einloggen. Die vorher im Test erstellten Dateien waren alle vorhanden und soweit scheint es gut gelaufen zu sein.

Ich hoffe, dass das vielleicht weiterhilft. Bei Unklarheiten bin ich gerne bereit weitere Details zu liefern. Ich werde die µSD-Karte vorläufig aufbewahren, damit ich ggf. darauf zurückgreifen kann. Die SSD mit der freien Partition hängt sowieso an meinem Pi 4.

_/ Peter

P.S. Typos dürft ihr behalten

Ich habe mal #10 in den Forumsperlen unter "Codeschnipsel" aufgenommen.

Ich weiss, das das eher eine Anleitung ist.

MfG

Jürgen

Quote from Nihilo9

[...] Da ich jetzt keinen eigenen Weg gehen wollte habe ich den USB-Stick auch auf /ssd gemountet und den Nextcloud-Container wieder gestartet und mich bei Nextcloud eingeloggt. Ich habe auf installieren geklickt und 30 min gewartet die Installation ist leider noch nicht abgeschlossen und der Raspi hat sich aufgehängt. Jetzt komme ich auch nicht mehr auf Portainer. Authentifizierungsfehler: unauthorized.

Ich habe keine Ahnung was da schief gelaufen ist. Das hat bei mir gerade mal ein paar Minuten gedauert. Ich kann jetzt auch nicht genau sagen wie lange das genau gedauert hat, vielleicht 3 Minuten oder weniger oder etwas mehr. Aber niemals 30 Minuten. Ich verwendete eine Samsung Portable SSD T7. Die ist recht schnell. Mit einem Stick könnte ich mir schon vorstellen, dass es länger dauert oder dass es evtl. sogar Probleme gibt.

Quote from Nihilo9

Noch eine andere Frage. Wenn ich das so mache wie in deiner Anleitung beschrieben habe ich die SSD dann nicht als externe Festplatte, sondern als Hauptspeicher. Idealerweise wollte ich eigentlich die SSD als externe Festplatte zu Nextcloud hinzufügen, sodass darauf keine Systemdaten liegen sondern nur meine Daten.

Der Begriff "Hauptspeicher" passt nicht so ganz. Hauptspeicher von NextCloud, ja.

In der Konfiguration, wie ich sie beschrieben habe, liegt in der "externen" Partition alles was zu NextCloud gehört. Aus der Sicht des Containers, bzw. von NextCloud, ist das alles was im Verzeichnis /var/www/html/ liegt. Dazu gehören auch .php-Dateien, diverse Ressourcen, Apps, Libraries, Themen, etc. Im Unterverzeichnis /var/www/html/data scheinen die eigentlichen Daten und Benutzerverzeichnisse zu liegen.

Möchte man das Datenverzeichnis vom Rest trennen, dann wäre das möglich, indem man zum Beispiel ...

a) ein Docker Volume mit dem Namen nextcloud erstellt und eine Zuweisung des Volumes nextcloud auf /var/www/html/ macht ...

b) mit einem Bind Mount das Verzeichnis /ssd//var/www/html/data/ dem NextCloud Verzeichnis /var/www/html/data/ zuweist.

Dadurch würde das Datenverzeichnis vom Rest getrennt und die vermutlich eher statischen Dateien von NextCloud wären dann im Volume nextcloud persistent aufgehoben.

Soweit ich weiss geht das, ich habe es aber nicht getestet. Theoretisch wäre es auf diese Weise möglich, den Container zu stoppen, die Festplatte zu entbinden und zu entfernen. Die Festplatte müsste wieder drin und gemountet sein, wenn immer der Container gestartet wird.

Quote from Nihilo9

Idealerweise wollte ich eigentlich die SSD als externe Festplatte zu Nextcloud hinzufügen, sodass darauf keine Systemdaten liegen sondern nur meine Daten. Wenn ich sie auf ntfs Dateisystem formatiere dann könnte ich sie abstecken und an einen Windows Computer anstecken und so auch meine Daten lesen oder?

Außerdem könnte ich gegebenenfalls noch eine 2 Festplatte hinzuhängen.
Stelle ich mir das zu einfach oder falsch vor?

Ich würde das aus mehreren Gründen nicht in Erwägung ziehen:

1. Ich muss jetzt zugeben, dass ich zuwenig weiss, wie NextCloud aufgebaut ist. Aber, wenn ich mir das Verzeichnis /ssd//var/www/html/data/ anschaue, dann sehe ich darin zwar ein Unterverzeichnis mit meinem User-Namen und darin die Dateien, die ich angelegt habe. Aber es liegen auch noch Dateien da, die ich nicht kenne. Auch im übergeordneten Verzeichnis gibt es nebst Logs noch eine SQLite Datenbank, deren Inhalt und Bedeutung ich nicht kenne und es gibt noch weitere Dateien, von denen ich nicht weiss, wie diese zusammenspielen. Ich kann mir aber vorstellen, dass es besser ist, den Zugriff auf die Daten NextCloud zu überlassen um nicht versehentlich etwas durcheinanderzubringen.

2. Ich weiss nicht was passiert, wenn man versehentlich bei laufendem Container die Platte aushängt.

3. Ich weiss jetzt auch nicht ob Docker NTFS überhaupt unterstützt. Aber das wäre relativ einfach zu klären.

Auf gutes Gelingen !

Frage rein aus Interesse: Warum nicht Nextcloud nativ auf die SSD ??

Weitere Frage: Was für Vorteile hat Dein Weg ??

Aus meiner Sicht keinen. Ich bin lediglich auf den Wunsch des Fragestellers eingegangen.