hawihoney

Ja: "docker start <containername>" bzw. "docker stop <containername>". Mit Hilfe des User Script Plugins könntest Du zwei Scripte erstellen die zu den gewünschten Zeiten starten. Nein. Limetech pflegt seinen eigenen Rhythmus für Minor und Major Release. Jede Nachfrage wird mit einem "Soon" beantwortet. Das nächste Release wird 6.10 heißen und befindet sich im zweiten RC (Release Candidate). Zu finden unter Bug Reports/Prereleases. Was fehlt Dir denn konkret?

Und deshalb macht man rein logisch ein Backup vorher - steht so in der Anleitung. Ich denke, dass in dieser Angelegenheit alles gesagt ist.

Du hast das nicht verstanden. Die *.key Datei enthält Deine Lizenz. Diese Lizenz-Datei liegt auf dem USB-Stick mit dem man den Server startet. Diese Lizenz ist mit genau diesem USB-Stick verknüpft und nur mit diesem gültig. Sonst könnte ja jeder die Lizenz Datei auf weitere USB-Sticks kopieren und kostenlose Lizenzen verteilen. Die GUID des lizenzierten USB-Sticks steht auf der per Mail an Dich verschickten Rechnung. Das eine professionelle Firma ihre Investition schützt wird wohl jeder verstehen. Und das eine professionelle Firma am Wochenende geschlossen hat, wird wohl auch jeder verstehen. Ich war jedenfalls gestern zu Hause. In den "First Steps" zur Inbetriebnahme eines neuen Unraid Servers steht an #9, dass man unbedingt ein Backup des USB-Sticks machen sollte: https://wiki.unraid.net/Articles/Getting_Started#Backing_Up_the_Flash_Drive Lange Rede kurzer Sinn: Wenn man weder ein Backup des USB-Sticks hat, noch ein Backup der Lizenz-Datei hat, und den USB-Stick platt gemacht hat bzw. dieser defakt ist, dann wendet man sich an den Hersteller. Dieser wird Dir helfen.

Why do you have bad feelings about that process? I guess 99% of disk replacements are done just that way. In our servers I've done that over 100 times without one single problem. - Stop the parity protected array - Shutdown the server *1) - Physically replace the old disk with the new disk - Start the server --> With a replacement disk installed Unraid will not start the array automatically - Replace the old disk with the new disk in the GUI --> Notice the warning beside the buttons on the Main Page (you are going to start a disk replacement) - Click the checkbox "Yes, I'm sure" - Start the array --> At that time, during Unraid overwrites the new disk with the data of the old disk, you can begin to work with the array again *2) *1) With server grade hardware (professional backplane) you don't need to shutdown the server, stopping the parity protected array will be enough to swap the disks in the GUI. Simply refresh the Main Page and make the changes in the GUI mentioned above. *2) If the old disk ist still readable, you have a backup of the data thats written to the new disk.

Das steht auf dem oben verlinkten Kontaktformular. Wieso ist das überhaupt relevant? Eine andere Lösung gibt es für Deinen konkreten Fall meines Wissens nicht. Jede weitere Nachfrage geht von Deiner Zeit ab <SCNR>

Das ist die Pest, da gebe ich Dir 100%-ig Recht. Lustig wird es wenn Du Tools aus den Containern nutzen willst, die dann wiederum auf gemappte Pfade zugreifen. Ich nutze bestimmt ein dutzend Skripte die Tools aus MKVToolNix bzw. MakeMKV aufrufen. Man müsste dann innerhalb der Skripte die Pfade ändern. Deshalb gibt es bei mir immer "Mnt: /mnt --> /mnt". Das ist Sicherheitstechnisch völlig irre, aber anders ging es nicht, weil sich die fest verdrahteten Container Settings teilweise nicht abschalten lassen. Und wenn ich noch etwas mehr hasse, dann sind das doppelte/überflüssige Einstellungen. Hier Fragmente eines meiner Python Skripts, welches z.B. von /mnt nach /storage mappen müsste, da der Container MKVToolNix /storage fest vergibt. In dem Skript lese ich aus Plex über deren offizielle Web API und schreibe maschinell die Titel in die MKV Dateien. Dazu muss ich dann /mnt nach /storage übersetzen: [...] mkvtoolnix_container = "MKVToolNix" mkvtoolnix_from = "/mnt/" # or None mkvtoolnix_to = "/storage/" # or None mkvinfo = f"docker exec {mkvtoolnix_container} /usr/bin/mkvinfo" mkvpropedit = f"docker exec {mkvtoolnix_container} /usr/bin/mkvpropedit" [...] info = f' --edit info --set "title={title_new}"' command = None if mkvtoolnix_from and mkvtoolnix_to: command = f'{mkvpropedit} "{video_media_part_file.replace(mkvtoolnix_from, mkvtoolnix_to)}"{info}' else: command = f'{mkvpropedit} "{video_media_part_file}"{info}' if command and not args.dryrun: result = os.popen(command).read() os.utime(video_media_part_file, (mkv_atime, mkv_mtime))

Nur zur Korrektur: Den Ordner hast Du nicht _mit_ Krusader angelegt, sondern diesen Ordner hast Du in den Docker Container Settings _für_ Krusader angegeben. Dadurch wurde dass Mapping "/mnt" (Host) --> "/UNRAID" (Container) durch das Docker Subsystem _für_ Krusader angelegt. Das mag jetzt spitzfindig klingen, aber es soll aufzeigen, was auch später einmal für andere Container/VMs wichtig werden wird. Wenn Du Dir Deine verschiedenen Mappings für Krusader anschaust, dann hast Du dort schon drei Mappings die mehr oder weniger das selbe ausdrücken: /mnt --> /UNRAID /mnt/user --> /MEDIA (ist eigentlich schon in /UNRAID enthalten) /mnt/disks --> /UNASSIGNED (ist eigentlich schon in /UNRAID enthalten) Wenn Du nicht unterschiedliche Berechtigungen bei den Mappings verwendest, ist einiges überflüssig. Mit dem bisher erworbenen Wissen kannst Du das in Zukunft bestimmt besser organisieren. Ein Hinweis: Wenn Du damit sofort beginnst, dann wirst Du innerhalb der Container (Plex, ...) einiges anpassen müssen. Das hat zur Folge, dass Du Dich auch mit deren Eigenarten beschäftigen musst (Stichwort: Z.B. Gesehenstatus bei Plex). Also aufgepasst ...

Es sind nicht alle blauen Pfeile aufgeklappt, deshalb unter Vorbehalt: Du nutzt in den Docker Containern /UNRAID bzw. /Unraid als Mapping zum Host (dem Server). Das solltest Du tunlichst nicht löschen. Würdest Du /UNRAID löschen können dann wäre Dein Server leer, da /mnt gemappt ist. Was /UNRAID/disk5/appdata angeht. Wie gesagt, unter Vorbehalt: Ich denke das kann weg. Aber nur appdata - nicht disk5 und nicht /UNRAID. Vielleicht guckt noch ein zweites Paar Augen drauf.

Die *.key Datei liegt/lag auf dem USB-Stick. Wenn Du weder diese Datei noch eine Sicherung von dem Stick hast, wende Dich an den Hersteller. Der benötigt u.a. die E-Mail Adresse unter der die Lizenz erworben wurde. https://unraid.net/contact

@Nebrius Guck mal auf dem Screenshot unten rechts:

Ok, genau das hatte ich vermutet. /UNRAID ist nicht das Wurzelverzeichnis von Unraid selbst sondern nur auf einer der Platten - das dahinter dann .../disk5/... steht zeigt, dass irgendjemand bzw. irgendetwas falsch konfiguriert ist bzw. falsch kopiert wurde. Und da dieser Ordner scheinbar nicht zu löschen ist, greift wohl immer noch eine fehlerhafte Konfiguration. 1.) Mach mal bitte Screenshots von den Docker Einstellungen und, wenn Du VMs nutzt, den VM Einstellungen. Damit bekommen wir heraus, ob für die Zukunft alles korrekt eingestellt ist: 2.) Mach einen Screenshot von der Docker Container Übersicht. Damit bekommen wir heraus, ob ein Container falsch konfiguriert ist. Wichtig sind hier die Pfade, Also alle blauen Pfeile nach unten aufklappen:

Vielen Dank. Dann bleibt das jetzt so. IPMI muss unter allen Umständen verfügbar bleiben.

Angeregt durch diverse Threads hier, habe ich mir mal meine Netzwerkeinstellungen angeschaut. Leider verstehe ich von Netzwerktechnik nicht sehr viel. Kann mir bitte jemand auf die Sprünge helfen. Sieht das alles sauber aus? Status: Ich nutze ein Supermicro X12SCA-F Motherboard. In allen drei Ethernet Ports steckt ein Gigabit Kabel. Diese führen zu einem Unmanaged 24-Port Gigabit Switch im Server-Schrank. Von diesem Switch führt ein weiteres Gigabit Kabel zu einem weiteren Unmanaged 24-Port Gigabit Switch für die Haus-Verkabelung. Und von diesem Haus-Switch führt ein Gigabit Kabel zum aktuellen Fritzbox Router. Ich nutze sporadisch - extrem selten - IPMI um den Server zu managen. Es soll aber unter allen Umständen aktiv bleiben. 1.) Wird nur ein Ethernet Kabel - egal welches - aus dem Motherboard entfernt erscheint immer eine Fehlermeldung. Diese besagt dann sinngemäß, dass eine Verbindung fehlt. Ok, könnte ich verstehen, wenn ich drei Verbindungen benötigen würde. Aber IPMI und Server selbst sind für mich zwei Verbindungen. Das ist schon mal mein erstes Problem, welches mich seit geraumer Zeit beschäftigt. Wieso müssen alle drei Ethernet Ports belegt werden, damit der Server glücklich ist? 2.) Vor ein paar Minuten hat @mgutt einem anderen User einen Netzwerk Befehl für die Konsole geschickt. Als Spielkind muss ich das auch probieren und gebe folgendes ein: root@Tower:~# ethtool --show-eee eth0 EEE settings for eth0: EEE status: disabled Tx LPI: disabled Supported EEE link modes: Not reported Advertised EEE link modes: Not reported Link partner advertised EEE link modes: Not reported root@Tower:~# ethtool --show-eee eth1 EEE settings for eth1: EEE status: enabled - active Tx LPI: 17 (us) Supported EEE link modes: 100baseT/Full 1000baseT/Full Advertised EEE link modes: 100baseT/Full 1000baseT/Full Link partner advertised EEE link modes: 100baseT/Full 1000baseT/Full Da denke ich Oops. Wieso habe ich nur eth1 und gucke in meine Unraid Settings: Sieht das sauber aus? Ist das korrekt oder gibt es Änderungsbedarf? Vielen Dank.

Exakt, bin gestern noch darüber gestolpert. Das ist meines Erachtens verwirrend, kann katastrophale Fehler provozieren und gehört geändert.

In der Regel kann man das Image in den Docker Settings löschen und neu aufsetzen. Bis 6.9.2 befinden sich die Templates auf dem Flash und alle Container lassen sich neu aufsetzen. Nach 6.9.2 sollte man die Container Einstellungen selbst sichern.

Och, kenne ich, passiert mir dauernd. Ich muss dann den Server neu starten damit Unraid/Linux die Disk aus /dev vergisst. Manchmal ist die Platte wirklich hopps. Dann hilft nur noch wipefs/diskpart - je nach Betriebssystem. Also: 1. Neustart ohne Platte Jetzt müsste die Platte raus sein. 2. Testen ob Platte noch lesbar ist. 3. Wenn nein, gehe zurück zur Badstrasse und baue die Platte neu auf Im Handling von USB Platten liegt meiner Erfahrung nach Linux meilenweit hinter Windows. Ich habe drei Backup Platten die der Reihe nach im Tage, Wochen, Monats Rhytmus angesteckt werden. Ich habe noch nie Server sooft neu starten müssen weil sich Platten nicht komplett unmounten lassen.

Jetzt weiß ich auch nicht mehr weiter. Da kann nur noch die Diagnostics helfen. Gehe mal unter Tools und starte die Erzeugung der Diagnostics. Poste die Datei hier.

Wenn das alles ist, dann ist da auch nix drin. "." steht für den aktuellen Ordner. ".." steht für den Ordner darüber. Geh mal eine Etage höher und zeige mal das gesamte Bild. Hast Du überhaupt User Shares aktiviert? ls -lisa /mnt/user/

Ja, mit manchen Dingen muss man sich etwas länger beschäftigen Ein Update des Nextcloud Docker Containers aktualisiert nicht das komplette Nextcloud System. Der Sprung auf eine aktuellere Version erfordert zusätzlich den Upgrade von Nextcloud über die Nextcloud Oberfläche. Wenn es so weit ist, wirst Du in der Web-GUI von Nextcloud darauf hingewiesen.

Hast Du denn auch das Mapping zwischen Unraid Server und Docker Container vorgenommen? Sonst gibt es /mnt/user nicht im Container. Bei mir sieht das zum Beispiel so aus: Dazu richtest Du einen zusätzlichen Pfad ein:

Ich tippe auf Dateirechte. Such einen der betroffenden Ordner raus und gib auf der Unraid Konsole den Befehl "ls -lisa /mnt/user/xxx" und ersetze xxx durch den Ordnernamen. Poste die Ausgabe des Befehls. Von Interesse sind nur die Dateirechte und nicht die Dateinamen. Letztere kannst Du getrost vor dem Posten abschneiden.

Wir reden hier über den Root-Folder /UNRAID auf dem Server, oder? Poste mal die Ausgabe dieses Befehls auf der Unraid Konsole: ls -lisa /

Auf unseren Android Mobilgeräten ist überall der Dateimanager+ installiert und dort Nextcloud als Cloud eingerichtet. Ich finde das von der Performance her ok. Hmm, bei meinen letzten Versuchen war das grotten langsam und stürzte regelmäßig zum krönenden Abschluss ab. Von der GUI fange ich erst nicht an - fürchterlich. Auch E-Books liegen bei uns wunderbar organisiert in Nextcloud und können im MoonReader direkt geladen werden. Klappt astrein. Und genau die drei würde ich nie nach außen freigeben. Nur hinter VPN. Einige der von Dir freigegeben Dinge können mit Nextcloud abgebildet werden. Nicht falsch verstehen, ich finde den Server Nextcloud ok, aber die Tools drumherum sind m.M.n. eine Katastrophe. Deshalb nutze ich WebDAV und kann dann die Klienten/Tools meiner Wahl verwenden - selbst innerhalb Windows.

Wie soll das denn gehen? Sind Eure Daten fest und unveränderbar? Zum Schutz vor Viren hilft wie im wahren Leben <hust hust> vor allen Dingen "Hirn einschalten". Dazu auf Klienten wie Windows einen wirksamen Schutz auf diesen installieren. Regelmäßige Backups der unverzichtbaren Daten (inkl. Unraid Flash) gehören ebenso dazu. Und vor allen Dingen: Nicht jeden Sch***ß installieren sondern eher mäßigen und reduzieren. Hat man mal ein funktionierendes Umfeld geschaffen, dann kann man auch mal aufhören, alles und jedes aufzurufen und installieren. Ich kann mir noch nicht mal ansatzweise vorstellen, wie ich mit auf Lesen reduzierten Netzwerkverbindungen umgehen soll. So sieht es bei uns aus: - Alle Disk-Shares hidden - User-Shares abgeschaltet - Kein Cache - FTP abgeschaltet (nach jedem Reboot erneut) - Die Handvoll Docker Container (SWAG, Plex, Nextcloud, Code-Server, MakeMKV, NZBGet und MKVToolNix) haben natürlich mehr oder weniger Zugriff auf alles was für sie notwendig ist. Meist r/w außer bei Plex. - SSL Zugriff von außen nur für Plex und Nextcloud - Weitergehender Zugriff von außen nur über VPN (Fritz) Kommen wir zu den Klienten wie Windows. Hier ist es schwieriger. Da wir alle auf dem Server direkt arbeiten, muss für diese das r/w freigegeben sein. Hier nutzen wir WebDAV zu Nextcloud.

Probier mal Folgendes aus: Tausche mal die Ethernet Kabel an den Slots des Routers. Nur um zu schauen, ob das nur an einem Port auftritt.