hawihoney

Mach mal folgendes: # Finde alle Dateien die auf Disk1 am 02.03.2023 zwischen 03:58 und 04:02 geaendert wurden find /mnt/disk1/ -newermt "2023-03-02 03:58:00" ! -newermt "2023-03-02 04:02:00" oder # Finde alle Dateien auf die auf Disk1 am 02.03.2023 zwischen 03:58 und 04:02 zugegriffen wurde find /mnt/disk1/ -newerat "2023-03-02 03:58:00" ! -newerat "2023-03-02 04:02:00"

Ich glaube nicht an Zufälle in der IT. Sollte es tatsächlich der Nextcloud Container sein, dann kann es sich bei der von Dir oben aufgeführten Konstellation nur um a.) in Nextcloud zusätzliche integrierte Apps wie z.B. das Externe Speicher Plugin handeln oder b.) die von Nextcloud genutzte Datenbank wie z.B. MariaDB handeln. Wo liegt die?

Doch, gibt es. Wenn Du nur das /boot/config Verzeichnis sicherst, dann musst Du Dir im Katastrophenfall den Stick aus zwei Quellen zusammen kopieren und manuell vorbereiten. Ein Backup des Flash (zip) hingegen kann mit Hilfe des Flash Creators von Unraid als Ganzes auf einen Stick kopiert werden - inkl. Systemdateien und inkl. Erzeugung des Boot Sektors.

Das kann ich so nicht bestätigen. In meinem Supermicro SC846 Gehäuse mit Supermicro X12SCA-F Mainboard und Intel W1290-P Prozessor werkelt ein Noctua NH-U9S Kühler.

Von Linuxserver.IO?

Nur zur Info: @Squid hat einen Update veröffentlicht. Das Problem ist behoben. Ich dachte der Fehler wäre nur rclone bezogen. Es handelte sich aber um ein generelles Problem des User Scripts Plugin.

@Squid Output of commands within scripts is not shown with latest User Script plugin. Example: Command issued on command line: rclone sync --config /root/.config/rclone/rclone.conf /mnt/disk17/Backup/Tower/system/appdata/MKVToolNix/ remote:/Backup/Tower/system/appdata/MKVToolNix/ --stats-log-level NOTICE --stats 30m 2023/02/27 09:40:19 NOTICE: Transferred: 24.016 MiB / 24.016 MiB, 100%, 26.645 KiB/s, ETA 0s Transferred: 1624 / 1624, 100% Elapsed time: 16m31.0s Same command issued from within User Scripts: Script Starting Feb 27, 2023 10:25.21 Full logs for this script are available at /tmp/user.scripts/tmpScripts/Sync Backup/log.txt Script Finished Feb 27, 2023 10:28.12 Full logs for this script are available at /tmp/user.scripts/tmpScripts/Sync Backup/log.txt Thanks again for listening.

Ah, danke. Randbemerkung: Der ACE Editor ist sowas von Schrott. Ich arbeite überwiegend mit einem Android Tablet mit dem eingebauten Chrome im Desktop Modus aus der Ferne. Das hat wohl niemand jemals getestet. Da kannst Du nix vernünftig editieren. Gib mal einen Slash oder Backslash ein. Dann verschwinden irgendwo Worte. Oder so simple Sachen wie Copy, Cut, Paste. Das ist Horror. Aber was sage ich - das ist bei der Container Konsole ebenfalls so. Ich habe es noch nicht geschafft eine Zeile fehlerfrei einzugeben. Immer erscheinen Worte oder verschwinden Worte hinter oder vor meiner Eingabe. Am Laptop mit Windows und Chrome geht das. Die Entwickler scheinen alle reich zu sein und mit Apple Geräten rumzulaufen

Dann verstehe ich seinen Screenshot nicht. Das Array sieht weder gestartet noch gestoppt aus ... oder hat er hinten etwa alles schwarz gefärbt. Das wäre dann aber für jemanden der gerne helfen würde äußerst verwirrend.

Was steht denn beim Array Status? Degraded? Array sieht verschlüsselt aus. Korrekt?

Wenn ich mir die vielen immer wiederkehrenden Fehler zu BTRFS etwas genauer anschaue, dann meine ich zu erkennen, dass BTRFS als Single FS (egal ob im Array oder im Cache) eher unproblematisch ist. Die Probleme scheinen eher bei den verschiedenen RAID Leveln zu existieren. Wer einmal eine Platte aus einem BTRFS Verbund austauschen muss, der reibt sich doch verwundert die Augen. Bei jedem RAID System, das ich bisher in den Fingern hatte, ist das einfach nur Platte raus, Platte rein, rebalance fertig. Bei einem BTRFS Verbund kommt ein weiterer extrem belastender Schritt für die verbleibende Platte(n) hinzu. Platte raus, rebalance, Platte rein, rebalance. So war es jedenfalls bevor ich BTRFS abgeschworen habe. Wenn das immer noch so sein sollte ... Finger weg.

Auf meinem Rechner laufen dutzende User Skripte. Bei einigen dieser Skripte erscheinen die Ausgaben der enthaltenen Befehle im Log des jeweiligen Scripts - bei anderen nicht. Zum Beispiel rclone, heute entdeckt: Rufe ich zum Beispiel folgenden Befehl auf der Konsole auf, dann erscheint diese Ausgabe: rclone sync --config /root/.config/rclone/rclone.conf /mnt/disk17/Backup/Tower/system/appdata/MKVToolNix/ remote:/Backup/Tower/system/appdata/MKVToolNix/ --stats-log-level NOTICE --stats 30m 2023/02/27 09:40:19 NOTICE: Transferred: 24.016 MiB / 24.016 MiB, 100%, 26.645 KiB/s, ETA 0s Transferred: 1624 / 1624, 100% Elapsed time: 16m31.0s Starte ich den selben Befehl mit identischen Parametern als User Script, dann erhalte ich nur die Start und Ende Meldung. Zum Beispiel wie diese: Script Starting Feb 27, 2023 10:25.21 Full logs for this script are available at /tmp/user.scripts/tmpScripts/Sync Backup/log.txt Script Finished Feb 27, 2023 10:28.12 Full logs for this script are available at /tmp/user.scripts/tmpScripts/Sync Backup/log.txt Wie erklärt sich diese Differenz? Vielen Dank.

Exakt. Kann ich nicht bestätigen. Sobald ich die VM starte und zur Anzeige wechsle steht dort schon das blaue Unraid Menu. Der restliche Ablauf ist so schnell wie beim Host. Es wird ein (virtuelles) Device oder ein Ordner oder so bei Dir bremsen.

Was ist bei Dir gefühlt langsamer? Ich muss das jedenfalls zu 100% verneinen. Wenn man dem Host die Resourcenverteilung überlässt (keine CPU Isolation), der VM native Devices übergibt (HBA, Disk, Stick), direkt vom Stick bootet (ohne virtuelle Disk) dann ist die Performance nahezu identisch. Bei mir ist das jedenfalls so. Habe ich nicht verstanden. Unraid ist Software, kein Mensch. Software kann man nicht verwirren. Man kann nur mit falschen Angaben oder nicht eindeutigen Konfigurationen zu anderen Ergebnissen kommen als erwartet. Mit einer korrekten und eindeutigen VM Beschreibung bekommt man was man will. Also lieber einmal zu viel Bus:Device und nicht so viel rumspielen, dann klappt das zuverlässig.

Ach geh weg Hab ich gerade gemacht. In SWAG die zusätzliche Subdomain aufgenommen, den Code von oben in filebrowser.conf im Ordner nginx/site-confs gespeichert und SWAG neu gestartet. Danach kam bei Aufruf von filebrowser.<hust>.dyndns.org meine Nextcloud. Danach habe ich noch eine Location Rule auf 192.168.178.2:80 im Code hinzugefügt, SWAG neu gestartet und es kam 502 Bad Gateway. Ich werde diesen Kram nie verstehen. Datenbanken und Oberflächen Programmierung ist dagegen ein Kinderspiel

Ja, darauf spekuliere ich schon länger. Ich traue mich aber nicht umzustellen. Vielleicht komme ich in Kürze mal auf Dich zu ...

@Squid After latest update the User Scripts plugin is broken. If I click on buttons like "Run in background" nothing happens. Thanks for listening.

Vielen Dank für Eure Tipps. Ich fange mal mit dem Filebrowser an. Ich will das für meinen Kumpel schon mal üben. Und schwupps komme ich direkt an meine Grenzen. Netzwerk: 0 Points. Standard scheint "br0" zu sein. Bei mir läuft bisher alles unter "bridge". Der Container nimmt sich aber gleich eine eigentlich reservierte IP aus meinem Netzwerk. Stelle ich auf "bridge" oder "host" um läuft er nicht mehr intern. Also wieder zurück auf "br0". Was mache ich denn jetzt mit dem um das nach außen freizugeben? Ich würde das gerne über mein SWAG und HTTPS laufen lassen. Ich kann ja jetzt schlecht diesen HTTP Port nach außen freigeben. Nur zur Erklärung. Ich habe die SWAG Konfigurationen für z.B. Nextcloud und Plex 1:1 irgendwo rauskopiert. Ich verstehe nicht eine Zeile daraus. Kann dieser Container überhaupt https?

Ich frage für einen Freund - im Ernst. Der betreibt einen kleinen Unraid Server ohne großes Brimborium. Nur für sich, bisher nur intern. Nun würde er gerne nur einen einzelnen Ordner von seinem Array nach außen freigeben. Bei den Personen die darauf zugreifen würden reicht der Zugriff über einen Browser. Es soll keine App oder anderes erforderlich sein. Ich persönlich nutze unter anderem dafür Nextcloud. Das erscheint mir aber für diesen einzelnen, kleinen Einsatzweck zu fett. Eine Suche ist nicht erforderlich, Hochladen oder gemeinsames Arbeiten ist nicht erforderlich, es wird nichts von außen verändert. Wie in einem File Browser soll nur durch eine Ordnerstruktur navigiert und einzelne kleine Dateien heruntergeladen werden. Wie könnte man eine solch kleine Lösung halbwegs sicher und einfach hinbekommen? Hättet Ihr eine Idee? Vielen Dank.

Jau, danke. Wäre sicherlich cleverer gewesen. Hatte zwischenzeitlich alle Skripte erweitert. Sehen jetzt alle so aus. Damit kann ich leben: rclone sync --config /root/.config/rclone/rclone.conf /mnt/disk17/Dokumente/ remote:/Dokumente/ Bin aber prompt wieder in die GDrive Duplicate Falle getappt. Hatte GDrive vor ca. 10-15 Jahren schon mal ausprobiert und hatte damals wegen den permanenten Duplicates das ganze in die Tonne getreten. Heute, ca. 10-15 Jahre später, hatte ich das wieder. Zur Erläuterung: GDrive erlaubt zwei Dateien mit identischen Namen im selben Verzeichnis. GDrive erzeugt die aber selbst manchmal. Glücklicherweise hat rclone für GDrive eine eigene Service Funktion eingebaut: rclone dedupe remote:/Dokumente/

Nachtrag: Ich habe nun von rclone Docker Container auf rclone Package (via un-get von @ich777) umgestellt. Nach wie vor wird alles über User Scripts angeworfen: Folgende Nachteile sehe ich: - Das Plugin hat nun natürlich r/w Access auf die Source während ich beim Container den Source Path als r/slave angebunden hatte - Durch das Konstrukt mit der rclone.conf und dem standardmäßigen Ordner für diese conf unter Linux an dieser Stelle /root/.config/rclone/rclone.conf geht die Konfiguration nun jedesmal bei einem Reboot des Rechners fliegen. Ich habe das durch ein weiteres User Script gelöst, welches beim ersten Start des Arrays den benötigten Ordner erzeugt und eine auf dem Stick gesicherte rclone.conf kopiert. - Beim Aufruf von der Konsole klappt das, beim Aufruf durch das User Script nicht. Hier muss ich dann die Location der Conf im Befehl mit angeben. Da muss ich mir noch eine bessere Lösung ausdenken Vorteile: Ist halt schlanker.

Das ist nicht erforderlich. Ich habe drei identische USB-Sticks im Server. Identische Devices werden halt als Bus:Device durchgereicht: So geht z.B. Vendor:Product sowie Bus:Device mit einem USB-Stick: <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x0930'/> <product id='0x6544'/> <address bus='1' device='4'/> </source> <boot order='1'/> <alias name='hostdev1'/> <address type='usb' bus='0' port='1'/> </hostdev> So nur mit Bus:Device bei identischen Modellen: <hostdev mode='subsystem' type='usb' managed='no'> <source> <address bus='1' device='2'/> </source> <boot order='1'/> <alias name='hostdev0'/> <address type='usb' bus='0' port='1'/> </hostdev>

Alles klar. Ich dachte der Mount enthält quasi das verschlüsselte Duplikat wie bei manchem Cloud Provider. Mein Befehl verbindet sich quasi on-the-fly mit der zuvor in der rclone.conf registrierten Cloud während Ihr einen Mount zu der Cloud setzt. Da ich ohnehin alles in User Scripts mache, ist das kein Ding. Alles klar. Ich lasse das erst mal so. Um auf meine Eingangsfrage zurückzukommen: Die zusätzlichen Variablen in dem Container sind nach meinem bisherigen Verständnis völlig sinnlos. Man muss ohnehin eine rclone.conf manuell erzeugen. Während ich dachte, dass das der Container selbst macht,

@speedycxd und @saber1: Vielen Dank. Wahrscheinlich bin ich das Thema völlig falsch angegangen. Ihr mounted immer irgendwas. Ich verstehe einfach noch nicht wofür das hilfreich ist. Werde mich wohl noch etwas schlau machen müssen. Ich will vom Unraid Host zu einer Destination synchronisieren. Und das zeitgesteuert (also nicht in Echtzeit) sowie nur one-way. Bisher löse ich das mit User Scripts wie folgt. Läuft tippi toppi, aber wahrscheinlich laufe ich in die falsche Richtung: #!/bin/bash #arrayStarted=true #backgroundOnly=true #clearLog=true #noParity=true docker exec binhex-rclone /usr/bin/rclone sync /media/Bilder/ remote:/Bilder/ --exclude "*.xml"

Allerdings bist Du jetzt einen Schritt weiter. Der Verursacher greift lesend auf /mnt/disk1/ (sdc?) zu. Lesend, da offensichtlich nur eine Daten-Disk geweckt wird. Als nächstes den o.a. Befehl von @alturismo auf disk1 anwenden. Anschließend bist Du wieder einen Schritt weiter. Anders geht das nicht. Schritt für Schritt.