Es wird ja empfohlen den admin zu deaktivieren und ein eigenen Admin-User anzulegen,
Darfste gerne ignorieren..war nur wilde Panikmache von QNAP (nach den ganzen Malware wellen von weboffenen NAS). Der admin bleibt intern immer aktiv...egal wie aktiviert der ist.
Hallo,
dolbyman alles klar, dann lasse ich den aktiviert. Dann sollte es auch keine Probleme geben.
Da aktuell noch nichts weitere auf der Container Station läuft, teste ich mal was passiert, wenn ich den User deaktivere. Lässt sich ja leicht wieder rückgängig machen und im Zweifelsfall nochmal schnell nue aufsetzen.
2. Ich würde das bookstack gerne freigeben, sodass ich öffentlich über eine Domain darauf zugreifen kann. Dazu muss ich DDNS einrichten und den Port in der Fritzbox weiterleiten, was ja aus sicherheitstechnischer Sicht nicht ideal ist....
Was haltet ihr meiner Hypothese bzgl. Sicherheit und Zugriff durch das admin-Konto? Oder hat das nichts miteinander zu tun?
Da bräuchte ich etwas Nachhilfe ?! 
EInen schönen Abend und viele Grüße
Wenn Du den Container wie dargestellt eingerichtet hast, läuft der unverschlüsselt mit http. Das solltest Du keinesfalls ins Internet freigeben.
Also solltest Du einen Proxy - hier empfehle ich caddy als Docker-Container - davorschalten und die externen Ports 80 und 443 auf den Caddy-Container weiterleiten. Der übernimmt die https-Verschlüsselung und das Zertifikatsmanagement.
Der Caddy-Container ist relativ sicher und wird unter anderem auch bei der Nextcloud-AIO eingesetzt. Der Vorteil ist außerdem, dass Du ggf. noch weitere Container-Dienste mit Caddy auf sicherem Wege ins Internet freigeben kannst.
Hier mal eine Beispiel YAML-Daei für Caddy:
version: "3.7"
services:
caddy:
container_name: caddy
image: caddy:alpine
restart: always
network_mode: "host"
ports:
- "80:80"
- "443:443"
volumes:
- /share/CACHEDEV1_DATA/Public/caddy/Caddyfile:/etc/caddy/Caddyfile
- /share/CACHEDEV1_DATA/Public/caddy/data:/data
- /share/CACHEDEV1_DATA/Public/caddy/config:/configDie ganzen Daten von Caddy werden im Verzeichnis Public/caddy abgelegt.
Und hier noch ein Beispiel für das benötigte Caddyfile:
https://DEINE.DYNDNS.ADRESSE:443 {
handle_path /bookstack* {
reverse_proxy http://IPADRESSE.DES.NAS:6875
}
}Damit der Caddy-Container funktioniert, muss der interne Webserver des NAS abgeschaltet werden, oder die Standardports 80 und 443 auf andere Ports gelegt werden. Aber eigentlich brauchst Du den unsicheren Apache im QTS nicht. Bitte auch schauen, dass der Systemmanagementport des NAS auf 8080 (http) und 8081 (https) steht. Ansonsten belegt dieser nämlich in der Standardeinstellung den Port 443 (https).
Der Caddycontainer übernimmt das komplette Zertifikatsmanagement mit Letsencrypt und sichert als Reverse Proxy den internen Container zusätzlich ab.
Was natürlich selbstverständlich sein sollte, dass Du für den Adminzugang von bookstack ein sicheres und komplexes Passwort wählst und zumindest für den Admin-Zugang auch Multifaktor-Authentifizierung aktivierst.
Mit dem obigen Caddyfile ist bookstack dann unter folgender URL erreichbar: https://DEINE.DYNDNS.ADRESSE/bookstack. Diese Konfiguration hat den Vorteil, dass Du mit Subdirs weitere Dienste unter der gleichen DYNDNS-Adresse nutzen kannst, zum Beispiel Nextcloud-AIO.
Den Port vom Bookstack würde ich lassen. Intern aus dem LAN kann er ganz normal über die IP-Adresse aufgerufen werden. Ist dann caddy als Proxy installiert, funktioniert der Zugriff über die Dyndns-Adresse von draußen.
Achtung: Bitte auch beachten, dass dann die URL in der bookstack-Konfiguration angepasst werden muss!
Guten Morgen,
leider wird es wohl noch ein paar Tage dauern bis ich dazukomme, den reverse-proxy mit caddy zu installieren.
Nach dem bookstack die Volumes Container-intern angelegt hat, frage ich ich mich aber wie ich das ganze am besten regelmäßig sichere?
In HBS3 kann ich den Pfad Container/container-station-data/... nicht auswählen 
Ich habe zuvor schon adguardhome in der ContainerStation laufen gehabt. Seltsamerweise konnte ich dies ohne probleme unter dem eigenen "Admin-TS-462" installieren ohne das es einen Konflikt gab. Allerdings gibt es einen Unterschied im Aufbau der beiden Anwendungen.
adguardhome: 2 Volumes und 1 Container
bookstack: 2 Volumes und 2 Container
Mir scheint, dass das Problem darin liegt, wenn die Container untereinander Zugriff benötigen. Die Ursache dafür bleibt mir jedoch ein Rätsel.
Sollte ich dann grundsätzlich alle Container unter "admin" aufsetzen?
Viele Grüße
Guten Morgen,
aktuell gibt es keine eingebaute Möglichkeit, Bookstack zu sichern:
Backup and Restore · BookStack
Du kannst aber über HybridBackupSync den Pfad /Container wegsichern - dann hast Du jeweils eine Sicherung aller Container. Was bei dieser Variante schwierig bis unmöglich ist: einen einzelnen Container zurückzusichern.
In HBS3 kann ich den Pfad Container/container-station-data/... nicht auswählen
Dieser Pfad steht unter der Verwaltung der Containerstation. Der wird auch bei einer Sicherung des Ordners /Container wohl nicht gesichert. Du hast dort keine Rechte. Man kann diese zwar erhalten, aber nach einem Update sind diese wieder weg.
Wenn Du die Daten sichern willst, mußt Du ein eigenes Volume bzw. Freigabe nutzen.
Oder Du nutzt für alle Vorgänge den Original admin.
Bei YAML Dateien werden nur die in der YAML Dateien genannte Volumes verwendet, Container Volumes kann man nicht verwenden. Es sei denn, du gibst den Pfad in der YAML Datei an.
Ganz abgesehen von den Volumes, Bookstack kann man komplett nur zusätzlich über SQL sichern.
Eine komplette Sicherung über HBS ist daher nicht möglich.
Ich versuche mal, ein bisschen Licht ins Dunkel mit den Volumes zu bringen:
Es gibt zwei Möglichkeiten, bei Docker Daten außerhalb des Containers zu speichern.
1. Docker-Volumes:
Hier werden die Daten in einer Art "Container" abgespeichert und im Dateisystem des NAS ist nur eine Datei (nämlich der Datencontainer) zu sehen. EIn direkter Zugriff auf die Daten innerhalb des Volumes ist nur über Docker-Befehle möglich.
Gemountet wird so ein Docker-Volume in der YAML-Datei über seinen Namen, z.B.:
volumes:
- ./config:/config2. Gemappte Verzeichnisse des Hosts:
Hier werden die Daten im Dateisystem des Hostsystems gespeichert, dadurch sind im Dateisystem des NAS dann auch alle einzelnen Dateien sichtbar. Es ist theoretisch ein direkter Zugriff auf einzelne Daten direkt mit Mitteln des NAS (z.B. Filestation oder SMB-Freigabe) möglich.
Gemountet wird so ein Volume mit dem vollständigen Pfad auf dem Host:
volumes:
- /share/CACHEDEV1_DATA/Public/config:/configGrundsätzlich ist es so, dass der volumes-Befehl innerhalb der YAML-Datei diese Syntax hat:
Variante 1:
- NAME_DES_VOLUMES:MOUNTPOINT_INNERHALB_DES_CONTAINERS
Variante 2:
- VOLLSTÄNDIGER_PFAD_AUF_DEM_HOST:MOUNTPOINT_INNERHALB_DES_CONTAINERS
Für die Datensicherung per HybridBackupSync ist die Variante 2 einfacher, da die Datei im Dateisystem des NAS liegen.
WICHTIG: Wie ich bereits unter Post #27 geschrieben und verlinkt habe, gehört zu einem vollständigen Backup immer auch die MariaDB-Datenbank! Diese muss über mysqldump exportiert werden, idealerweise auch auf ein gemapptes Verzeichnis des NAS. Nur wenn Daten UND Datenbank-Dump gesichert werden, geht die Wiederherstellung.
Hier noch mal der Link aus meinem genannten Post:
Backup and Restore · BookStack
So, ich hoffe, damit etwas mehr Licht ins Dunkel gebracht zu haben.
Bei den in Deiner Containerstation als ungenutzt angezeigten Volumes handelt es sich um "echte" Docker-Volumes (Variante 1), die aktuell mit keinem Container mehr verbunden sind. Wahrscheinlich hattest Du erst die Syntax für Docker-Volumes verwendet und jetzt den Container mit gemappten Hostverzeichnissen neu aufgesetzt. Dann bleiben die ursprünglichen Docker-Volumes als ungenutzt zurück. Wenn Du diese nicht mehr benötigst, kannst Du sie mit der Funktion "Bereinigen" (Docker-Befehl prune) löschen lassen.
Hi zusammen,
vielen dank für eure Erklärung.
Ich dachte in dem Container "bookstack" läuft das Programm und in "bookstack_data" liegt die Datenbank. Daher meine Idee beide Container einfach regelmäßig mit HBS3 zu sichern. Wenn ich es richtig verstanden haben bringt das aber nichts, weil beim Export mittels mysqldump was anderes abläuft.
Denn Link ich im Post oben habe ich gesehen, bin aber leider noch nicht dazugekommen das vernünftig durchzulesen 
--> muss ich noch machen!
Den Unterschied zwischen den beiden Varianten habe ich soweit kapiert, darum war Variante 2 zu Begin auch mein Favorit.
Warum jedoch bei den manuell angelegten Pfaden als "echter admin" /share/test/config das Ganze nicht funktioniert kapiere ich einfach nicht.
Das YAML-Skript macht doch nur die Zuordnung weswegen die Pfade zuvor als Freigabeordner angelegt werden müssen?!
Bei den in Deiner Containerstation als ungenutzt angezeigten Volumes handelt es sich um "echte" Docker-Volumes (Variante 1), die aktuell mit keinem Container mehr verbunden sind.
Sorry, jetzt blick ichs gar nicht mehr. 
Mein boockstack habe ich mit folgenden Pfaden aufgesetzt. Aber es werden keine Volumes angezeigt.
volumes:
- ./bookstack_app:/config
und
volumes:
- ./bookstack_data:/var/lib/mysqlich habe die "alten" Volumes gelöscht und bookstack funktioniert noch einwandfrei.
Ist es nicht genau andersrum?
Vielen Dank für eure Geduld und Mühen mit mir!
Hallo,
Du hast wahrscheinlich neue Volumes angelegt. Schau doch einfach mal, ob in Deiner Containerstation jetzt unter Volumes etwas angezeigt wird.
Dann hast Du Verzeichnisse auf dem NAS gemappt. Wenn Du beim Mapping unterhalb des Volumes-Befehl ./ davor gesetzt hast, werden die Daten unter dem Root-Verzeichnis der Containerstation (standardmäßig /share/Container/) abgelegt. Das ist aber suboptimal - besser sind separate Freigabeordner außerhalb des Pfades der Containerstation.
Hintergrund:
Beim Neueinrichten der Containerstation kann es passieren, dass der komplette Inhalt gelöscht wird. Daher immer die Datenverzeichnisse außerhalb des Root-Verzeichnisses der Containerstation ablegen.
Dazu hatte ich ja schon häufiger in diversen anderen Threads, das QNAP College Video zu Containern gepostet
Hier beginnend an der relevanten Stelle
Habe den Pfad gefunden:
Mit dem Befehl aus dem YAML-File
volumes:
- ./bookstack_app:/configwird der Ordner in folgendem Pfad angelegt:
/Container/container-station-data/application/bookstack/bookstack_app
Das ist aber suboptimal - besser sind separate Freigabeordner außerhalb des Pfades der Containerstation.
Ich weiß, das möchte ich ja die ganze Zeit machen... 
Deshalb verweise ich noch einmal auf meine obigen Posts.
Machen wir mal Schritt-für-Schritt:
1. Neuen Freigabeordner über die Systemsteuerung anlegen. Nennen wir ihn mal bookstack. Auf dem Ordner muss der Admin Schreibrechte haben
2. In der YAML-Datei folgenden Pfad für die Volumes eingeben - /share/CACHEDEV1_DATA/bookstack/config:/config
Damit wird der Ordner config des Containers auf die Freigabe bookstack auf dem NAS gemappt. Diese Freigabe kann dann problemlos per HybridBackupSync gesichert werden.