vakilando

Was somebody successfull installing the latest version 22.12.5 of Xeoma?? I'm still on version 22.3.16....

@Stri das Nerd Pack ist seit Unraid 6.11.x nicht mehr kompatibel und steht für Unraid 6.11.x im CA Store nicht mehr zu Verfügung. Ich gehe davon aus du hattest das Nerd Pack unter 9.10.x installiert? Eigentlich sollte es nach dem Uprage auf 6.11 automatisch entfernt werden - so mein Wissensstand....? Entferne es jetzt. Als Ersatz kannst du die neuen NerdTools installieren oder un-get verwenden.

Docker vergibt die IPs bei Start eines Containers selbst. Du kannst in den Docker Einstellungen einen DHCP Pool definieren und so vermeiden, dass von deinen Containern IP Adressen verwendet werden, die mit deinem DHCP-Server (z.B. Router) in Konflikt geraten.

das ist ja auch einigermaßen sinnfrei... Ein Docker Container kann nur dann DHCP, wenn der Maintainer einen dhcp client integriert hat. Wenn du VLANS mit macvlan nutzt (und nicht ipvlan) sollten sich entsprechende container mit dhcp client beim Start auch eine IP von deinem DHCP Server holen. Ob und wie das mit mehreren Containern mit ipvlan funktioniert weiß ich nicht, die haben ja keine eigene MAC-Adresse.... Ich habe VLAN mit macvlan und vergebe jedem Container sowohl eine IP-Adresse als auch eine MAC-Adresse.

ja, hab ich auch gefunden.... @mgutt würdest du vor einem Reparaturversuch einen reboot empfehlen, oder eher nicht? @Smolo Hast du vorher etwas am Server physisch gemacht? Vor einer Reparatur würde ich ggf. das Array im Wartungsmodus (maintenance mode) starten und einen Check ausführen mit den Optionen -nv (no modification, verbose). Danach eine XFS Reparatur. Siehe auch https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui

Schau dir das Plugin "Unbalance" an:

Solange man bei Kopier-/Verschiebe-Aktionen immer /mnt/user oder /mnt/cache als Ziel angibt ist es in der Tat "egal" und alles sollte korrekt angezeigt werden. Wenn bei dir auf dem Backup System Daten nur auf Disk-1 liegen und nicht unter /mnt/user würde ich als erstes dein Backup Script verdächtigen... Wie machst du die Backups?

weitere nützliche Befehle findest du hier: https://selfhosters.net/commands/ Prinzipiell müsstest du von HA aus über die platform "command_line" ein SSH Befehl an Unraid senden, der den entsprechenden virsh Befehl beinhaltet und die VM startet bzw. stoppt. Das habe ich so selbst noch nicht gemacht, aber hätte prinzipell auch Interesse, denn als es noch funktionierte habe ich es über Unraid-API gemacht.

ja, das wäre mein nächster Tipp gewesen....

hmmm, seltsam. Habe deine Einstellungen bei mir gesetzt und habe keine Darstellungsprobleme (selbe Unraid Version).... Wenn ich die Seite mit STRG+F5 neu lade sieht es kurz bevor sie komplett neu geladen ist aus wie bei dir - aber eben nur kurz. Hattest du vielleicht mal ein Theme Plugin installiert (Theme engine, Theme park, Dynamix Day Night), das ggf. nicht sauber deinstalliert wurde? Noch was...gehst du über die lokale IP auf deinen Servers oder über einen DNS Namen?

erst mal einige üblich Fragen: Hast du auf anderen Seiten von Unraid (z.B. "Start") auch das Problem? Wie sehen deine Einstellungen aus unter "Einstellungen > Anzeigeeinstellungen"? welchen Browser nutzt du? schon mal den Cache geleert und/oder mit STRG+F5 Seite neu geladen? Anderen Broweser probiert?

lesen/schreiben - sekundär

Dem würde ich mich anschließen. X könnte in den Plugin-Einstellungen angegeben werden?

habe dein Script sträflicherweise nur schnell und schlecht überflogen. Wenn das kein bis wenig Speicherplatz benötigt muss nicht nach freiem Platz geprüft werden. Der Gedanke war Platz sparen...

Die Idee finde ich ziemlich gut! Ich habe den ein oder anderen wichtigen Container, den ich vor einem Update tatsächlich manuell sichere und vorher auch prüfe welche Version (tag) installiert ist. Wenn dies über ein Plugin automatisch geschehen würde, wäre das prima. Mein nextcloudpi ist mir auf die Art letztens um die Ohren geflogen... Es wäre vielleicht sinnvoll vor dem Backup zu prüfen wieviel freier Platz auf dem Datenträger (appdata) ist. Optional könnte vielleicht auf einer Einstellungsseite des Plugins angegeben werden welche Container vor einem Update gesichert werden?

Ist sie denn Bestandteil eines Cache Pools BTRFS RAID1 .... wohl eher nicht denn dann würde der Cache Pool noch laufen? Was steht im syslog?

das wird meiner Einschätzung nach mit einem reinen Plugin nicht machbar sein, da eine Datenbank benötigt wird (wenn du schnell Ergebnisse haben möchtest). was meinst du mit "MMlsen"? Eine Textdatei mit Pfaden und Dateinamen wird bei vielen Dateien gelinde gesagt ziemlich unhandlich groß werden. Zudem muss sie auch laufend aktualisiert werden, wenn du Dateien verschiebst und/oder umbenennst. Und diese "nur" nach Stichwörtern in den Dateinamen zu durchsuchen bringt auch nur was, wenn alle Dateinamen sprechend sind, also sinnvoll den Inhalt der Datei wiedergeben.... Da kommt man um eine Indexierung der Inhalte von Dateien in einer Datenbank wohl nicht herum. Da würde ich eher mal einen der Recoll Docker Container probieren... Du kannst dich ja mal dran machen: Ich habe auf Github eine Anleitung für Unraid geschrieben, nicht mehr ganz aktuell, sollte aber noch funktionieren (ich müsste die mal updaten...): https://github.com/vakilando/unraid-docker-templates Die Installation besteht aus 4 Docker Containern (docspell-restserver, docspell-joex, docspell-consumedir, postgresql). Und natürlich hier: https://github.com/eikek/docspell und hier: https://docspell.org

Ein Unraid Plugin gibt es meines Wissens nicht. Ich habe auf meinem Rechner (Linux!) Recoll installiert. Das funktioniert prächtig. Davon gibt es auch Docker, aber ich habe sie nicht getestet. Eine Windows Version von Recoll, gibt es ebenso, ihr fehlt aber die ein oder andere Funktion (Realtime indexing, multi-thread execution) und will mit mind. 5 € unterstützt werden. Ich habe mich allerdings mittlerweile für ein "richtiges" DMS entschieden und bin nach einigen Tests bei docspell hängen geblieben.

Same here... I tried updating to the latest version 22.8.16: manually downloaded the latest version 22.8.16 (xeoma_linux64.tgz) from felenasoft renamed xeoma_linux64.tgz to xeoma_22.8.16.tgz put it in the xeoma download directory (/mnt/cache/appdata/Xeoma/downloads) changed the config file xeoma.conf by adding: VERSION='22.8.16' When starting the container it stucks at: Sep 29 20:09:44 5b7e2d0c1c9d syslog-ng[13]: syslog-ng starting up; version='3.13.2' Configuration: PASSWORD=<hidden> VERSION=22.8.16 [Sep 29 08:09:47 PM] Setting the password Reverting to version 22.3.16 and everything is fine.... Did somebody find a way to get it up and running, perhaps by manually setting the password?

Kannst du als root über ssh, oder das Terminal mit dem mc (midnight commander) bzw. über den file manager (plugin) auf die shares zugreifen?

allerdings steht in der df.txt: /dev/mapper/md5 15T 11T 3.6T 76% /mnt/disk5 ...was der obigen Meldung "No space left on device" wiederspräche. Ich steh etwas aufm Schlauch, vielleicht kann das jemand anderes (sicherlich) besser interpretieren.....? Siehst di die beiden Disks unter Unassigned Devices?

Ich habe keine Erfahrung mit der Analyse der System diagnostics, aber mir fällt auf, dass (wenn ich das richtig interpretiere) beide HHDs (disk5 und disk6) nun als Unassigned Devices auftauchen müssten disk5 voll ist relevante Stellen im syslog: Sep 24 09:13:05 VTWorld emhttpd: Device inventory: (...) Sep 24 09:13:05 VTWorld kernel: mdcmd (6): import 5 sdi 64 15625879500 0 ST16000NM001G-2KK103_WL20951K Sep 24 09:13:05 VTWorld kernel: md: import disk5: (sdi) ST16000NM001G-2KK103_WL20951K size: 15625879500 Sep 24 09:13:05 VTWorld kernel: mdcmd (7): import 6 sde 64 15625879500 0 ST16000NM001G-2KK103_ZL2J32KY Sep 24 09:13:05 VTWorld kernel: md: import disk6: (sde) ST16000NM001G-2KK103_ZL2J32KY size: 15625879500 (...) Sep 24 09:15:35 VTWorld kernel: xfs filesystem being mounted at /mnt/disk5 supports timestamps until 2038 (0x7fffffff) Sep 24 09:15:35 VTWorld emhttpd: shcmd (187): xfs_growfs /mnt/disk5 Sep 24 09:15:35 VTWorld root: xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: No space left on device (...) Sep 24 09:25:00 VTWorld root: Fix Common Problems: Error: disk5 (ST16000NM001G-2KK103_WL20951K) is disabled Sep 24 09:25:00 VTWorld root: Fix Common Problems: Error: disk6 (ST16000NM001G-2KK103_ZL2J32KY) is disabled (...) Sep 24 09:26:19 VTWorld rc.diskinfo[8966]: SIGHUP received, forcing refresh of disks info. Sep 24 09:26:20 VTWorld unassigned.devices: Disk with ID 'ST16000NM001G-2KK103_WL20951K (sdm)' is not set to auto mount. Sep 24 09:26:21 VTWorld emhttpd: error: hotplug_devices, 1719: No such file or directory (2): Error: tagged device ST16000NM001G-2KK103_WL20951K was (sdi) is now (sdm) (...) Sep 24 09:26:26 VTWorld rc.diskinfo[8966]: SIGHUP received, forcing refresh of disks info. Sep 24 09:26:27 VTWorld unassigned.devices: Disk with ID 'ST16000NM001G-2KK103_ZL2J32KY (sdn)' is not set to auto mount.

@hawihoney ....du wärst nicht der Einzige, der ein solches Problem hat. Allerdings treten die eigentlich direkt nach dem Upgrade auf 6.10.x auf... Ich hatte ähnliche Probleme bei mehreren Containern (Grafana, Xeoma, weitere) direkt nach dem Upgrade auf 6.10.1 und habe daraufhin auf der Console die Rechte teilweise wieder zurücksetzen müssen und habe in den Docker Einstellungen USER_ID / GROUP_ID gesetzt bzw. über die Extra Parameters mitgegeben. Siehe auch:

Hallo @Kuhlio, ich denke dieser Thread kann als gelöst geschlossen werden, denn du hast ja 2 weitere Threads zu diesem Thema, die gelöst sind.

@Jack8COke Ich verwende "saspus/duplicacy-web:mini" (This is the recommended version to use). Dazu gebe ich mit der Variable "DUPLICACY_WEB_VERSION" die herunterzuladende und zu verwendende Version (latest) an. Glaube aber nicht dass dies deinen Fehler erklärt... Dein Problem ist eher hier beschrieben: https://forum.duplicacy.com/t/duplicacy-failing-to-backup-on-random-days/6350 (Reduce number of threads to 1, reliability will improve) Verwendest du mehrere threads?