sonic6

So, habe nun endlich mal Zeit gefunden. Habe dein Pakete installiert und getestet. -Alle Array Platten Spinup (ist bei mir default) -UAD Platte (sdh) in den Spindown geschickt Dann habe ich mehrere male das WEbUI von Nextcloud aufgerufen und verschiedene Bereiche besucht. Kein Problem, Platte (UAD sdh) blieb im Spindown. Habe zu guter letzt den NC Windows Client bei mir am PC gestartet und aufeinmal ging die UAD in den Spinup. Zum testen nochmal den NC Win Client geschlossen, UAD in den Spindown... danach NC Win Client gestartet und ne Sekunde, nachdem dieser sich verbunden hat ist die UAD angedreht. [...] COMMAND /usr/sbin/hdparm -C /dev/sdh (22124) COMMAND /usr/sbin/hdparm -C /dev/sdh (22390) COMMAND /usr/sbin/hdparm -C /dev/sdh (22536) COMMAND /usr/bin/php /usr/local/sbin/smartctl_type dev1 -A (22699) COMMAND /usr/sbin/smartctl -A /dev/sdh (22701) COMMAND /usr/bin/php /usr/local/sbin/smartctl_type dev1 -A (22699) COMMAND /usr/sbin/smartctl -A /dev/sdh (22701) COMMAND /usr/bin/php /usr/local/sbin/smartctl_type dev1 -A (22699) COMMAND /usr/sbin/smartctl -A /dev/sdh (22701) [...] Klingt irgendwie kaum nachvollziehbar, oder?

Last time a saw this Error in my Syslog: Sep 4 19:11:10 Unraid-1 nginx: 2021/09/04 19:11:10 [error] 27998#27998: *4810699 open() "/usr/local/emhttp/plugins/dynamix.system.stats/images/sys.png" failed (2: No such file or directory) while sending to client, client: 192.168.0.6, server: , request: "GET /plugins/dynamix.system.stats/images/sys.png HTTP/1.1", host: "192.168.0.50", referrer: "http://192.168.0.50/Stats" This Error appears every time, i open the System Stats Tab. Diagnostic attached. unraid-1-diagnostics-20210904-1913.zip

Wenn sich jemand "nicht-Deutsches" verirrt.

Ich finde Option 2 mit "Anleitungen / Guides" sehr gelungen.

Moin, würde es vielleicht Sinn machen einen Sammelthread im Deutschen Bereich zu den erstellten Guides anzupinnen? Mittlerweile gibt es hier ja einiges und ich persönlich finde, dass gerade Guides auf Deutsch sehr dabei helfen, die Zusammenhänge und Abläufe unter Unraid zu zu verstehen. Besonders neuen Usern bietet man hier eine große Hilfestellung und auch Möglichkeiten Hilfe-zur-Selbsthilfe zu schaffen. Dem Ein oder Anderen der einfach nur mal im Forum stöbert, wird man hier vielleicht auf neue Idee für seinen Server bringen. Klar gibt es einen gesonderten Bereich für Guides, dieser ist aber primär auf Englisch. Das kann aber eine Hürde bei einigen Usern sein. Hier würde man diesen Leuten einen Anlaufpunkt geben, sich mehr mit Unraid auseinander zu setzten. Gleichzeitig fördert man das Erfolgserlebnis und senkt die Hemmschwelle neues zu probieren.

nochmal vorweg: Primär habe ich nur den Guide zusammen geschrieben und die Befehle zusammengetragen, um Variablen ergänzt und ausprobiert. Deswegen kann ich nur vermuten, warum die Befehle so sind, wie sie sind. Sollte ich quatsch erzählen, bitte ich dass die von Jemanden der es "weiß", korrigiert wird. Das habe ich so aus dem Script von Lukas Knöller übernommen. Laut diesem Artikel schien mir keine Anpassung von nöten. Ich denke es liegt daran, dass das dd if=/dev/mmcblk0 im Ziel ausgeführt wird, dann per pipe an dd of=${BACKUP_PFAD}/${BACKUP_NAME}-${DATUM}.img übergeben wird, welches lokal ausgeführt wird.

Hier ein kurzer Guide um über ein einfaches User Script von Unraid aus die Konfiguration eures Pihole zu sichern. Hierzu wird per SSH eine Verbindung zu Pihole aufgenommen, der Teleporter (Backup Erstellung) gestartet und das Backup per SCP auf den Unraid-Server übertragen. Danach wird das Übertragene Backup am Pihole und alte Backups auf dem Unraid-Server gelöscht. Da ich, abgesehen von meinem letzten Guide, recht unerfahren mit Unraid, Termina, Linux, SSH, Scripte, etc... bin, bitte ich Fehler zu entschuldigen. Für Ergänzungen/Verbesserungen bin offen und dankbar! ---- -Backup Share als Ziel einrichten. Falls mehrere Pi's gesichert werden sollen, empfehle ich für jeden Pi einen eigenen Unterordner im Share zu erstellen. -Unterordner im Share erstellen: Im Unraid Terminal folgenden Befehl ausführen mkdir -p /mnt/user/DEIN-BACKUP-SHARE/PIHOLE-BACKUP -sshpass downloaden, /extra/ Ordner auf dem Stick erstellen, sshpass in den Ordner /extra/ verschieben und sshpass installieren: Im Unraid Terminal folgenden Code ausführen. wget https://packages.slackonly.com/pub/packages/14.2-x86_64/network/sshpass/sshpass-1.06-x86_64-1_slonly.txz && mkdir /boot/extra && mv sshpass-1.06-x86_64-1_slonly.txz /boot/extra/ && installpkg /boot/extra/sshpass-1.06-x86_64-1_slonly.txz Dadruch dass wir das sshpass im /extra/ Ordner des Unraid Sticks liegen haben, wird sshpass mit jedem Unraid Start installiert. Wer das "Fix Common Problems" Plugin nutzt, wird nun eine Meldung bekommen, diese kann man mit dem Button rechts ignorieren: -User Script Plugin installieren: -User Script Plugin aufrufen und neue User Script erstellen: -Script ins leere Feld kopieren und Variablen anpassen: #!/bin/bash #Variablen PI_IP="XXX.XXX.XXX.XXX" SSH_USER="PI-USER" SSH_PW="DEIN-SUPER-PASSWORT-VOM-PI-USER" BACKUP_PFAD="/mnt/user/DEIN-BACKUP-SHARE/PIHOLE-BACKUP" #ohne / am Ende BACKUP_ANZAHL="30" #Backup erstellen sshpass -p ${SSH_PW} ssh ${SSH_USER}@${PI_IP} sudo "pihole -a teleporter" #Backup von Pi nach BACKUP_PFAD kopieren sshpass -p ${SSH_PW} scp -r ${SSH_USER}@${PI_IP}:pi-hole-*.tar.gz ${BACKUP_PFAD}/ #Backup am Pi löschen sshpass -p ${SSH_PW} ssh ${SSH_USER}@${PI_IP} rm -f pi-hole-*.tar.gz #Alte Backups löschen pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/pi-hole*.* | head -n -${BACKUP_ANZAHL} | xargs rm; popd sync -f ${BACKUP_PFAD} Im falle von Raspberry Pi OS sollte der User "Pi" sein. Das Passwort habt ihr bei der Installation von Raspberry Pi OS selbst festgelegt. Am Ende der Variablen BACKUP_PFAD darf kein "/" gesetzte sein, da dieses schon im Code enthalten ist. -Script mit dem "SAVE CHANGES" Button abspeichern. -Cron anpassen: In meinem Beispiel läuft das Script zur 0. Minute in der 23. Stunde an jedem Tag, jeden Monat, an egal welchem Wochentag. Oder kurz: jeden Tag um 23:00 Uhr. Hilfe zu Cron: https://crontab.guru/ -Einstellungen unten mit dem Button "APPLY" sichern. Vielen Dank schon einmal im Voraus an alle die das Script nutzen! *CHANGELOG*

*CHANGELOG* 25.08.2021 20:20 - Variable DATE hinzugefügt Musste schon die erste Sache anpassen. Wenn das Script über einen Tageswechsel läuft, würde das Shrinken nicht stattfinden.

An eine Möglichkeit das Passwort nicht im Klartext ins Script zu packen, hatte ich auch schon gedacht. Aber zum jetzigen Zeitpunkt sprachen zwei Gründe für mich dagegen: 1. Passwort als Klartext war sehr Einsteigerfreundlich und für diese Nachvollziehbar. Jemand der Fit in der Materie ist, wird das Script mit Leichtigkeit anpassen. 2. Es überstieg bisher einfach meine Fähigkeiten

@exico here is my workaround, try using this Repository: linuxserver/mariadb:110.4.21mariabionic-ls31

So,... i updated the container a few minutes ago... and now i got this: Some ideas, how i can solve this? *edit* my workaround in Post #1028110

Es ist ne SATA Platte

Hier ein kurzer Guide zu einem User Script um von einem Pi eine Sicherungsimage zu erstellen und zu verkleinern. Da ich selbst recht neu mit Unraid unterwegs bin und total unerfahren im Bereich Linux, Termina, Befehle, etc... bitte ich Fehler zu entschuldigen und gerne zu Verbessern und/oder brauchbares zu ergänzen. Als Basis habe ich das Script von Lukas Knöller - hobbyblogging.de genommen und um ein paar Variablen und PiShrink ergänzt. Das Script verbindet sich per SSH auf den Pi, erstellt ein Image davon und legt es im Backup Share ab. Danach werden überfällige Backups gelöscht und das erstellte Backup verkleinert. -Backup Share als Ziel einrichten. Falls mehrere Pi's gesichert werden sollen, empfehle ich für jeden Pi einen eigenen Unterordner im Share zu erstellen. -Unterordner im Share erstellen: Im Unraid Terminal folgenden Befehl ausführen mkdir -p /mnt/user/DEIN-BACKUP-SHARE/PI-UNTERORDNER -sshpass downloaden, /extra/ Ordner auf dem Stick erstellen, sshpass in den Ordner /extra/ verschieben und sshpass installieren: Im Unraid Terminal folgenden Code ausführen. wget https://packages.slackonly.com/pub/packages/14.2-x86_64/network/sshpass/sshpass-1.06-x86_64-1_slonly.txz && mkdir /boot/extra && mv sshpass-1.06-x86_64-1_slonly.txz /boot/extra/ && installpkg /boot/extra/sshpass-1.06-x86_64-1_slonly.txz Alternative, falls die Quelle nicht erreichbar ist: Dadruch dass wir das sshpass im /extra/ Ordner des Unraid Sticks liegen haben, wird sshpass mit jedem Unraid Start installiert. Wer das "Fix Common Problems" Plugin nutzt, wird nun eine Meldung bekommen, diese kann man mit dem Button rechts ignorieren: -PiShrink download, verschieben nach /mnt/user/appdata/, ausführbar machen: Im Unraid Terminal folgenden Code ausführen. wget -O /mnt/user/appdata/pishrink.sh https://raw.githubusercontent.com/Drewsif/PiShrink/master/pishrink.sh && chmod +x /mnt/user/appdata/pishrink.sh -User Script Plugin installieren: -User Script Plugin aufrufen und neue User Script erstellen: -Script ins leere Feld kopieren und Variablen anpassen: #!/bin/bash #Variablen PI_IP="XXX.XXX.XXX.XXX" SSH_USER="PI-USER" SSH_PW="DEIN-SUPER-PASSWORT-VOM-PI-USER" BACKUP_PFAD="/mnt/user/DEIN-BACKUP-SHARE/PI-UNTERORDNER" #ohne / am Ende BACKUP_ANZAHL="5" BACKUP_NAME="pi_image" SHRINK_SCRIPT_PFAD="/mnt/user/appdata/pishrink.sh" DATUM="$(date +%Y%m%d)" #Backup erstellen sshpass -p ${SSH_PW} ssh ${SSH_USER}@${PI_IP} sudo "dd if=/dev/mmcblk0" | dd of=${BACKUP_PFAD}/${BACKUP_NAME}-${DATUM}.img bs=1MB #Alte Sicherung löschen pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP_ANZAHL} | xargs rm; popd sync -f ${BACKUP_PFAD} #shrink ${SHRINK_SCRIPT_PFAD} ${BACKUP_PFAD}/${BACKUP_NAME}-${DATUM}.img Im falle von Raspberry Pi OS sollte der User "Pi" sein. Das Passwort habt ihr bei der Installation von Raspberry Pi OS selbst festgelegt. Am Ende der Variablen BACKUP_PFAD darf kein "/" gesetzte sein, da dieses schon im Code enthalten ist. Solltet Ihr "root" nutzen, oder das Script aufgrund von sporadischen erneutem Abfragen des Passwortes abbrechen, haben @dan4UR und @Anym001 vielleicht die Lösung für euch: root User Erneute Passwortabfrage bei sudo -Script mit dem "SAVE CHANGES" Button abspeichern. -Cron anpassen: in meinem Beispiel läuft das Script zur 15. Minute in der 23. Stunde am 11. und 26. Tages jeden Monat, an egal welchem Wochentag. Oder kurz: jeden 11. und 26. um 23:15Uhr. Hilfe zu Cron: https://crontab.guru/ -Einstellungen unten mit dem Button "APPLY" sichern. Wie Anfangs schon erwähnt, bin ich nicht sehr Erfahren und bitte um Rücksicht bei Fehlern. Danke auch an @ich777, @alturismo und @Anym001 für Idee, Ratschläge, Testen und Wissen. Ansonsten, Happy Backup! *CHANGELOG* 25.08.2021 20:20 - Variable DATE hinzugefügt 30.11.2021 09:35 - Troubleshooting Ergänzung für root und sudo 26.12.2021 14:22 - Alternative Quelle für sshpass. Danke @mgutt

War vielleicht blöd von mir formuliert, war aber nicht toxisch von mir gemeint. root@Unraid-1:~# hdparm -C /dev/sdh /dev/sdh: drive state is: standby

Mal probiert ob es einen Unterschied macht, erst alle "Heimnetz" IPv6 Settings zu deaktiveren und dann über die "Internet"-Einstellungen?

Wie gesagt, Platte ist weder gemappt, noch gemountet, noch sonst irgendwas. Die Platte wird nur per Script gemountet und innerhalb des Scripts beschrieben. Kannst du das näher ausführen? Wüsste nicht wonach ich bei den Spin-Down Settings suchen sollte, wenn ein "Spin-Up" das problem ist.

Das ist mir recht egal, da ich keinen Spin-Down nutze. Mir geht es lediglich um die ungemountete UAD, welche angedreht wird, aber im Spindown bleiben soll.

Kann ich nicht sagen, da meine Platten (abgesehen von der "nicht-gemounteten UAD), nicht in den Spin-Down geschickt werden. Ich gehe aber ganz stark davon aus, da meine NC auf dem Array liegt. *edit* habe es gerade mal getestet. Beim Zugriff auf nen "externen Speicher" werden alle Platten angedreht, außer die Parity. Aber warum ist eine UAD davon betroffen, die keinem Share zugeordnet oder gemounted ist?

Du hast IPv6 nur fürs WAN deaktiviert. Fürs LAN musst du hier schauen: *EDIT* ich habe den zweiten Pfeil zu weit gemalt, er sollte auf "IPv6 Einstellungen" verweisen.

Kann das ganze bestätigen. Ich habe eine UAD (per SATA angeschlossen), welche NUR für ein monatliches Backup per Script gemounted wird. Die Plätte ist keinem Share zugetreilt. Wenn ich die Platte in den Spin-Down schicke, wird diese mit dem Aufruf des Nextcloud WebGUI sofort geweckt.

Das habe ich noch in der Anleitung ergänzt. Wird "Prefer" (also bei "Überlauf aufs Array schreiben") überhaupt noch funktionieren, wenn ich in /mnt/cache/... schreibe? Dachte "Prefer" wird nur angewand, wenn in /mnt/user/... geschrieben wird.

Meine Holzhammer-Methode wäre, einfach wieder auf Docker Image umzustellen, dann rauszukopieren, wieder auf Docker Path zurück und ersetzten. So wie ich es oben beschrieben habe. Aber es gibt sicherlich eine elegantere Methode. Ich für meine Teil sichere mich die local-kv.db monatlich. Wie siehts hiermit aus? (nextcloud config.php) Oder configs aus SWAG für den RP? Ich hatte tatsächlich hier und dort mal mit IPs, statt Namensauflösung gearbeitet. (Was sich im nachhinein als nicht sehr schlau darstellte, da sich die IPs im Dockernetz ja anhand der Startreihenfolge ändern können.) Aber das war von meiner Seite aus genug Off-Topic und würde in nen eigenen Thread gehören.

Bei mir war es damals nicht so, da wurde das "Docker Image" als Pfad neu erstellt. Wenn ich mich recht erinnere musste ich auch die Container "neu laden". Ich erinnere mich nicht mehr 100%tig, war aber glaube ich in der 6.9.2 Beta?

Warum war das überhaupt weg? Hast du nicht eingestellt, dass Custom Network erhalten bleiben sollen (Docker Settings)? Das liegt daran, dass die Docker Network Setting im Docker Image unter /docker/container/network/files/local-kv.db liegen. Wenn man die "local-kv.db" vorher aus dem laufenden Docker Image sichert und später im Docker Path wieder herstellt, sind die Customnetworks wieder vorhanden. - Docker mit Docker Image starten - local-kv.db sichern - Docker auf Docker Path starten und warten, dass alle Container gestartet sind - Docker Dienst stoppen - local-kv.db mit dem Backup ersetzten - Docker Dienst starten - ... - sich darüber freuen, dass alles ist wie vorher *edit* Die Lösung einfach "wieder" das Proxynet zu erstellen ist nur Semi gut. Beim ersten mal wenn das Proxynet erstellt wird und man kein Subnet angibt, wird 172.17.0.0 erstellt. Wenn man nur einfach wieder eines erstellt, wird 172.18.0.0 erstellt, selbst wenn das Proxynet "verschwunden" ist. Und so weiter... das hat bei mir alles durcheinander geworfen, als ich auf Docker Path umgestellt habe, da ich überall, wo nicht mit der Namesauflösung gearbeitet wurde, die IPs anpassen musste. Nicht zu vergessen einige Zeilen in der config von NC. In Summe ist da schnell mal was vergessen. Das ganze habe ich umgangen, in dem ich mir einfach meine alten Netzwerksetting aus dem Docker Image gesichert habe.

Erstmal Danke, ich beobachte das Thema schon seit es im Reddit aufgetaucht ist. Gibt es auch eine Kehrseite der Medaille? Was ist mit nem Crash oder sonstigem unvorhersehbarem verhalten? Ist absehbar ob eine dauerhafte Lösung in Unraid implementiert wird?