mgutt

Wenn Du einen Share auf öffentlich stellst, dann kann ihn jeder in deinem Netzwerk öffnen, verändern oder löschen. Ein Container greift außerdem nicht auf einen Share zu, sondern auf einen lokalen Ordner. Es kann sein, dass du den auch als Share freigegeben hast, aber das interessiert den Container nicht. Einen Share also immer nur Privat mit Login freigeben! Denk aber an Backups, denn wenn der Client mit dem Login Ransomware drauf bekommt, zerlegt die trotzdem die Daten.

Hast du vorher SMB benutzt oder vielleicht doch AFP? AFP ist ja aus der Beta rausgeworfen worden: https://forums.unraid.net/bug-reports/prereleases/unraid-os-version-690-beta22-available-r955/page/6/?tab=comments#comment-9533 Wenn du auf die WebGUI kommst, ist der Server von deinem Rechner aus ja erreichbar. Also liegt es wenn an SMB. Führe mal das im WebTerminal aus um den SMB Dienst neu zu starten: samba restart Hilft das oder gibt es eine Fehlermeldung? Dann die Frage ob die Workgroup gleich ist. Prüfe diese auf deinem Mac und auf dem Server unter Settings > SMB Settings > Workgroup Settings.

@michael390 Bist du per LAN oder WLAN verbunden? Kannst du bitte testweise in den Global Share Settings den Disk Cache aktivieren und auf //Tower/Cache, also direkt auf die SSD hochladen? Welche CPU hat dein NAS?

Ich meine den Threadersteller

Kurze Frage: Welchen Nextcloud Container nutzt du? Es gibt ja einen, der MariaDB enthält und den offiziellen, wo man selbst MariaDB in einem separaten Container bereitstellen muss.

Es gibt für fast jedes Endgerät Software dafür. Auf einem Smartphone/Tablet könnte man es zb über ein WoL Widget lösen. Da gibt es sicher eine Lösung im Store. Man könnte es auch per Sprachbefehl über einen smarten Lautsprecher umsetzen zb Alexa. Macht nur wenig Sinn, wenn dessen Kaufpreis und Stromverbrauch eine Amortisierung quasi unmöglich macht. Noch eine Idee wäre, sofern zb eine Fritz!Box eingesetzt wird, dass man nicht die lokale IP, sondern eine DDNS beim Abspielen der Musik nutzt. Das setzt eine Port Freigabe voraus und die WoL Aktivierung unter Fritz!Box > Netzwerk > IP des Servers. Habe ich allerdings nie getestet.

Hast du mal probiert den Creator als Admin zu starten? Solche Fehler habe ich bei manchen Sticks auch mit dem Creator von Raspberry PI OS.

Nutzt du das Docker Folder Plugin? https://forums.unraid.net/topic/91828-solved-read_folders-error/ Dann weg damit

Ich kenne das Plugin nicht, aber kann es sein, dass es das NAS erst schlafen schickt, wenn die Platten im Ruhezustand sind? Wenn ja, hast du unter Disk Settings eine entsprechende Zeit eingestellt? Ob nun rsync, mc, über SMB freigeben und dann Drag & Drop, vom alten NAS über das Netzwerk, usw Da kann jeder wie er beliebt vorgehen. Die Frage ist was dich an der aktuellen Methode stört? Also du möchtest den Cache von einem Share auf "Prefer" setzen und nicht auf "Yes", damit nicht alle Dateien aufs Array verschoben werden. Nun sollen gewisse Verzeichnisse in diesem Share aber trotzdem aufs Array verschoben werden? Das ist so nicht vorgesehen und müsste tatsächlich per Skript gelöst werden. Aber vorab, kannst du nicht deine Daten so verteilen, dass du sie auf zwei verschiedenen Shares hast, also einer mit Cache prefer und der andere mit Cache yes?

Ok, ich habe den Quelltext gefunden. Es werden mehrere Dateien bei einer Änderung des Netzwerks ausgeführt, wobei die update.php nur dafür sorgt, dass die /include/update.ethernet.php included und die /scripts/netconfig ausgeführt wird: <form markdown="1" name="eth0_settings" method="POST" action="/update.php" target="progressFrame" onchange="exitCode(this,false)" onsubmit="return prepareSettings(this)"> <input type="hidden" name="#file" value="<?=$ini?>"> <input type="hidden" name="#include" value="/webGui/include/update.ethernet.php"> <input type="hidden" name="#section" value="eth0"> <input type="hidden" name="#command" value="/webGui/scripts/netconfig"> Und in der /scripts/netconfig gibt es nur wenige Terminal-Kommandos. Am Anfang stoppt er zB das Interface: $set = $ifname = $argv[1]; $run = $set != 'none'; ... exec("/etc/rc.d/rc.inet1 ".escapeshellarg("{$ifname}_stop")." >/dev/null"); Und am Ende des Quelltextes startet er das Interface dann wie folgt wieder und lädt das Shell Script create_network_ini: // start interface with updated (new) configuration // don't execute when only interface description has changed if ($run) { exec("/etc/rc.d/rc.inet1 ".escapeshellarg("{$ifname}_start")." >/dev/null"); exec("/usr/local/sbin/create_network_ini >/dev/null"); } Diese Kommandos könnte ich dann selbst mal testen und evtl Fehlermeldungen prüfen. In der create_network_ini passiert dann auch nicht mehr viel. Die generiert einfach eine neue /var/local/emhttp/network.ini und zum Schluss gibt es noch eine Zeile betreffend NGINX, die aber nur ausgeführt wird, wenn man DHCP aktiviert (weil $data sonst leer ist): IFACE=${IFNAME[$i]:-eth$i} ETH=${IFACE/#bond/eth} ETH=${ETH/#br/eth} ... if [[ ${USE_DHCP[$i]} == yes ]]; then NET=($(ip -4 addr show $IFACE|awk '/inet /{sub("/"," ",$2);print $2;exit}')) GW=$(ip -4 route show default dev $IFACE|awk '{print $3;exit}') ... data="${data}${ETH}_I_IPADDR:0=${NET[0]} ${ETH}_S_NETMASK:0=$(mask ${NET[1]}) ${ETH}_I_GATEWAY:0=$GW " ... # send update information [[ -n $interface && -n $data && -e /var/run/nginx.socket ]] && curl -sfd "$data" --unix-socket /var/run/nginx.socket http://localhost/pub/dhcp?buffer_length=0 >/dev/null 2>&1 Das würde heißen, dass schon das simple Stoppen des Interface das Problem verursacht. Mehr dazu, wenn ich weiter testen kann....

Ok, was Neues herausgefunden. Die Erreichbarkeit ist schon nicht mehr gewährleistet, wenn ich nur das Bonding deaktiviere. Hier die Schritte in Bildern: Nach Löschen der Network Config sah es so aus: Die MAC-Adresse wurde auch von der Fritz!Box übernommen (wohlgemerkt steckt kein Kabel in B4:2E:99.A8:C7:2A): Dann habe ich die Geräte umsortiert: Nach dem Neustart erhielt ich nun erstmals eine DHCP Adresse, dh den Haken rausnehmmen bei "immer die gleiche IPv4" auf der Fritz!Box hat das Verhalten nun geändert: Und als nächstes habe ich bonding auf "no" gestellt und "Apply" gedrückt. Danach war der Server nicht mehr erreichbar. Das klingt nun eher nach einer Inkompatibilität zum 10G Treiber. Was meint ihr? Ich teste nachher noch ob ich das Bonding drin lassen kann und nur die IP auf statisch setzen kann. EDIT: Also der Server wird auch dann unerreichbar, wenn ich das Bonding aktiv lasse und nur die IP auf statisch ändere. Scheinbar ist jede Einstellungsänderung ein Problem. Kann ich irgendwo nachschauen wie Unraid die Einstellungen aktualisiert? Also dass ich die Kommandos mal selbst testen kann? EDIT2: Und wieder was Interessantes. Nachdem ich nun die IP auf statisch geändert hatte, musste ich ja neu starten. Dann habe ich das Bonding deaktiviert und das hat nun anstandslos geklappt?! Also noch mal zusammengefasst: - Bonding deaktivieren und IP auf statisch ändern = offline - Bonding deaktivieren = offline - IP auf statisch ändern = offline - Bonding deaktivieren, wenn bereits eine statische IP existiert = bleibt online

Several times a day this error happens to me: Maybe its time to raise the limit?

Mal ein paar Vorschläge / Korrekturen: https://unraid.net/de/preis Du kannst Unraid OS Kostenlos 30 Tage, mit uneingeschränktem Zugriff auf alle Funktionen, testen. 🔃 Teste 30 Tage kostenlos und uneingeschränkt alle Unraid OS Funktionen. Die angeschlossenen Speichergeräte bezieht sich auf die Gesamtzahl der Speichergeräte, die vor dem Starten des Arrays an den Server angeschlossen sein dürfen, ohne den USB-Stick auf dem Unraid OS installiert ist. 🔃 Die angeschlossenen Speichergeräte beziehen sich auf deren Gesamtzahl - außer dem USB-Stick auf dem Unraid OS installiert ist - die vor dem Starten des Arrays an den Server angeschlossen sein dürfen. oder Die angeschlossenen Speichergeräte beziehen sich auf deren Gesamtzahl, die vor dem Starten des Arrays an den Server angeschlossen sein dürfen. Der USB-Stick auf dem Unraid OS installiert ist wird dabei nicht mitgezählt. im Paritätsgeschütztem Array 🔃 im paritätsgeschütztem Array ➖ (nicht relevant für den deutschsprachigen Raum, wobei ich diese Erwähnung eh nicht verstehe, da eine allgemein Hilfe zum E-Mail-Whitelisten denke ich besser wäre) Bitte verwende keine comcast.net E-Mail Adresse um deinen Lizenzschlüssel zu erwerben. Solltest du ein Spezielles Angebot benötigen bitte Kontaktiere uns unter [email protected]. 🔃 (gehört außerdem in einen separaten Listenpunkt) Wenn du ein spezielles Angebot benötigst, erreichst du uns unter [email protected] oder Bitte kontaktiere uns unter [email protected], falls du ein spezielles Angebot benötigst. Alle Käufe sind Bindend. Keine Rückerstattung. 🔃 Alle Käufe sind bindend. Keine Rückerstattung. ➕ (extra allgemein gehalten) Im Forum helfen sich die Nutzer gegenseitig, auch in deiner Sprache. um die validität der Testlizenz zu überprüfen. 🔃 um die Validität der Testlizenz zu überprüfen. Eine verlängerung der Testlizenz um 15 Tage ist bis zu 2x möglich. 🔃 Eine Verlängerung der Testlizenz um 15 Tage ist bis zu 2x möglich. ➕ Dateien auf den Speichergeräten sind auch nach Ablauf der Testlizenz über ein geeignetes Betriebssystem (XFS bzw BTRFS Unterstützung) auslesbar. Die Seite "About" fehlt auf der deutschen Seite: https://unraid.net/about Mir ist wichtig, dass ich weiß wie das Unternehmen heißt und woher es kommt. Also ein kleiner Text mit einem Foto reicht da völlig. Man könnte ja problemlos die englische About-Seite verlinken, wenn man mehr über das Team erfahren möchte.

Kann ich nicht mal eben testen. Wie gesagt mein produktiver Server. Wenn Mal keine Aktivität ist, werde ich das noch mal testen. Einmal die .9 und dann auch mal die .10. Was könnte ich denn auf dem Server vor und nach der Änderung ausführen, damit ich debuggen kann, was hier eigentlich in die Hose geht? Also wenn es überhaupt an Unraid liegt.

Der VPN Container hat ja denke ich eine WebGUI. Und beim anderen Container kannst du es verifizieren, in dem du beim Klick auf das Icon nicht die WebGUI, sondern die Konsole öffnest und dann das ausführst: curl ifconfig.co oder curl ifconfig.me Dadurch wird dir die öffentliche IP des Containers angezeigt, die dann ja durch den VPN eine andere sein muss. Muss nicht. Jeder hat da seine eigenen Prioritäten. Nein. Erst ab 4000/5000 sparsam und die sind zu teuer. Außerdem gibt es große Hürden bei der iGPU. Mal eben für Plex zum Transcoding nutzen geht nicht. Außerdem nur mit der Beta Version nutzbar. Die Paritätsplatte verhindert den Datenverlust durch Defekt. Dadurch hast du aber noch kein Backup gegen Viren, versehentliches Löschen etc. Natürlich auch eine finanzielle Frage. Ich habe zb einen zweiten Server bei einem Freund stehen. Ansonsten eben externe USB Platten. Was man eben so bevorzugt. Erst wenn die Parität drin ist, wird die Geschwindigkeit sinken. Wobei es eine Turbo Write Option gibt, die schnelles Schreiben durch Aktivierung aller HDDs auch bei einer Parität ermöglicht. Bei wenig HDDs durchaus eine Option, die dir die SSD ersparen kann. Statt einer SSD ginge auch 64 bzw 128GB RAM und die Erhöhung des Schreibcaches auf 50 bis 75%. Dadurch wird der freie RAM dann für Uploads verwendet, der dann zeitversetzt auf die HDDs geschrieben wird. Also RAM Caching statt SSD Caching. Ist aber nur in Kombination mit einer USV empfehlenswert (sonst Strom weg = Daten aus dem RAM weg). Die SSD kann aber sinnvoll sein - und da kommen wir zur Größe - wenn du bestimmte Daten dauerhaft darauf ablegst wie zb die VM Festplatte oder Docker Container Daten. Ich habe zb auch meine komplette MP3 Sammlung darauf liegen (plus 1:1 Sync auf den HDDs), damit das Abspielen von Musik oder Hörspielen ohne Latenz geht und damit die HDDs gar nicht erst hochfahren müssen. Backups lasse ich dagegen direkt auf die HDDs kopieren, da ich inkrementell sichere und er eh auf die bereits gesicherten Daten der HDD zugreifen muss. Da hilft dann aber der RAM Cache. Also beides in Kombination bietet die beste Performance.

Ich starte ja mit einer funktionierenden Config, also mit der statischen .9 Gerade geschaut. Stimmt. Ist jetzt raus. Hat das aber überhaupt einen Einfluss auf den Fehler? Wenn man die Config löscht, dann ist das ja die Grundeinstellung. Nach der Änderung der eth0 auf die 10G Karte und dem Neustart, entferne ich das Bonding mit eth1 (was aber eh keine Verbindung hat). Bridging bleibt für Docker/VM an.

Dein gewählter Stick kostet 5 €. Ich denke da kann man sich problemlos einen zweiten in die Schublade packen oder nicht? Ich sage dir aber gleich, dass die Consumer 3.1 Sticks nicht für den Dauerbetrieb geeignet sind. Wenn man unbedingt 3.x haben will, sollte man sich einen teuren industrietauglichen SLC Stick holen. Aber bringen tut dir das eh nichts, weil er im Betrieb quasi irrelevant ist. Er dient nur dazu, dass deine gemachten Einstellungen und installierten Plugins nach einem Reboot wieder zur Verfügung stehen. Unraid läuft sonst durchgehend im RAM. Gar nicht. Wenn man die Schlüsseldatei auf den neuen Stick überträgt und die Lizenz an die GUID des neuen Sticks bindet, dann ist die Schlüsseldatei ja immer noch auf dem alten Stick vorhanden. Steckt man den nun in einen Server, der offline ist, dann kann dieser illegal weiterverwendet werden. Damit genau das nicht missbraucht wird, darf man nur 1x pro Jahr den USB Stick wechseln. Wobei der Support absolut kulant ist und auf Anfrage auch weitere Wechsel erlaubt. Also mach dir keinen Kopf, falls dir mal zwei Sticks in einem Jahr kaputt gehen. Man könnte das ausnutzen. Aber bringt schlechtes Karma und Heuschreckenplagen. ^^ Bei Unraid ist der Cache niemals flüchtig. Er ist ein normales Volume, was du optional nach x Stunden mit dem Mover leeren kannst. Die meisten Unraider nutzen den SSD Cache aber für viele Dinge persistent wie zb Docker oder VMs. Ich habe sogar meine komplette MP3 Sammlung darauf liegen, damit Hörspiele nicht unnötig die HDDs aufwecken. Das ist gänzlich anders als ein SSD Cache bei Syno, QNAP oder ZFS. Auf jeden Fall beim Booten. Da wird nämlich auch ein Fehler ausgegeben, dass keine Internetverbindung möglich ist, wenn man offline ist. Ist also transparent. Ob da die Lizenz abgeglichen wird? Keine Ahnung. EDIT: Ich habe mal den Support gefragt. Der hat das verneint. Ist also wirklich nur eine Prüfung ob eine Internetverbindung besteht.

Ja, nur dann. Danach gibt es nie mehr Probleme. Ist dran und wenn ich die IP auf statisch .9 ändere, dann kann ich über das Terminal auch nicht mehr den Router anpingen. QNAP QXG-10G1T

Mein DHCP Bereich startet bei .30 und der Server hat die .9 Nun lösche ich die Network Config und obwohl dadurch DHCP aktiv wird, behält der Server die .9 Dann ändere ich auf .9 statisch und der Server ist nicht mehr erreichbar. Beim letzten Mal als die erste 1G LAN Buchse noch nicht per vfio cfg ignorieren ließ, bekam der Server sogar mal die .66, aber als ich die 10G Karte auf eth0 stellte, erhielt der Server nach dem nächsten Neustart wieder die .9 (immer noch DHCP aktiv). Ich vermute die Fritz!Box gönnt der statischen IP auch eine lease time, wenn die MAC Adresse nun plötzlich den DHCP Server anfragt. Wenn ich das richtig sehe, muss ich das noch mal reproduzieren und beim nächsten Versuch ändere ich die IP auf .10 um die Fritz!Box als Ursache auszuschließen. Korrekt?

Ja das macht in jedem Fall mehr Sinn. Hier wird beschrieben wie man die iGPU in Plex nutzbar macht und ich denke das sollte auf Emby übertragbar sein: https://forums.unraid.net/topic/77943-guide-plex-hardware-acceleration-using-intel-quick-sync/ Hier hat jemand was zu Emby geschrieben, aber ich denke der hat zu viel eingestellt: https://forums.unraid.net/topic/83137-how-exactly-do-you-get-hevc-transcoding-exactly-cant-get-emby-to-work/

Ich habe bei mir eine Situation, die ich immer wieder nachstellen kann: 1.) Ich lösche /boot/config/network.cfg und /boot/config/network-rules.cfg und starte den Server neu. Das führt zum Reset the Netzwerkeinstellungen. Der Server holt sich also per DHCP eine IP. 2.) Ich ändere die Reihenfolge meiner Netzwerkkarten so, dass meine 10G Karte eth0 erhält (Settings > Network > Interface Rules) und starte den Server neu. 3.) Ich ändere die IP von DHCP auf statisch und behalte die IP aber bei (Settings > Network > Interface eth0). Und das war es dann. Der Server ist nicht mehr erreichbar. Ich kann ihn von meinem Client auch nicht mehr anpingen. Erst wenn ihn noch mal neu starte, gilt die eingestellte statische IP. Da ich den Server produktiv einsetze, kann ich das nicht genauer untersuchen. Ich wollte mal fragen ob das andere auch schon erlebt haben bzw ob das eher an meiner 10G Karte liegen könnte? So rein vom Gefühl her ist das ein Bug in Unraid.

Gerne. Gib auf jeden Fall Feedback wie das Case so ist. Würde das dann gerne grundsätzlich für mATX weiterempfehlen.

Unraid nimmt sich immer die primäre GPU, egal ob du im GUI Modus bootest oder nicht. Ich habe das noch nie gemacht, aber wie ich vorgehen würde: Settings -> VM -> Advanced -> PCIe ACS override -> Both -> Server neu starten, Das bringt alle PCI Geräte nun in eigene IOMMU Gruppen Apps -> VFIO-PCI CFG installieren Settings -> VFIO-PCI CFG -> die Adresse / Gruppe der iGPU anklicken -> Build VFIO-PC.CFG -> SAVE -> Server neu starten, Unraid ignoriert nun die ausgewählten Geräte beim Neustart und installiert entsprechend auch keine Treiber dafür (das Plugin erstellt übrigens einfach nur die Datei "/boot/config/vfio-pci.cfg", wenn man die Datei löscht, ist alles beim alten) VM editieren und iGPU auswählen VM starten und Treiber installieren. Bitte beachte, dass das eigentlich nicht so in Unraid vorgesehen ist, denn sobald du die iGPU an eine VM durchschleifst bzw mit der oben genannten Methode von Unraid ignorieren lässt, kann die iGPU von keiner anderen Anwendung mehr verwendet werden. Dh kein Unraid GUI Mode und kein Container, der zB die Videofunktionen der iGPU benötigt wie zB Plex/Jellyfin/Emby. Eventuell macht es mehr Sinn sich für eine VM eine kleine dedizierte GPU zu holen (GT 710, GT 1030 oder GTX 1050 Ti).

Jo auf den C246 Chipsatz passen alle 1151v2 und sogar Xeon. Hier günstig als B-Ware: https://m.computeruniverse.net/de/gigabyte-c246m-wu4-mehlow-c246-up-bware-6?agt=1741&awc=11355_1607524904_7ecbe5f70884666657f42133229656e3 Und hier neu auch günstig: https://m.alza.de/gigabyte-c246m-wu4-d5756768.htm?country=DE&language=en&kampan=adw_alza_pla_all_alza_produkty_m_9044662_GBC426a2&gclid=CjwKCAiAiML-BRAAEiwAuWVggvLjW_ik4uFtLZ57bQohuMYoSymwHAfMJXmmiIaVOorOO1qn3yHMDRoC4ksQAvD_BwE