mgutt

Das Unraid Konto ändern dürfte schwierig werden: https://unraid.net/policies Für Limetech sind das ja erst mal zwei verschiedene "Leute". Dass du der Inhaber beider Accounts bist, müsstest du denke ich erstmal gegenüber dem Support "belegen". Und dann auf deren Kulanz hoffen, dass die das überhaupt technisch übertragen können oder das einfach technisch gar nicht vorgesehen haben. Also da heißt es wohl den Support fragen. Ergebnis darfst du gerne posten 😁

Ich habe mehrere Server und aktualisiere immer erst einen "unwichtigen", wo keine Anwendungen drauf laufen, sondern der nur als Backup / Netzlaufwerk genutzt wird. Allerdings mache ich nie sofort Upgrades, auch nicht bei diesen weniger wichtigen Systemen. Ich habe zB das Upgrade von 6.X auf 7.1.4 erst Anfang August vollzogen. Also 3 Monate nach Release von 7.1 und 1,5 Monate nach Release von 7.1.4. Wenn du also eine generelle Empfehlung haben willst: Mach kein Update, wenn das letzte noch keinen Monat alt ist. Und zu 7.1.4 kann ich tatsächlich keine Fehler wahrnehmen. Das mit den verzögerten Updates mache ich übrigens auch bei Docker Containern. Ich arbeite da überall mit tags und bleibe erst mal eine Weile bei einer Version, wo dann in der Regel nur noch Sicherheitsupdates folgen.

@andber Aus Interesse: Hast du die nach dem Tausch genauso wieder in Betrieb genommen und laufen sie seitdem fehlerfrei?

@bobokun I fixed a small bug and tested the new version of the Discord Agent. Feel free to test it by yourself: https://github.com/unraid/webgui/pull/2364#issuecomment-3300620990 I think it will be part of the next unraid release.

Option A) Ask the dev of the unbalanced plugin to add hard link support. Option B) Use rsync: rsync -aH --remove-source-files --numeric-ids /mnt/disk3/sharename/backups/ /mnt/disk5/sharename/backups & disown the final "/" of the source path is important or it will create an additional source "backups" folder in the destination path. the "& disown" makes it a background process, so you can close the terminal. The "-H" keeps hardlinks Use "/disk" paths only (as in my example), not "/user" paths (avoids overhead and avoids accidentally overwriting of files, which can happen if "/user" points to the same disk) To finally delete the empty source dirs: find /mnt/disk3/sharename/backups/ -type d -empty -delete

I think it's because the authority server tries to reach your domain through your IPv6, which is wrong: How do you update the IPv6 of your domain and does it target your NPM container? Note: IPv6 must not be the one of your router as it is for IPv4. You can test your IPv6 similar to IPv4 in your browser by adding brackets. Example: http://[2001:4860:4860::8888]:80/You must see the npm welcome page equal to your IPv4 tests. IPv6 can be more challenging to setup. On the first page I showed one example by running npm in the host network, so it shares the same IPv6 as unraid. But you need to update your domains IPv6 everytime Unraids IPv6 changes. Most people gave up and disable IPv6 😅

Thank you for your input. I don't think that my script should handle this. Instead I opened a pull request to let the Discord notification agent handle the escaping: https://github.com/unraid/webgui/pull/2364

After re-executing the script, does the loading time decrease or not? Maybe you only need to change the preload_threshold setting?!

Both are relevant for creating and updating certificates. That's irrelevant for certs. We need the errors which are logged in this file. I still don't understand why they aren't forwarded to the container output, so we would be able to see them through the unraid gui. So please open the file in your npm appdata folder. A simple search for "error" or "fail" should show the relevant lines. Else remove your private information and post it here.

Es gibt ein Plugin dafür: https://forums.unraid.net/topic/114415-plugin-docker-compose-manager/

Sounds like your database gets corrupted. Is your app data share located on the cache only? (Best option is enabling exclusive shares and bring the cache completely on an SSD, but backups are mandatory)

Da rsync über das Terminal als root läuft, sind die Fehlermeldungen tatsächlich komisch. Was man aber sieht: zuerst kopiert er erfolgreich .../java/awt/Stroke.html 6 Operationen danach kommt dann ein Fehler zu .../java/awt/.Stroke.html.Q4Hcxj Da rsync standardmäßig Temp-Dateien erzeugt, handelt es sich also um die selbe Datei, die 2x kopiert wird. Daraus schließe ich, dass du -H (--hard-links) benötigst, weil hier in der Quelle ein Hardlink auf die selbe Datei verweist und du ohne -H diese Datei ansonsten 2x am Ziel erzeugst. Wobei ich tatsächlich nicht verstehe, warum rsync sich daran stört. Da das ja nicht parallel, sondern hintereinander passiert, könnte rsync ja einfach 2x die Datei erzeugen, also einfach die Zieldatei noch mal überschreiben, aber evtl macht rsync das intern nicht und erzeugt lieber einen Fehler (der dann aber echt kryptisch ist ^^). Mal einen Test machen: mkdir /tmp/source touch /tmp/source/test.txt ln /tmp/source/test.txt /tmp/source/hardlink-auf-test.txt # stat /tmp/source/* File: /tmp/source/hardlink-auf-test.txt Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 0,2 Inode: 1868831 Links: 2 Access: (0666/-rw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2025-08-13 20:45:48.864189719 +0200 Modify: 2025-08-13 20:45:48.864189719 +0200 Change: 2025-08-13 20:46:57.617528412 +0200 Birth: 2025-08-13 20:45:48.864189719 +0200 File: /tmp/source/test.txt Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 0,2 Inode: 1868831 Links: 2 Access: (0666/-rw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2025-08-13 20:45:48.864189719 +0200 Modify: 2025-08-13 20:45:48.864189719 +0200 Change: 2025-08-13 20:46:57.617528412 +0200 Birth: 2025-08-13 20:45:48.864189719 +0200 Wir haben also zwei Dateien mit gleicher Inode und 2 Links (= Hardlinked) Dann weiter: mkdir /tmp/destination # rsync -vahP /tmp/source /tmp/destination/ sending incremental file list source/ source/hardlink-auf-test.txt 0 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=1/3) source/test.txt 0 100% 0.00kB/s 0:00:00 (xfr#2, to-chk=0/3) sent 212 bytes received 58 bytes 540.00 bytes/sec total size is 0 speedup is 0.00 # stat /tmp/destination/source/* File: /tmp/destination/source/hardlink-auf-test.txt Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 0,2 Inode: 1869897 Links: 1 Access: (0666/-rw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2025-08-13 20:47:54.994976735 +0200 Modify: 2025-08-13 20:45:48.864189719 +0200 Change: 2025-08-13 20:47:54.994976735 +0200 Birth: 2025-08-13 20:47:54.994976735 +0200 File: /tmp/destination/source/test.txt Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 0,2 Inode: 1869898 Links: 1 Access: (0666/-rw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2025-08-13 20:47:54.994976735 +0200 Modify: 2025-08-13 20:45:48.864189719 +0200 Change: 2025-08-13 20:47:54.994976735 +0200 Birth: 2025-08-13 20:47:54.994976735 +0200 Ohne -h hat rsync beide Dateitn neu erstellt. Spricht also gegen meine Theorie und wenn ich jetzt drüber nachdenke, eigentlich auch logisch. 😅 Was passiert dann 🤔 Vielleicht ein hardgelinkter Ordner... macht eigentlich auch keinen Sinn. Sicher, dass du rsync nicht versehentlich 2x parallel gestartet hast? Du nutzt ja -P, also --partial. Vom Prinzip braucht man das ja nur, wenn man mit Abbrüchen rechnet. Lass das mal weg und verwende stattdessen --inplace, so dass gar keine temp-Datei erzeugt wird. Außerdem macht es bei einem Backup in ein einziges Verzeichnis wenig Sinn, wenn du kein --delete verwendest, weil bei jedem neuen sync, würden ja vom Ziel verschwundene Dateien im Ziel-Backup verbleiben = evtl korruptes Backup. Falls die Quelldateien außerhalb von Unraid erzeugt wurden zB in einem Docker oder einer VM, solltest du außerdem --numeric-ids in Betracht ziehen. Mein Vorschlag daher: rsync --verbose --archive --hard-links --numeric-ids --human-readable --progress --inplace --delete /mnt/disk1/backup/java /mnt/disk2/datest/ Warum aber dein Fehler kommt, hätte ich trotzdem gerne gewusst 😅

Du meinst die Option "Mirror syslog to flash"? Flash meint in dem Fall den USB-Stick. Und was meinst du mit "leer". Das Log belegt aktuell 1% von 128MB. Ein Unraid Log kann sehr lange bei 1% stehen bleiben. So viel wird da nicht geloggt. Siehst du unter Tools > System Log wirklich nichts? Ich vermute schon.

Wenn man eine Parität hat, darf nur eine Platte ausfallen. Der Rebuild braucht dann alle restlichen Platten. Wenn du also zwei defekte Platten hast, sind die Daten einer komplett defekten Platten verloren. Wenn du ohne Rebuild auf die Daten von Disk 5 zugreifst, dann werden diese Daten über die restlichen Disks emuliert. Dh du bist auch dann voll von Disk 6 abhängig. Bei defektem RAM kommt noch dazu, dass die Paritätsplatte selbst völlig falsche Daten enthalten könnte. Dann würde nicht mal mehr der Rebuild mit einer defekten Platte gehen. Und das ganze kann noch schlimmer werden: Sagen wir, dass wegen defektem RAM die Parität hinüber ist. Disk5 hat kurz die Verbindung verloren und du startest mit verfälschten Daten der Paritätsplatte den Rebuild von Disk 5: Auch Disk 5 Daten gehen kaputt. Das gleiche Spiel gilt übrigens auch, falls Disk 6 aktuell kompletten Unsinn zurückgeben sollte. Dann würde der Rebuild von Disk 5 mit Unsinn-Daten erfolgen = Disk 5 wird kaputt geschrieben. Daher würde ich jetzt gar nichts mehr mit Rebuild oder Emulation versuchen. Deine einzige Rettung sind die echten Daten von Disk 5, in der Hoffnung, dass der Rebuild die Disk nicht noch zerlegt hat. Du darfst ja nicht vergessen: Disk 5 hatte zwar Lesefehler, aber die Daten auf Disk 5 sind ja nativ vorhanden. Ein Rebuild überschreibt nur einfach die Daten, die bereits drauf sind. Das macht Unraid aus Sicherheitsgründen, weil zwischen dem Lesefehler und dem aktuellen Zeitpunkt, könnten ja weitere Daten auf Disk 5 hinzugekommen sein. Wenn du das aber ausschließen kannst, dann interessieren dich eigentlich nur die Daten, die eh schon drauf sind. Was ich also machen würde: erst mal RAM testen und dann nur garantiert fehlerfreien RAM verwenden Array stoppen und nicht mehr starten (Autostart in Disk Settings deaktivieren) Docker deaktivieren VM deaktivieren Screenshot von der Disk-Übersicht machen, damit du weißt, welche Disk wo zugewiesen war unter Tools > New Config die Pools behalten auswählen und dann bestätigen jede Disk kann nun einzeln mit dem Unassigned Devices Plugin READ-ONLY (!) gemountet werden Nun kopierst du alle Daten von Disk 5 auf eine neue HDD (neue HDD, denn Disk 6 kannst du wegen der Lesefehler nicht nehmen und die Paritätsdisk würde ich mir erst mal aufheben) sollte das fehlerfrei funktionieren: vermutlich ist die Disk 5 noch in Ordnung, das ganze mit allen anderen Disks wiederholen, bis du alle mit Fehlern ermittelt hast falls zB Disk 1 in Ordnung sein sollte: Ausbauen und an dem Anschluss eine defekte Disk anschließen (vielleicht ist nicht die Disk kaputt, sondern das Kabel?!) vielleicht ist die Disk auch nicht kaputt, sondern die Kühlung mangelhaft?! Ich hatte schon mal CRC Fehler als eine meiner HDDs über 50 Grad erreicht haben. falls eine fehlerhafte Disk gefunden wurde zB weil nicht alle Dateien kopiert werden können oder sie gar nicht mehr zu mounten ist. In dem Fall nicht weiter herumspielen, sondern gleich eine Datenrettung versuchen: https://www.ufsexplorer.com/ufs-explorer-standard-recovery/ (nicht über USB, sondern nativ SATA!) Falls Disk 5 und Disk 6 komplett hinüber sein sollten: Wenn auf Disk 6 noch nie Daten waren (also nicht eine einzige Datei!!!) und der RAM die Parität nicht beeinflusst hat und wenn alle anderen Disks nicht mehr verändert werden (nur noch mit READ-ONLY auf alle Disks zugreifen!!!), könntest du auch versuchen zwei neue HDDs zu kaufen. Irgendeine Beliebige als Ersatz für Disk 5 und exakt die gleiche (!) als Ersatz für Disk 6. Disk 6 bereitest du dann mit dem Unassigned Devices Preclear Plugin vor. Das Plugin schreibt auf diese neue Disk 6 alles voller Nullen. Wichtig: Wieder mit XFS formatieren. Nun das Array exakt so zuzuweisen, wie es vorher war, nur das die Ersatz HDDs dann in Disk 5 und Disk 6 zugewiesen werden. Beim Start wählt man dann, dass die Parität NICHT neu gebaut werden soll, sondern dass man der bestehenden Parität vertraut. Der Rebuild bzw die Emulation von Disk 5 erfolgt dann mit der "alten" Partität, allen anderen alten Disks und der nagelneuen Disk 6 (auf der nur Nullen enhalten sind). Falls doch mal Daten auf Disk 6 lagen, wird der Rebuild nicht komplett erfoglreich passieren. Dann werden ein Teil der Dateien korrupt sein oder das ganze Dateisystem nicht lesbar sein. Das hängt ganz davon ab wie viele Daten auf Disk 6 mal lagen. Ich würde in dem Fall dann diese neu erzeugte Disk 5 auch noch mal mit der oben gennnten Datenrettungssoftware behandeln. Jedenfalls ist das wirklich der letzte Strohhalm und jeder Fehler führt zum Totalverlust. Wenn du durch bist und neu mit einem Array starten willst: wieder über New Config und Pools behalten das Array leeren Paritätsdisk wieder dem Paritätsslot zuweisen, der Rest kann beliebig oder gleich zugeordnet werden diesmal die Parität neu bauen lassen Für die Zukunft: niemals defekten RAM verwenden eine Parität ist kein Backup evtl über zusätzlichen Backup-Server für die wichtigsten Daten nachdenken oder zumindest auf eine separate Disk des Arrays die wichtigsten Daten kopieren Dh wenn sehr wichtige Daten auf Disk 1 liegen, diese regelmäßig zB auf Disk 7 kopieren. Solange nicht diese beiden parallel ausfallen, ist alles fein.

I don't know how Kodi does the setup, but maybe it needs root to create a database, before creating the tables and data?! And yes, finally it's irrelevant if you use one mariadb container per application if you use the root login.

Are you sure Kodi can reach mariadb? Where is Kodi running? If it is outside of unraid: test external access with an application like Heidi SQL. If it is an internal container: Which networks are both using?

The user scripts plugin is not able to run scripts infinite in the background. Or to be more precise: The user scripts plugin starts scripts by PHP and PHP has a maximum execution time. So the script will still run in the background, but the user scripts plugin looses control of it. If you are fine with this, we could of course change the script, so it runs infinite in the background, but how do you control its run status? Let's say a bug or OS error kills the script. How do you monitor this scenario? Wouldn't it be better to schedule the script instead? What is your main target to have it run permanently? Live notifications on new log entries? So something in combination with inotifywait? I'm not a huge fan of having a permanent process monitoring a file for rare new log entries, but yes of course this would be possible to build.

Usually that means your database file is broken.

Mein Tipp: Hinterlege immer die letzte Version, nie die aktuelle und latest schon gar nicht. Und Auto-Update wie manche es bei Dockern machen, kann ich erst recht nicht empfehlen. Bei Nextcloud kommen die Plugin Entwickler gar nicht hinterher, weshalb es häufig zu Problemen kommt, wenn man automatisch die latest installiert. Ich habe aktuell das eingestellt: nextcloud:30 Aktuell ist Version 31: https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule Updates mache ich ausschließlich per Hand und auch immer nur nach frischem Backup. Backups wiederherstellen wäre aber sowieso mein allererster Tipp. Einfach damit man weiß was man machen muss, wenn es mal knallt. Weil mit einem produktiven System wirst du wohl kaum immer wieder neu installieren wollen. Ich mache übrigens auch nie Updates von Datenbank und Nextcloud parallel. Heute kann ich zB beide aktualisieren. Ich stoppe dazu Nextcloud und mache das DB Update. Wenn das durch ist, starte ich Nextcloud wieder und warte einen Tag, bevor ich die Nextcloud aktualisiere. Es ist zB absolut unlogisch die Datenbank zu aktualisieren, wöhrend Nextcloud gerade läuft. Aber genau das machen Auto-Updates. Die kennen die Abhängigkeiten zwischen den Containern nicht.

Yes. Forward 80 and 443 to npm, add a new host with your specific server domain and set the target ip of your server.

Sorry, forgot that point. Only possible with DNS challenge. So still the best way to migrate everything to NPM.

You could then add those domains to npm and configure the servers ip address as the target. You are not forced to use local container ips as target. If you prefer the ugly addresses simply forward those ports to npm. For example 8443 to unraid_ip:443 and 8080 to unraid_ip:80

Why not merging everything to npm? Other ports are possible, but ugly as you need to add the port like https://example.com:4443/index.html

Rsyncs default is to compare timestamp AND size. So this does not really make sense. And as you don't use --partial, but a partial file exists, it sounds like a problem with your rsync target: > --partial keep partially transferred files Note: If you use rsync over ssh, the rsync binary on the target server runs in --server mode and does all the actions after a disconnect as for example deleting a partial transfered file.

Released version 1.4 - added the new errors words "mismatch" and "invalid" - added two new error lines, which are ignored by default (see comments in code) - solved a bug which caused not finding new errors because last_line="$line" did not contain trailing whitespaces (solved by adding "IFS=") - solved a possible bug by adding "--text" to both greps (if syslog lines contain binary data) - added a check to verify that "$line_number_file" contains a number and if not set "line_number_start=0" so it does not break the following code (instead it restarts searching from the first line, but I think this is acceptable). @jordanchin I think the new version fixes your problem. Sorry for the late bug fix, but I wasn't able to reproduce it until I faced it on my own 😅