Da Do Ron

Das sind meine aktiven Docker. Deiner ist übrigens auch dabei und dient als Datenbank für meine PHP-Sites.

Ich habe dann doch noch eine Frage. Wenn die Docker nun auf Cache liegen - macht dann der Mover etwas damit? Oder könnte ich die Dockersachen unter /mnt/user/appdata/... löschen? Also nur die spezifischen Dockersachen, die ich vorhin geändert habe. Einige Sachen von einigen Dockern liegen bewusst auf /mnt/user/appdata. Obwohl die ausgewählten Sachen dort eigentlich auch raus können und auf einer Array-Freigabe gepackt werden können. Ich habe das aber erst beim Schreiben gemerkt, dass eigentlich /mnt/user/appdata kompett raus kann.

Wahrscheinlich mein eigener. Schätze ich mal. Ich habe vor paar Wochen ein Image erstellt und von Euch freigeben lassen. Ubuntu-XFCE-novnc.

Das wusste ich auch noch nicht. Allerdings muss erst schauen, wo ich das deaktiviere. Immer wenn die herausnehme, ist die beim nächsten Öffnen wieder drin.

Ein dritter Cache wäre wohl etwas übertrieben, aber in diesem Fall meine erste Überlegung. Nun, ich setze tägliche rsync-Backups zu einem ext. Backup-Server. Das User Script in Unraid ist da bestens geeignet. Wie sich die Umstellung, bei einem Ausfall des Caches, bemerkbar macht, werde ich auf alle Fälle noch testen. Wozu hat man einen Test-Server 🙂 . Ich werde alle Tipps berücksichtigen und in meinen Überlegungen einbeziehen. So sieht das bei mir aus. 50GB Free Min Space hatte ich irgendwann schon einmal eingestellt. du -hs /mnt/cache/* 45G /mnt/cache/appdata 1.6G /mnt/cache/data 68G /mnt/cache/docker 1.8G /mnt/cache/isos 5.1G /mnt/cache/lancache 1.3G /mnt/cache/nextclouddata-new 0 /mnt/cache/nextcloudwebdata 0 /mnt/cache/save 69G /mnt/cache/system

Bin nun fertig. Was soll ich sagen. Ich habe doch schon etwas Tränen in den Augen 🙂 . Hätte ich nie und nimmer gedacht, dass man mit so einer geringfügigen Änderung, spürbare Erfolge erzielen kann. Nextcloud RENNT. Und das spürbar. Wordpress übrigens auch. Bei Grafana, Emby, Pihole, phpipam und Calibre-Web habe ich ebenfalls das Gefühl, dass die etwas schneller aufbauen. Das Wichtigste für mich ist und war Nextcloud. Somit könnte ich mich nun von meiner VM verabschieden. Da die Nacht aber erst anfängt, stelle ich noch paar Tests gegenüber. Aber ich bin eigentlich jetzt schon mehr als zufrieden. Bleibt noch das Problem, weshalb ich diesen Thread eröffnete. Aber das scheint mich, jedenfalls für den internen Unraid-Betrieb, wohl gerade nicht mehr zu interessieren, da ich durch Zufall und Deiner Hilfe eine andere Lösung gefunden habe. Da das Problem aber auch auftritt, wenn man von externen Geräten auf NFS zugreift, bleibe ich da trotzdem dran.

Davon habe ich schon mal gehört, bin aber nie darauf eingegangen. Ich habe nun die beiden vorher angelegten docker.img rüber kopiert ins /mnt/cache/docker-Verzeichnis. Somit waren alle Docker sofort wieder da. Ich stelle eben die letzte Docker auf /mnt/cache/appdata/... um. Was mir jetzt schon auffällt, dass der Zugriff bei bestimmten Docker mit verfügbarem Web-Interface, etwas schneller geht. Oder ist das jetzt die obligatorische Einbildung, dass es einfach schneller laufen muss? Was aber keine Einbildung ist, dass die Prozessorlast im Ruhemodus, also wenn die Docker zwar gestartet sind, aber grad nichts zu tun haben, 4 Prozent herunter ging.

Habe ich schon gemacht. Alles auf Cache liegend.

/mnt/cache/docker funktioniert nicht. Das wäre dann bestimmt /mnt/cache/docker/docker.img

Das ist ja mal 'ne Info. Vielen Dank dafür. Davon ausgehend, dass das stimmt, werde ich natürlich umstellen. Auf die Tatsache, wie Du es beschreibst, wäre ich nicht gekommen. 33 aktive Docker müssen nun angepasst werden 🙂 . Danke nochmals.

Ich habe derweil die Übertragungsgeschwindigkeiten der beiden Sachen getestet. Also einmal die NFS-Verbindung und einmal die direkte Verbindung der VM zur Freigabe. Es hat sich dementsprechend noch nichts geändert, von damals zu heute. Ich verwendete für den Test 2 VM's, mit der selben Datei für den rsync-Befehl. Die Ergebnisse sprechen für sich. Direkte Freigabe (Bullseye-VM1): fstab-Eintrag: test /mnt/sharedfolders 9p trans=virtio,version=9p2000.L,_netdev,rw 0 0 Erreichte Werte: root@nc-vm:~# rsync --info=progress2 /media/testfile /mnt/sharedfolders 1,172,273,839 100% 8.82MB/s 0:02:06 (xfr#1, to-chk=0/1) NFS-Freigabe (Bullseye-VM2): fstab-Eintrag: 192.168.1.58:/mnt/user/data/vmdata /mnt/sharedfolders nfs defaults 0 0 Erreichte Werte: root@debian-nc-wp:/media# rsync --info=progress2 /media/testfile /mnt/sharedfolders 1,172,273,839 100% 239.79MB/s 0:00:05 (xfr#1, to-chk=0/1) Also führt kein Weg an NFS vorbei. Jedenfalls nicht, wenn ich es weiterhin so umsetzen möchte. Ich gehe aber davon aus, dass mein Problem in Version 10, bis zum richtigen Release, noch verschwindet. Was die Ursache ist, kann ich nicht bestimmend sagen. Python-Probleme oder Probleme mit dem Anlegen der Benutzer-Schreibrechte von Nextcloud auf die NFS-Freigabe für den Datenordner selbst, ich weiß es nicht. Eines ist sicher. Auf Unraid9.6 funktioniert es noch. Auch nach einem Downgrade zurück zur Version 9.6. funktioniert es wieder, ohne weitere Änderungen gemacht zu haben. Am Ende noch eine Sache. Kann mir jemand die Frage beantworten, ob der fstab-Eintrag meiner Direkt-Freigabe richtig ist? Oder lege ich mir da selbst Fallstricke, weil vielleicht die eingetragenen Werte nicht passend sind? Es geht um diesen fstab-Eintrag für das Mounten der Freigabe, wenn diese in der VM direkt als Unraid-Verzeichnis verwendet wird: test /mnt/sharedfolders 9p trans=virtio,version=9p2000.L,_netdev,rw 0 0 LG Da Do Ron

Ich merke grad', ich habe etwas an Deiner Frage vorbei geantwortet. Sorry. Also der erste Teil der Antwort passt zu Deiner Frage. Der Rest bezieht sich auf die direkte Freigabe. Vielleicht könntest Du etwas dazu sagen?

Danke @mgutt für die Antwort. Ich glaube, dass macht bei mir keinen Unterschied, ob ich cache oder user verwende. Ich habe für Docker und VM's, jeweils eine 1TB-SSD als Cache-only zugewiesen. Seit dieser Möglichkeit, mehrere Caches zu verwenden, habe ich das auch genutzt. Sag' mir bitte, wenn ich da falsch liege. Vielleicht passt mein mein Einhängebefehl nicht so richtig? Ich habe meine Unterlagen ausgekramt und hatte damals diesen Befehl, in meiner VM, in der fstab verwendet: vmdata /mnt/sharedfolders 9p trans=virtio,version=9p2000.L,_netdev,rw 0 0 Danach habe ich erst mit SMB etwas getestet und entschied mich am Ende für NFS, was auch bis heute bei fast allen externen Rechnern und internen VM's präsent ist, außer auf zwei Windows-Rechner, die SMB als Zugriff zu den jeweiligen Freigaben verwenden. Falls es nur am Befehl des Mountpointes liegt, lass' es mich wissen.

Ich kam dann doch schon heute dazu. Das Ergebnis meiner Tests ist ernüchternd. Was habe ich alles probiert? - Das NFS-Freigabeverzeichnis als Hauptordner angelegt - Man weiß ja nie - Sämtliche Einstellungen der Unraid-NFS-Freigabe durchprobiert - Einen weiteren Unraid-Server mit einer Testversion aufgesetzt - eine weitere VM mit Buster verwendet - eine weitere VM mit Focal Fossa (Ubuntu LTS) verwendet Ein externer Test steht noch aus. Ich werde noch einen Raspi mit Nextcloud aufsetzen und testen. Nach jeder Änderung die Docker gestoppt, gelöscht und die angelegten Verzeichnisse per Hand gelöscht und neu angelegt. In allen Fällen das gleiche Ergebnis, inkl. dieser geposteten Fehlermeldung. Übrigens - Wordpress zeigte dieses Verhalten nicht. Da funktionierte alles. Abhilfe schaffte am Ende dann doch nur die Verwendung von Unraid 9.6.2. Was mir jetzt grad eben noch einfällt, dass ich vielleicht eine Unraid-Freigabe direkt in der VM-Erstellung verwenden könnte. Dort sollte es definitiv funktionieren. Darauf verzichtete ich allerdings gern, weil die Geschwindigkeit zur Freigabe sehr bescheiden war. Ich kann mich noch leicht daran erinnern, dass ich einen Grund hatte, NFS zu verwenden. Ich werde diesen Versuch auch noch starten und die Geschwindigkeit testen. Vielleicht hat sich ja diesbezüglich bei den virtio-Treibern etwas getan. Das Hauptsystem bleibt vorerst auf 9.6.2 bestehen. Ich werde das Ganze aber im Auge behalten, wenn die 10'er Version ihren vollständigen Release erhält. Mit diesem Fehler, egal wo der nun herkommen mag, möchte ich mich auf dem Produktivsystem nicht herumärgern. Bleibt noch die Frage, warum ich mir das Ganze mit einer VM und Docker-Compose antue 🙂 . Nun, die Geschwindigkeit des Zugriffes auf Nextcloud in Verbindung mit eigenem NginX-Webserver und Nextcloud:FPM ist einfach schneller, als es bei der normalen Docker-Version unter Unraid der Fall ist. Obwohl ich dort auch schon einen Redis-Cache als Docker hinzufügte und in Nextcloud eingebunden habe. Nextcloud hat es mir angetan. Ich teste immer wieder verschiedene Konstellationen auf verschiedenen Servern. Auch der Raspi bleibt da nicht verschont davon. Dabei ist es egal, ob nun nextcloud oder linuxserver/nextcloud oder MariaDb oder PostgreSQL. Ich nehme da alles mit. Einer Sache bin ich mir aber treu geblieben. Ich verwende auschließlich Docker. Ob nun einzeln oder als Docker-Compose-Script... Das war's dann erst einmal zum Thema. Falls noch jemand eine Idee hat, nehme ich mich der Sache gern an. LG Da Do Ron

Zur Info: Ich bin wieder etwas weiter gekommen, nur bisher ohne Erfolg 🙂 . NFS-Freigabe funktioniert. SMB-Freigabe funktioniert auch. Nur leider nicht, wenn man Nextcloud installiert und eine NFS-Freigabe als NC-Datenverzeichnis angibt. Ich beziehe mich hierbei auf die NFS-Freigabe zu einer Freigabe im Array und Nextcloud in einer Debian-Bullseye-Server-VM, welche unter Unraid installiert ist. Der handelsübliche Nextcloud-Docker unter Unraid funktioniert. Folgenden Fehler bekomme ich, wenn ich die erstellte Docker-Compose in der VM starte. Dabei ist die Fehlermeldung nur präsent, wenn ich als Datenverzeichnis die NFS-Freigabe zu und auf Unraid 10 wähle. Zuerst dachte ich, das liegt an meiner VM. Aber auf Unraid 9.6, mit der selben VM, funktioniert das Ganze. root@debian-nc-wp:/home/dockervolumes/nextcloud# docker-compose up -d Starting nextcloud_redis_1 ... done Starting nextcloud_db_1 ... done nextcloud_adminer_1 is up-to-date Recreating nextcloud_app_1 ... ERROR: for nextcloud_app_1 a bytes-like object is required, not 'str' ERROR: for app a bytes-like object is required, not 'str' Traceback (most recent call last): File "/usr/lib/python3/dist-packages/docker/api/client.py", line 261, in _raise_for_status response.raise_for_status() File "/usr/lib/python3/dist-packages/requests/models.py", line 943, in raise_for_status raise HTTPError(http_error_msg, response=self) requests.exceptions.HTTPError: 500 Server Error: Internal Server Error for url: http+docker://localhost/v1.22/containers/6218d8840728663a214e217dfa477c31ebe689f54376bdd6efdc43eca525c1f6/start During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/compose/service.py", line 625, in start_container container.start() File "/usr/lib/python3/dist-packages/compose/container.py", line 241, in start return self.client.start(self.id, **options) File "/usr/lib/python3/dist-packages/docker/utils/decorators.py", line 19, in wrapped return f(self, resource_id, *args, **kwargs) File "/usr/lib/python3/dist-packages/docker/api/container.py", line 1095, in start self._raise_for_status(res) File "/usr/lib/python3/dist-packages/docker/api/client.py", line 263, in _raise_for_status raise create_api_error_from_http_exception(e) File "/usr/lib/python3/dist-packages/docker/errors.py", line 31, in create_api_error_from_http_exception raise cls(e, response=response, explanation=explanation) docker.errors.APIError: 500 Server Error: Internal Server Error ("b"error while creating mount source path '/mnt/sharedfolders/NC/NC-Data': chown /mnt/sharedfolders/NC/NC-Data: operation not permitted"") During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/bin/docker-compose", line 11, in <module> load_entry_point('docker-compose==1.25.0', 'console_scripts', 'docker-compose')() File "/usr/lib/python3/dist-packages/compose/cli/main.py", line 72, in main command() File "/usr/lib/python3/dist-packages/compose/cli/main.py", line 128, in perform_command handler(command, command_options) File "/usr/lib/python3/dist-packages/compose/cli/main.py", line 1107, in up to_attach = up(False) File "/usr/lib/python3/dist-packages/compose/cli/main.py", line 1088, in up return self.project.up( File "/usr/lib/python3/dist-packages/compose/project.py", line 565, in up results, errors = parallel.parallel_execute( File "/usr/lib/python3/dist-packages/compose/parallel.py", line 112, in parallel_execute raise error_to_reraise File "/usr/lib/python3/dist-packages/compose/parallel.py", line 210, in producer result = func(obj) File "/usr/lib/python3/dist-packages/compose/project.py", line 548, in do return service.execute_convergence_plan( File "/usr/lib/python3/dist-packages/compose/service.py", line 561, in execute_convergence_plan return self._execute_convergence_recreate( File "/usr/lib/python3/dist-packages/compose/service.py", line 486, in _execute_convergence_recreate containers, errors = parallel_execute( File "/usr/lib/python3/dist-packages/compose/parallel.py", line 112, in parallel_execute raise error_to_reraise File "/usr/lib/python3/dist-packages/compose/parallel.py", line 210, in producer result = func(obj) File "/usr/lib/python3/dist-packages/compose/service.py", line 481, in recreate return self.recreate_container( File "/usr/lib/python3/dist-packages/compose/service.py", line 602, in recreate_container self.start_container(new_container) File "/usr/lib/python3/dist-packages/compose/service.py", line 627, in start_container if "driver failed programming external connectivity" in ex.explanation: TypeError: a bytes-like object is required, not 'str' Starte ich den up-d Befehl anschließend noch einmal, werden alle Docker in der Compose-Datei installiert und die Fehlermeldung erscheint nicht noch einmal. Aber dann kann Nextcloud nicht ins Datenverzeichnis schreiben und lässt sich nicht installieren. Noch schlimmer wird es, wenn ich einen eigenen Webserver für Nextcloud:fpm in der Compose-Datei mit verwende. Dann erscheint der Klassiker - Bad Gateway. Wohlbemerkt - das tritt nur unter Unraid 10 auf. Auf dem Unraid 9.6, welcher das identische Hard- und Software-Setup hat (außer die beiden Unraid-Versionen), passt alles, wie es sein sollte. Ich werde am Samstag weiter schauen, ob ich neue Erkenntnisse bekomme. Nachtrag-1: Verwende ich als Nextcloud-Datenverzeichnis einen lokalen Ordner, direkt in der VM , funktioniert alles, wie es sein sollte. Nachtrag-2: Verwende ich diese identische Docker-Compose direkt unter Unraid, funktioniert das auch. Aber das wollte ich eigentlich nicht realisieren, da es offiziell nicht unterstützt wird. Ich verwende lieber dieses Szenario in einer VM.

Ich bin dann doch schon etwas weiter gekommen. Die Unraid-NFS-Freigabe funktioniert mit "Öffentlich". Mit anderen Servern, auch mit der besagten VM kann ich per NFS darauf zugreifen. Nur die Nextcloud-Datenfreigabe funktioniert nicht mehr. Diese ist gesperrt. Ich kann mich schwach daran erinnern, dass ich das schon einmal, vor paar Jahren hatte. Ich muss mal meine Aufzeichnungen heraussuchen. Vielleicht finde ich was dazu.

@blinddark. Ich habe die Regeln noch einmal überprüft. Es ist soweit egal, was ich einstelle. Auf 6.10RC2 bekomme ich derzeit keine NFS-Verbindung zum Array hin. Aus momentanen Zeitmangel werde ich mich am kommenden Wochenende damit befassen. Wenn noch jemand einen Tipp hat, werde ich das gern berücksichtigen. Falls ich das beheben kann, werde ich natürlich berichten. LG Da Do Ron

Danke für die schnelle Antwort. Ich habe, für den internen Betrieb, die Einstellungen auf Exportieren: "Ja" und Sicherheit: "Öffentlich". Musste damals schnell eingerichtet werden und ist nur für den internen Gebrauch. Falls das nur noch auf "Privat" funktioniert, muss ich dann noch irgendwelche Benutzer/Passwortabfragen in der fstab der VM oder Raspi eintragen oder funktioniert das dann immer noch wie bisher? Meine bisheriger fstab-Eintrag für die NFS-Freigabe ist: 192.168.1.159:/mnt/user/data/vmdata /mnt/sharedfolders nfs defaults 0 0 Bin grad nicht am Rechner zum Testen, habe aber die Einträge im Kopf 🙂 LG Da Do Ron

Hi. Hat noch jemand auf 6.10 das Problem, dass die erstellten NFS-Freigaben von 6.9 nicht funktionieren? Ich kann nämlich nach einem Upgrade zu 6.10-RC2, von einer Buster-Server-VM, die auch auf dem selben Unraid-Server liegt, welche über NFS Zugriff auf einer Freigabe zum Array hat, nicht mehr an die benötigten Daten ran, weil die Verbindung nicht hergestellt werden kann. Auch ein Neustart der VM brachte keinen Erfolg. Nach anschließendem Downgrade auf 6.9.2 funktionierte es wieder. Zur Info: Alles soweit kein Problem für mich, da es ein Testserver ist. Ich möchte mich nur im Vorfeld mit den neuen Funktionen vertraut machen. Habe ich etwas übersehen? Gibt es neue Protokolle oder ähnliches, die eine vorher erstellte Verbindung nicht ermöglichen? Oder ist das einfach nur ein Bug, der noch behoben wird? LG Da Do Ron

Genau. Das wars. So ein ähnliches Problem hatte ich schon einmal vor geraumer Zeit mit MariaDB. Danke für den Hinweis. Folgende Version funktioniert: telegraf:1.17 Grafana bekommt nun seine Daten wieder. Vielen Dank.

Ich meine den Docker Telegraf - nicht Telegram 🙂 Das Problem mit Telegram ist mir aber auch bekannt.

Hi. Mir ist bewusst, dass mein Problem nicht bei Unraid liegt. Ich möchte keinesfalls die Forenregeln brechen. Falls dieser Post unangebracht ist, bitte löschen. Vielleicht kann mir jemand bei folgendem Docker-Problem helfen oder vielleicht hatte jemand das Problem auch und fand eine Lösung. Es betrifft den Docker Telegraf, welcher unter Apps zu finden ist. Bisher installierte ich meine zusätzlich benötigten Sachen direkt im Docker, als "Post Argument" unter "Erweiterter Ansicht). /bin/sh -c 'apt update && apt install -y smartmontools && apt install -y lm-sensors && apt install -y nvme-cli && apt install -y ipmitool && telegraf' Das funktioniert nun nicht mehr. Im Zeitraum der letzten Woche muss wohl ein Update des telegraf-Dockers erschienen sein. Vorige Woche funktionierte das noch. Mein Server läuft seit Jahren stabil 24/7 und wurde mit dem letzten Final-Unraid-Patch das letzte Mal neu gestartet. Der Docker startet nicht mehr und es erscheint nun im Protokoll die Fehlermeldung: "List directory /var/lib/apt/lists/partial is missing. - Acquire (13: Permission denied)" Wie kann ich als root diese Sachen weiterhin, als "Post Argument" installieren? Es scheint, dass der Docker jetzt intern auf Benutzerebene läuft, bin mir aber nicht sicher. Zuerst dachte ich, das Einfachste ist es, das Verzeichnis anzulegen. Aber auch ein zusätzlicher Eintrag im "Post Argument" mit mkdir -p /var/lib/apt/lists/partial gibt "Permission denied" aus. Andere Docker zeigen dieses Verhalten nicht. Deshalb bin ich mir sicher, dass es kein Unraid-Problem ist. System: Unraid 6.9.2 - Docker - telegraf:latest

Hi. Das ist auch der Grund, warum in Unraid immer noch die Version 21.x, wenn man linuxserver/nextcloud verwendet und schon längere Zeit betreibt, präsent ist. Es kommt einfach kein Update auf 22. Bei einer Neuinstallation ist allerdings Version 22 vorhanden. Aber nur, wenn man auch eine neue MariaDB verwendet. Ich war da auch etwas irritiert, da ich normalerweise alle Datenbanken seit Jahren in einer MariaDB betreibe. Das habe ich nun speziell für Nextcloud geändert. Ab jetzt betreibe ich die Nextcloud-DB in einer extra dafür angelegten MariaDB. Da ich fast wöchentlich auf diversen Testmaschinen Versuche fahre, stolperte ich darüber. Wenn man z.B. Nextcloud und MariaDB in einer VM betreibt und jeweils die aktuellen Versionen verwendet, hilft folgender Befehl im Compose-Script, im MariaDB-Eintrag: command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW LG Da Do Ron

Hi. Backups, die mit DB-Backup erstellt wurden, lassen sich auch in der Konsole wiederherstellen. Die 2MB Limitierung in PHPMyAdmin ist normal und seit Jahren bekannt. Um das Backup als Restore zurückzuspielen, einfach im neuem MariaDB-Docker eine leere Datenbank, mit dem identischen Namen der gesicherten DB anlegen. Dann die Konsole des MariaDB-Dockers öffnen und folgenden Befehl (natürlich mit den eigenen Werten ersetzt) abschicken (Die Backupdatei muss im Verzeichnis liegen, von welchem der Befehl ausgeführt wird.): cat BACKUPFILE.sql | docker exec -i mariadb /usr/bin/mysql -u root --password=PASSWORT DATENBANKNAME Hierbei spielt dann die Dateigröße keine Rolle. -------------------- Ein weiteres Beispiel, um alle angelegten Datenbanken mit einem Rutsch zu sichern, wäre folgender Befehl, z.B. in einer Scriptdatei reingelegt und täglich aufgerufen: sudo docker exec mariadb /usr/bin/mysqldump -u root --password=12345698 --all-databases > /mnt/user/backups/db-all/`date +%Y-%m-%d-%H+%M+%S`-alldatabases.sql Das Restore dafür wäre dann: cat /BACKUPPFAD/2020-10-12-05+30+01-alldatabases.sql | docker exec -i mariadb /usr/bin/mysql -u root --password=PASSWORT Ich glaube sogar, dass man bei dieser Methode nicht erst leere Datenbanken mit den jeweiligen Namen anlegen muss. Bin mir allerdings grad nicht 100% sicher. Ist zu lange her. LG Da Do Ron

It's been a while, but phpipam works on Unraid. I have written a guide for it. It's in German, but I think you can take the most important things from it. https://knilixun.wordpress.com/phpipam/ Best regards