sonic6

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?

I am on 9.10.RC1. I am not using spindown on my Array, but i have a UAD which is connected through SATA for a monthly backup. This UAD is unmounted and will only be mounted and unmounted by the backup script. Also this "unmounted" UAD will be spinning up for no reasons.

Vielleicht sollte man DIES (https://forums.unraid.net/topic/101283-what-is-the-difference-between-virtio-and-virtio-net/?do=findComment&comment=1021453) aber auch nicht unerwähnt lassen... hatte lange deswegen crashes.

I am running a BTRFS RAID1 Cache Pool and an XFS single Cache. What is the recommended way for this usecase? Just use the Trim Plugin once a week? Will it be conflicted with the BTRFS Cache? (running Unraid 6.9.2)

I think this depends to the guide from spaceinvader and the rewrite from the nextcloud IP to the WAN URL inside the nextcloud conf.

@bat2o if it works externally and you try to access your nextcloud from the same LAN with your DuckDNS URL then maybe DNS-Rebind Protection / DNS Hairpinning (nat loopback) on your router/firewall can help you.

Noch eine kleine Ergänzung zur CyberPower USV: Wenn man möchte, dass bei beim Netzausfall der Server runterfährt und bei Netzwiederkehr hochfährt muss man folgendes machen: -Statt dem UPS Dienst (welcher in Unraid schon installiert ist), muss man das NUT Plugin nutzen und "Turn off UPS after shutdown:" auf "Yes" setzten. -Im Bios den Server so konfigurieren, dass bei Netzspannung immer "Power on" ist. Warum NUT satt UPS? -Wenn man "Turn off UPS after shutdown:" vom UPS Dienst nutzt fährt die USV erst 60 Minuten runter, nachdem der Server runterfahren wurde. Wenn innerhalb der 60 Minuten das Netzt aber zurück kommt, bleiben alle Ausgänge weiterhin unter Spannung und der Server bleibt immer aus. Die BIOS Funktion "Power on" bei "Netzspannung" funktioniert nur bei einer Flanke von 0 auf 1.

After updating to 1.17.0-ls71 SWAG doen't start: nginx: [emerg] "proxy_redirect" directive is duplicate in /config/nginx/proxy-confs/debianbullseye.subdomain.conf:36 nginx: [emerg] "proxy_redirect" directive is duplicate in /config/nginx/proxy-confs/debianbuster.subdomain.conf:36 nginx: [emerg] "proxy_redirect" directive is duplicate in /config/nginx/proxy-confs/ferdi-client.subdomain.conf:36 nginx: [emerg] "proxy_redirect" directive is duplicate in /config/nginx/proxy-confs/onlyoffice.subdomain.conf:22 i have to commenting out "proxy_redirect" in my all *.subdomain.conf to get SWAG work.

Falls man Cloudlfare für deine Domains nutzt, kann hier vielleicht @hotios cloudflareddns container helfen? Der kann zusätzlich zum A Record auch den AAAA Record per API anpassen.