JogiBear

Doch..... Frage: Hast du vor einer Neuinstallation auch alle Installationsreste im Docker gelöscht? AIO legt Volumes an, die vor einer sauberen Neuinstallation gelöscht werden sollten: docker volume ls docker volume rm VOLUME_NAME_OR_ID VOLUME_NAME_OR_IDFrage2: Wo läuft dein Proxy und dein DNS Server? Als Docker auf dem gleichen Server? Auszug aus meinem Wiki: DNS ServerIst der DNS Server auf dem gleichen System in einem Benutzer definiertem Netzwerk installiert, ist der DNS Server nur erreichbar, wenn in den Docker Einstellungen der Host Zugriff auf Benutzer definierte Netzwerke zugelassen ist. Es muss jeder selber wissen, ob er diese Einstellung wählt. Ansonsten ist der DNS Server von Nextcloud AIO aus nicht erreichbar. Proxy ManagerIst der Proxy Manager auf dem gleichen System in einem Benutzer definiertem Netzwerk installiert, wird dieser auch nicht die Nextcloud Instanz erreichen, solange der Host Zugriff nicht erlaubt wurde Ich habe dies ohne Host Zugriff realisiert: HTTP und HTTPS Port von Unraid geändert Proxy Manager läuft in einem eigenen Docker Netzwerk und ist über die Ports 80/443 erreichbar DNS Server läuft auf meiner Firewall, der DNS Eintrag zeigt auf die IP von UNRAID AIO läuft im eigenen AIO Docker Netzwerk und ist über Port 11000 erreichbar, ohne HTTPS HTTPS wird über Proxy realisiert Hoffe das hilft Dir weiter

Ahh, ein Klick auf "erweiterte Ansicht" in den Docker Einstellungen zaubert das Geheimnis von loop2 hervor: Das hatte ich gesucht.....

Bin auch am überlegen..... Ich hatte (außerhalb von Unraid) noch nie Probleme mit BTRFS , so wie es aussieht, machen hier aber aktuell die virtuellen Sachen Probleme. Mein SSD-Cache mit BTRFS läuft schon lange Zeit stabil und hat auch harte Resets überstanden.... alles fehlerfrei.... Ich werde mal zuerst mal das Docker Image entBTRFSen, mal sehen :)

Hallo, mich plagen seint einigen Tagen seltsame Fehler, ich vermute, das hat mit einer Windows 10 VM zu tun, die ich vor einigen Tagen installiert habe. Seltsamer Weise gab es heute morgen auch Probleme mit einigen Docker Containern, appdata backup konnte einige Container nicht starten, vereinzelt traf es auch Container, die appdata backup nicht anfasst. So wie es ausschaut ist wohl irgendwo die Dateistruktur von 'loop2' beschädigt. Allerdings habe ich keine Ahnung ob es sich dabei um die vdisk von Docker handelt oder die vdisk von der VM. Wie kann man herausfinden um was es sich bei dem device 'loop2, loop3' etc. handelt? Die Probleme treten nur sporadisch auf.... kann man die vdisks irgendwie auf Fehler testen? Hier mal das SysLog gefiltert auf BTRFS, vielleicht hat jemand einen Tipp? Zeile 751: Aug 28 21:05:45 Raidy kernel: BTRFS: device fsid 0af2f3df-6537-47ed-8813-ccfadfc799fe devid 2 transid 739589 /dev/sdf1 (8:81) scanned by udevd (974) Zeile 752: Aug 28 21:05:45 Raidy kernel: BTRFS: device fsid 0af2f3df-6537-47ed-8813-ccfadfc799fe devid 1 transid 739589 /dev/sde1 (8:65) scanned by udevd (977) Zeile 1615: Aug 28 21:06:23 Raidy emhttpd: cache: btrfs verify devices Zeile 1616: Aug 28 21:06:23 Raidy emhttpd: /sbin/btrfs filesystem show 0af2f3df-6537-47ed-8813-ccfadfc799fe 2>&1 Zeile 1622: Aug 28 21:06:23 Raidy emhttpd: shcmd (38): mount -t btrfs -o noatime,nodiscard,space_cache=v2 -U 0af2f3df-6537-47ed-8813-ccfadfc799fe /mnt/cache Zeile 1623: Aug 28 21:06:23 Raidy kernel: BTRFS info (device sde1): first mount of filesystem 0af2f3df-6537-47ed-8813-ccfadfc799fe Zeile 1624: Aug 28 21:06:23 Raidy kernel: BTRFS info (device sde1): using crc32c (crc32c-intel) checksum algorithm Zeile 1625: Aug 28 21:06:23 Raidy kernel: BTRFS info (device sde1): using free-space-tree Zeile 1627: Aug 28 21:06:23 Raidy kernel: BTRFS info (device sde1 state M): turning on async discard Zeile 1661: Aug 28 21:06:29 Raidy kernel: BTRFS: device fsid 73865399-bbf8-4560-ab08-1fe47470e847 devid 1 transid 874674 /dev/loop2 (7:2) scanned by mount (9208) Zeile 1662: Aug 28 21:06:29 Raidy kernel: BTRFS info (device loop2): first mount of filesystem 73865399-bbf8-4560-ab08-1fe47470e847 Zeile 1663: Aug 28 21:06:29 Raidy kernel: BTRFS info (device loop2): using crc32c (crc32c-intel) checksum algorithm Zeile 1664: Aug 28 21:06:29 Raidy kernel: BTRFS info (device loop2): using free-space-tree Zeile 1665: Aug 28 21:06:30 Raidy kernel: BTRFS info (device loop2): bdev /dev/loop2 errs: wr 0, rd 0, flush 0, corrupt 2, gen 0 Zeile 1930: Aug 28 21:13:57 Raidy kernel: BTRFS: device fsid 1411a484-ecf5-4a2e-aa64-e46f3a95dcba devid 1 transid 197 /dev/loop3 (7:3) scanned by mount (40619) Zeile 1931: Aug 28 21:13:57 Raidy kernel: BTRFS info (device loop3): first mount of filesystem 1411a484-ecf5-4a2e-aa64-e46f3a95dcba Zeile 1932: Aug 28 21:13:57 Raidy kernel: BTRFS info (device loop3): using crc32c (crc32c-intel) checksum algorithm Zeile 1933: Aug 28 21:13:57 Raidy kernel: BTRFS info (device loop3): using free-space-tree Zeile 3496: Sep 2 17:02:02 Raidy kernel: BTRFS critical (device loop2): corrupt leaf: root=6093 block=11042996224 slot=6 ino=16813665, invalid previous key objectid, have 36449 expect 16813665 Zeile 3497: Sep 2 17:02:02 Raidy kernel: BTRFS info (device loop2): leaf 11042996224 gen 887769 total ptrs 96 free space 3747 owner 6093 Zeile 3669: Sep 2 17:02:02 Raidy kernel: BTRFS error (device loop2): block=11042996224 write time tree block corruption detected Zeile 3670: Sep 2 17:02:02 Raidy kernel: BTRFS: error (device loop2) in btrfs_commit_transaction:2537: errno=-5 IO failure (Error while writing out transaction) Zeile 3671: Sep 2 17:02:02 Raidy kernel: BTRFS info (device loop2 state E): forced readonly Zeile 3672: Sep 2 17:02:02 Raidy kernel: BTRFS warning (device loop2 state E): Skipping commit of aborted transaction. Zeile 3673: Sep 2 17:02:02 Raidy kernel: BTRFS error (device loop2 state EA): Transaction aborted (error -5) Zeile 3674: Sep 2 17:02:02 Raidy kernel: BTRFS: error (device loop2 state EA) in cleanup_transaction:2025: errno=-5 IO failure Edit: Ahhh, loop3 ist wohl das VM Filesystem, so dass loop2 wohl das Docker Image ist.....

Des Rätsels Lösung! War mir nicht klar, Danke! Mit TightVNC funktioniert es nun! JaJa, aller Anfang ist schwer! War das erste mal, dass ich mich mit VM's beschäftigt habe.....

Also irgendwie bin ich zu blöd... Ich habe eine VM mit Windows 10 aufgesetzt und habe/hatte Probleme mit Umlauten und Zeichen, welche die Taste "AltGr" erfordern. Beim ersten Test war folgendes eingestellt: Windows 10 VM Tastatur auf "no Mapping" eingestellt Windows in der VM hat deutsche Tastatur eingestellt Am Client ist auch Deutsche Tastatur eingestellt Mit dem Unraid eigenen VNC Client alles wunderbar also z, y, @ (AltGr) Umlaute Mit VNC Viewer: z & y vertauscht, AltGr+Q = 2, keine Umlaute Also die VM umgestellt auf Tastatur der VM-Konsole: German (de) Nun mit dem Unraid eigenen VNC Client: Alle Umlaute OK, aber alles was AltGr benötigt wie @€~ geht nicht Mit VNC Viewer selbiges Ergebnis Mit RealVNC selbiges Ergebnis Ich stehe auf dem Schlauch....weiss jemand die Lösung ? Kann doch nicht sein, dass man das wichtige "@" nicht übertragen kann.... was mache ich falsch Win10Config.xml

Nein, das geht nicht, siehe Solution

Hallo, da widersprechen aber meine Erfahrungen, also ich betreibe Nextcloud schon längere Zeit (2 Jahre) und seit mehreren Monaten bin ich umgestiegen auf Nextcloud AIO und kenne diese Probleme eigentlich nicht. Es ist aber so, dass ich dem Nextcloud Server auch nicht dazwischen grätsche, indem ich Dateien des Servers von außerhalb einfach ändere. Soll heißen, alles was in meinem Server Verzeichnis enthalten ist, ist tabu, da macht nur Nextcloud selbst rum. Ich meine man kann doch nicht erwarten, dass wenn man da Änderungen macht, dass dies ohne Auswirkungen bleibt, unabhängig davon, ob Nextcloud nun unter UNRAID oder sonst etwas läuft, die Verzeichnisse sind tabu. Das ist einfach der falsche Ansatz! Wenn ich zum Beispiel ein Verzeichnis für meine Fotos will, lege ich diese Fotos in einem, von Nextcloud unabhängigen Verzeichnis ab (separate Freigabe). Dieses Verzeichnis wird dann im Nextcloud Docker gemountet. Dieser Mount wird dann einem User in den Administrations Einstellungen dem entsprechenden User zugewiesen. Somit kann man dann über Nextcloud direkt oder über SMB oder direkt über Unraid seine Fotos hochschieben, ohne dass dies die Seiteneffekte hat mit Berechtigungen und so, da Nextcloud eben weiß, dass dieses Dateien von außerhalb geändert werden können. Also wenn es richtig konfiguriert ist dann gibt es auch keine Probleme mit Berechtigungen und so. Und Nextcloud AIO (bei mir laufen da 11-12 Container) auf dem aktuellen Stand zu behalten ist kinderleicht, ein Knopfdruck im AIO Interface, fertig. Fazit: Mache keine (heimlichen) Änderungen im Serververzeichnis und alles ist gut. Benutze dafür separate Verzeichnisse außerhalb der Nextcloud Installation.

Da bin ich ja ganz deiner Meinung, aber ursprünglich ging es um Nextcloud AIO. Ich wüsste jetzt nicht, wie ich auf den Nextcloud-AIO-Mastercontainer Einfluß nehmen könnte, damit er und auch die untergeordneten Container die Daten nicht im Docker Volume ablegen. Ich kann da lediglich das Dataverzeichnis festlegen.... Bei einer "normalen" Nextcloud Single Instanz" ist das ja über die Pfade machbar, aber bei Nextcloud AIO ????

Hallo, willkommen im Club, ich hatte vor einiger Zeit das selbe Problem, Lösung: Alle AIO Container stoppen und entfernen Das DATA_DIR von Nextcloud löschen Der wichtigste Schritt: Nextcloud AIO legt für die Container Konfigurationsdaten in /var/lib/docker/volumes an. In diesem Verzeichnis alles löschen was mit Nextcloud-AIO zu tun hat Evt. Docker neu starten Also auf der Unraid Konsole für jedes Verzeichnis: cd /var/lib/docker/volumes rm -r Nextcloud-AIO-...... Oder evt, der sichere Weg (Da kann man nicht irrtümlich einem laufenden Container das Volume löschen) Auflisten der Volumes mit docker volume ls Löschen der Volumes mit docker volume rm nextcloud-aio..... Viel Erfolg

Inzwischen bin ich soweit, dass es dafür keine Lösung gibt. Ich habe daher Nextcloud AIO nach der Standard Methode installiert. Zu beachten sind allerdings folgende Punkte, wenn in Docker der Host Zugriff auf Benutzer definierte Netzwerke deaktiviert ist: Ein DNS Server, der in einem Benutzer definiertem Netzwerk auf dem selben System läuft, ist nicht erreichbar von AIO aus Ein Proxy Manager, der in einem Benutzer definiertem Netzwerk auf dem selben System läuft, kann den AIO Container nicht erreichen Ob man es riskiert, den Hostzugriff zuzulassen, muss jeder für sich entscheiden, ich würde es aber nicht machen Da bei mir Nextcloud die einzige Anwendung ist, die Port 80/443 benötigt, verzichte ich auf einen Proxy Manager und der DNS Server wurde auf ein anderes System verlegt, so dass die Domain Namen für Nextcloud auch intern aufgelöst werden. In Nextcloud wurde ein Geoblocker installiert, der nur bestimmte Länder für die Anmeldung zulässt. Zusätzlich verhindert meine Firewall generell den Zugriff aus dem Ausland, da ich keinen Zugriff aus dem Ausland brauche. Ach ja, noch etwas, das mich einige Stunden gekostet hat: Hatte mal vor längerer Zeit mit AIO experimentiert, das aber total vergessen. Und die Konfigurationsverzeichnisse von damals waren noch im Docker volume, was mir nicht bewusst war. Das hat mir das Leben echt erschwert, bis ich geschnallt habe, dass für die komplette Neuinstallation diese Überreste zuvor gelöscht werden sollten..... Fazit: Nextcloud läuft nun in seinem eigenen Netzwerk, ohne Proxy und rennt wunderbar. Jürgen

Hallo, ich versuche gerade Nextcloud AIO in meiner DMZ zum laufen zu bringen, mit mäßigem Erfolg. Ich habe zwei Netzwerkkarten: ETH0 ist mein "Internes LAN", ETH1 ist die "DMZ" In Docker habe ich folgende Netzwerke: Den AIO Master habe ich mit folgenden Parametern installiert: Habe da auch schon alles mögliche probiert........ Aber der Master Container erstellt die anderen Container im falschen Netz: Der Master läuft in der DMZ (33.x) und die anderen Nextcloud Container im internen LAN (29.xx) Gibt es eine Möglichkeit das Bridge Netzwerk"nextcloud-aio" an die DMZ zu binden??? (Unraid 6.12.15)

Ja, beim nächsten mal mache ich es richtig! Mir war nicht bewusst, dass kill lediglich ein freundliches TERM an den Prozess sendet, in meinem Fall wäre kill -9 pid wohl erfolgreicher gewesen. Danke!

Ich hatte heute ein Problem mit Unraid: Alle Docker, wie zum beispiel Nextcloud, DNS Server schienen so, als ob sie tot wären Unraid war über die Web GUI erreichbar, Login möglich Ich habe dann gesehen, dass alle Docker im Status "gestartet" waren Ein Blick auf die Auslastung zeigte aber, dass 3 von 4 CPU Kernen auf 100% Last waren Bei durchschauen der Prozesse fiel mir auf, dass BorgBackup, welches heute morgen über Userscript's gestartet wurde, Amok lief Ich habe dann in Userscripts den Background Job abgebrochen, was jedoch die BorgBackup Prozesse nicht interessierte Dann der Versuch die Prozesse von BorgBackup per pKill abzuschießen, was auch nicht von Erfolg gekrönt war Auslastung war immer noch so hoch.... Den Docker Service konnte ich normal beenden Array konnte nicht gestoppt werden Ein Neustart/Herunterfahren über die Web GUI wurde ignoriert Ein shutdown/ halt etc. über die Konsole blieben auch wirkungslos Letztendlich musste ich einen harten Reset am Server das Theater beenden Jetzt die Frage an die Linux Spezialisten unter euch: Wenn so ein Zustand mal wieder auftreten sollte, wie kann ich Unraid zum herunterfahren bringen, ohne harte massnahmen? Die Ursache war vermutlich: Habe gestern mit BorgBackup einige Versuche angestellt und so wie es aussieht gab es da ein Problem, dass BorgBackup wohl im Hintergrund irgendwie weiter lief. Als dann heute morgen das eigentliche tägliche Backup anlief, gab es wohl irgendeinen Konflikt unter den Prozessen. Dies führte dann vermutlich zu dem heutigen Problem. Und wie bereits gesagt, ist es mir nicht gelungen, die Prozesse irgendwie zu beenden. Ja, bei Linux habe ich noch Lernbedarf....

Danke! Ich werde mir das mal anschauen!