Leaderboard

Yes, the parity array is great for mass storage, very bad for random I/O, especially random writes. SSD or NVME is a must for vdisks.

Ich hab dies hier dazu gefunden. https://github.com/openzfs/zfs/discussions/15447

Jesus, this took me a couple hours to troubleshoot.... I couldn't figure out what you were talking about by adding a second video card. Theres a tiny easily missed plus button to add more cards in the VM settings: I kept getting a Guest not initialized error, so had to go into XML view (top right of VM settings), and switch the bus to 0 from 7: to It gave me an error for slot 1 so I switched it to slot 2. I have to manually edit this every time I change a setting. Anyone know a fix? Now I can start the VM using VNC in unraid, as well as by using remote viewer of your choice. Was having a hell of a time getting Nvidia drivers installed, had to go back and forth to VNC like 15 times. Now I have the VNC drivers and Nvidia drivers installed and showing up in device manager. Now even loads Star Citizen which was my entire reason for making this VM. Edit: After a single restart the VM keeps losing the Nvidia drivers (device manager has question mark). Nvidia control panel wont open. Task manager doesnt have a GPU tab even right after reinstalling the gpu driver (and shows up in device manager). anymore.

I just wanted to post an update about my progress with 1.5.5. It was a busy weekend but I did get a chance to work on it. I ran into an issue that I'm trying to figure out but I think I'll be able to get it out before week's end.

@emilgil env variable in the template. 20 000 should be 20 seconds Also you are running the tag 6.11 with unraid 6.12. They have to match

Honestly, Unraid is good so far. I've been using Windows Server for years but after doing some research for my home NAS I came across TrueNAS Core, TrueNAS Scale, UNRAID, OpenMediaVault, etc. I decided to give one of these dedicated NAS operating systems a shot. I decided on UNRAID as it was supposed to have the most user friendly experience of the options. Not sure I'd call any of them user friendly on hindsight. TBH I hadn't touched linux since 2002/2003 and was... rusty... to say the least. But when I think of 'User Friendly' I think of the general computer user, not experienced computer hobbyists/professionals. I want to purchase UNRAID but man the price is killing me. I've got 11 devices attached so I'm already looking at the 'Unleashed License' for $109 +tax etc., but that only comes with updates for a year. After that year what happens? Does my system slowly march towards becoming a useless brick when all the Docker/VM support moves forward without me? So, then I think maybe the better option would be the 'Lifetime License' at $249 +tax etc. for the lifetime updates. But holy crap... $250 for NAS software? I can get a Windows Server 2019 key for $16 +tax with support for YEARS and YEARS. Admittedly, UNRAID has better/different features but not $230 dollars worth ffs. I could just run BTRFS on Windows and be basically there. So there is my dilemma. Now here are the core questions; -What happens after the '1 year' of updates to your system? Would I have to purchase another $109 +tax 'Unleashed License' to get updates? -Does UNRAID ever go on sale? -Does anyone got a discount code or something? -If everything else fails, should I just go back to Windows Server? Is there something else I should try before giving up?

Kannst du mehr Details nennen? Hersteller/Modell/Größe?

Hi, it seems that solves the issue (and more 2x to 3x fastest in transfert). Thanks

Was habt ihr den für Sticks bzw. was macht ihr damit? Ich hatte ebenfalls noch keine Probleme mit meinen. Es gab/gibt ne gefälschte Charge? von Sandisk Sticks vor denen von Unraid auch gewarnt wurde/wird. Falls ihr einen davon erwischt habt, kann es durch aus sein, das die deshalb blacklisted sind.

here you will find some answers: https://unraid.net/blog/new-pricing

Ganz genau. Time Machine erzeugt ja ein Sparsebundle. Ich denke, das würde mit Cache zu Problemen führen. https://de.wikipedia.org/wiki/Apple_Disk_Image

or start watching 'linux isos'

Safe mode held for 24 hours then crashed. Started ruling out hardware but first decided to reset my bios. Seems maybe power settings were the culprit, for now it's holding like normal but I'll see.

Thank you @ijuarez And good morning (at least where I am located) I made sure not to share cores and HT's. I am about to re-attempt another WIN-11 install as well. Will come back with results. I also D/L Windows 11 Lite. Will use that if all else fails. NOTE: You may receive a message that says: This PC can’t run Windows 11. You probably already know this but there is a Fix for that

I am trying now with a debian install, will try with windows 11 , for me, debian is pretty snappy on the array. However windows 11 was just dog slow and I gave up. It looks like your giving the vm 8 cores 8 HT are you possible using the same cores for other vms that are running at the same time?

Sieht nach einem beschädigtem USB-Stick aus, und nicht der Festplatte. Er hat hat da ein paar Error beim Device /sda das sollte der Stick sein.

It worked. Thank you so much!

Nach einem Neustart und dem Verschieben des libvirt.img auf Cachenvme ist es mir nun gelungen die erste VM mit Windows 10 zu installieren. Die Freigaben Domains und Isos sind auch auf Cachenvme ausgelagert und soweit laufen die Disks im Arry beim Ausführen der VM auch nicht an In der VM selbst hänge ich nun zwar mit dem Code 56 fest (Netzwerk Treiber), dass ist aber eine andere Baustelle. Woran es nun genau lag, kann ich nun gar nicht mehr sagen. Danke für deine Hilfe @saber1

Aktuell wird bei ATX Netzteilen ja gerne das bequiet 12M genannt (auch von mir). Da ich es selber noch nicht hatte und mich da auch auf Beiträge Anderer bezogen habe, dachte ich mir, daß ich es wirklich doch mal selbst messen sollte. Also habe ich einen Händlergutschein benutzt um das Ding minimal unter Preis zu ordern. Es wurde mir geliefert: be quiet Pure Power 12 M 550W ATX 3.0 (BN341). Ich bin zwar etwas über die Verkabelung der Modularkabel verwundert (4+4pol CPU Steckverbinder ist irgendwie komisch), aber okay. Also messe ich es mal gegen meine aktuell meist hergenommene Inter-Tech (pico Nachbau) Versorgung. Hardware und Beschaltung: - Gigabyte B760M DS3H DDR4 (BIOS/UEFI: 2023-11-09 F16b) (BIOS auf Default und dann die unten im Bild 1 erkennbaren Abweichungen eingestellt). (Im BIOS die CPU und PCH Geschwindigkeit auf PCIE 3.0 reduziert! - Intel I3-12100 boxed (incl. Intel boxed CPU Kühler) - 2x 16GB DDR4-3200 Mushkin Essentials (MES4U320NF16) - kein SATA - interne Netzwerkkarte (Realtek RTL8125BG) 1GBLan Link aktiv - PCIe 4.0 x16: leer - M.2 NVME Slot neben CPU: leer - 1. PCIe 3.0 x1: leer - 2. PCIe 3.0 x1: leer - M.2 NVME Slot (Chipsatz) am Ende des Mainboard: leer - USB Bootstick: Transcend Jetflash 600 32GB - USB 2.0 Y-Verteiler (Chinaware): USB_SanDisk_3.2 Gen1 32GB als einzige Disk im Array (weil sich unraid sowieso ja nur mit Array vollständig nutzen läßt). Array mit Autostart, damit es immer gleich ist und ich nach einem Reboot für die Tests nicht erst ins WebGUI zum Starten gehen muß. Unraid hat alle Systemshares automatisch auf die USB Stick gelegt (weil ich ja keinen Pool/Cache-SSD eingebunden habe) und damit den USB Stick schon mit 28GB von den vorhandenen nominal 32GB belegt. Software: unraid 6.12.4 stable (weil ich keine Lust habe mich nur für diese Tests mit manuellen ASPM Einstellungen rumzuschlagen. Ich weiss da weiterhin noch nicht so ganz, was ich da wirklich tue und will nicht durch Hardwareveränderungen wieder die passenden 'setpci' parameter rausfummeln.) Community App nerdtools + powertop-2.15-x86_64-1.txz Dynamix Cache Dirs Dynamix File Manager Dynamix System Temperature Unassigned Devices Unassigned Devices Plus Unassigned Devices Preclear im Go File: powertop --auto-tune alle tunables stehen auf "Good" WebGUI und Terminal geschlossen, idle, der Bildschirmschoner hat den angeschlossenen HDMI Ausgang nach rund 15 Minuten schwarz geschaltet (das spart hier noch mal rund 1W, deshalb warte ich mindestens diesen 'Bildschirmschoner' ab). Ferngesteuert per ATEN 8600 KVM over IP an HDMI und USB2.0 Messungen wieder mit AVM DECT200 Funksteckdose. Messung 1: Stromversorgung - Inter-Tech Mini-ITX PSU 160W, Wandlerplatine (88882188) 12V Input (aktuell ca. 15 Euro) - Leicke ULL 156W Netzteil 12V 13A 5,5 * 2,5mm (aktuell habe ich es nur bei Amazon für nun fast 50 Euro gefunden) Keine Überraschung, das nackte System geht wieder auf knapp unter 10W runter, welche ich in der Vergangenheit auch schon des öfteren so gemessen habe. Siehe Bild 1 unten. Messung 2: Stromversorgung - be quiet Pure Power 12 M 550W ATX 3.0 (BN341) (aktuell so um 83 Euro) Und wie zu vermuten war: auch hier werden Werte unter 10W erreicht, wodurch es im Rahmen der Meßgenauigkeit bei dieser Niedrigstlast genau so gut, wie die Inter-tech Lösung ist. (BIld2) Nur hat man bei Bequiet mehr Reserve und auch Anscxhlüsse, wenn es eben doch mehr Festplatten werden sollten. BIld 1: Inter-Tech Netzteil mit Leicke: Bild 2: BN341 Netzteil

Need to chown -R nobody:users /path/to/anythingllm dir and then do the newperm command . Well that fixed it for me.

Yes, I'm using ECC memory. Ok, then I"ll start a third run. Will report in 24h about the result. Thanks for looking into it!

SMART test passed so the disk should be OK for now, keep monitoring, you can also replace/swap cables to rule that out if more errors occur.

Oh I see. Thanks for the update!

I can do this tomorrow, restoring some old hw. btw thanks you in the meantime

This is awesome, thanks

Hallo Amane, vielen Dank, sehr nett von dir. Ich hab das mal jetzt so eingefügt und es gab keine Fehlermeldung. Wenn morgen die 24h rum sind, sehe ich ob die von mir erstellte Datei dann gelöscht wird. Zusätzlichen Dank auch an ich777 und Archonw.

Hab es hinbekommen, vielen Dank! 1. Appdata SSD in XFS formatiert. 2. Docker Dienst beendet 3. Share appdata neu erstellt 3. Docker Dienst gestartet 4. Docker über die User Templates neu heruntergeladen / erstellt 5. appdata aus Backup rüberkopiert auf die SSD 6. Docker Dienst gestartet Jetzt passt alles wieder, danke dir @alturismo

Hi All, Thank you so much for your help and suggestions. I played around with THE BIOS settings as you all recommended and it turns out the culprit was the Bios setting "USB transfer time out.". By default, it was 20 seconds but I changed it to 10 seconds and somehow I am able to access the Webgui now.... I can't believe it was that little change that made the impact and was the source of my problem and headache. For my information, does anyone know what this usb transfer time out means and why it was the source of my trouble? In any event, much appreciative to you for taking the time looking at issues and trying to help and thank you for pointing me in the right direction!

I installed bacula with postegresql except that I don't know why but it can't find the host of the IP database (both are on the same networks) so after that I deleted everything and installed with sqlite3. Installation that works but did not take into account the following variables : -WEB_User -WEB_Password After launching the container I access the dashboard with a 101-curl error. I check the internal conf files and it turns out that the user was admin and the password was difficult. So the variables are not taken into account as I mentioned above.

Quick question. I have removed my gpu as I do not needit anymore. Removed the gpus all and device object from the container config. All working fine. I have an amd 3400g. Will it use the integrated graphics of this cpu automatically or do I need to add an extra parameter? error-gpu There was an error getting usage stats. This does not mean hardware acceleration is not working. Either your GPU does not support this or Frigate does not have proper access to get statistics. This is expected for the Home Assistant addon. UPDATE: Fixed. Added variable radeonsi amd-vaapi GPU %Memory % 2.50%19.27%

So after running both the Coral with 12th Gen Intel QSV and Nvidia Quadro RTX 4000 for Frigate processing for some time, the Coral/Intel setup significantly uses less power and generates much less heat than the Nvidia method. Overall, this resulted in 100watt less power usage and Quadro RTX 4000 is no longer running a constant 60C. Unrelated to unRAID but kind of wondering how the HA Yellow/RP4 would handle Frigate with Coral attached, I know others are doing it but just unsure about how many cameras and what not they are able to handle.

To reduce wear on your SSD this script moves your docker status and log files into your RAM. This script syncs every 30 minutes the RAM content to your SSD to reduce loss of log files. Paste the following script in your /boot/config/go File on your usb flash drive or create a script with the user scripts plugin which gets only executed on first array start (check the unraid version info in the script, maybe it was updated some pages later): Use the execute in the background button, to install the script the very first time. Now go to settings > docker and set docker to "no" and then to "yes" again. How it works Docker service is started - It creates the path /mnt/<path_to_your_docker_data>/containers_backup - It copies all files from /var/lib/docker/containers to /containers_backup - It creates a RAM disk /var/lib/docker/containers (on top of the already existing path, so the already existing path is not deleted) - It copies all files from /containers_backup back to the now empty RAM disk /var/lib/docker/containers Docker service is stopped - Reverses steps from before Every 30 minutes - It creates the path /var/lib/docker_bind - It mounts the path /var/lib/docker to /var/lib/docker_bind (this trick allows us to access the local path /var/lib/docker/containers) - It copies all files from the RAM Disk /var/lib/docker/containers to /var/lib/docker_bind/containers (which is the local /var/lib/docker/containers path) Reduce RAM Usage If you fear to much RAM usage, you can change your docker settings as follows: By that each container can only create a single log file which is limited to 50 MB. How much RAM is used Usually less then 512 MB: # df -h /var/lib/docker/containers Filesystem Size Used Avail Use% Mounted on tmpfs 32G 369M 31G 2% /var/lib/docker/containers Does it really help? For me it made a huge change (most of the time absolutely no writes on my SSD). But read the reactions of other users: https://forums.unraid.net/bug-reports/stable-releases/683-unnecessary-overwriting-of-json-files-in-dockerimg-every-5-seconds-r1079/?do=findComment&comment=15472

Thanks for clarifying It would be great to have this documented much more clearly/prominently and explicitly, since in other places IIRC parallels are/were drawn between the prior concepts of 'cache' and 'main unraid array' as 'pools'. If that were the case, then what I was originally trying to do ought to have been possible

Like mentioned it's not possible, you can use a disk share.

No you cannot do that since the array is inherently not a exclusive share. Only works for pool devices. You might wanna look into disk shares

Hey zusammen, sollte jemand aktuell auf das Thema stoßen nutzt bitte die neue Methode. Diese in Kürze: Backup des aktuellen Sticks über die GUI oder regelmäßig über das Backup plugin. USB Creator von der unraid Seite laden und öffnen Statt stabel wählt ihr local und wählt dort die zip Backup Datei Neuen Stick rein, beschreiben fertig. cheers

Ursachen Wer einen SSD Cache einsetzt, hat evtl schon festgestellt, dass er permanente Schreibzugriffe auf der SSD hat. Es gibt dafür verschiedene Ursachen: Write Amplification Das bedeutet es wird mehr auf das Laufwerk geschrieben als die Daten eigentlich groß sind und das liegt daran, dass der festgelegte Datenblock größer ist als die Daten selbst oder es werden je nach Dateisystem zusätzliche Informationen wie Prüfsummen, Metadaten oder Journaling gespeichert, die eine hohe Amplification resultieren können. Healthcheck Wenn ein Container diese Funktion besitzt, schreibt er alle 5 Sekunden (!) in die Dateien "/var/lib/docker/containers/*/hostconfig.json" und "/var/lib/docker/containers/*/config.v2.json". Diese ermöglicht den "healthy", "unhealthy" oder "health: starting" Status in der Docker Übersicht: Mir bekannte Container, die das nutzen sind zB Plex, Pi-Hole oder der Nginx Proxy Manager. Container Logs Über die Logs eines Containers können wir sehen was er gerade macht. Manche Container schreiben sehr viel in "/var/lib/docker/containers/*/*-json.log". Ich hatte zB schon eine 500MB große Log-Datei bei Plex Interne Logs oder temporäre Dateien Innerhalb eines Containers können ebenfalls Logs oder temporäre Dateien erstellt werden. zb schreibt der Nginx Proxy Manager im Pfad /var/logs ständig in Log-Dateien oder der Unifi-Controller ständig in /tmp temporäre Dateien. Mit dem folgenden "find" Kommando können wir uns alle Dateien ausgeben lassen, die durch Container oder dem Docker Dienst geschrieben werden: find /var/lib/docker -type f -not -path "*/diff*" -print0 | xargs -0 stat --format '%Y:%.19y %n' | sort -nr | cut -d: -f2- 2> /dev/null | head -n30 | sed -e 's|/merged|/...|; s|^[0-9-]* ||' Es listet die 30 zuletzt geänderten Dateien auf. Wiederholt man das Kommando, dann sieht man schnell welche Dateien (teilweise im Sekundentakt) immer wieder aktualisiert werden: 09:36:29 /var/lib/docker/containers/*/hostconfig.json 09:36:29 /var/lib/docker/containers/*/config.v2.json 09:12:45 /var/lib/docker/containers/*/*-json.log 09:12:34 /var/lib/docker/overlay2/*/merged/tmp/*.log 09:12:34 /var/lib/docker/overlay2/*/merged/var/log/*.log ... 09:12:34 /var/lib/docker/btrfs/subvolumes/*/var/log/*.log Gegenmaßnahmen Was können wir nun dagegen tun: Docker vom docker.img auf "Directory" umstellen (ja, "/docker/docker/" ist richtig!): Damit reduzieren wir schon mal die Write Amplification, da das Schreiben einer kleinen Zeile in eine log/json-Datei mehr Datenblöcke im docker.img ändern kann, als das beim direkten Zugriff auf die Datei der Fall ist. Hinweis: Dadurch werden alle Custom Networks und Container gelöscht. Diese können dann einfach (ohne Datenverlust) über Apps > Previous Apps wieder installiert werden (Custom Networks müssen natürlich vorher neu erstellt werden! Geht übrigens auch per Kommandozeile) Bonus: Wer den Share "system" beim Cache auf "Prefer" gestellt hat, der sollte auch gleich den Pfad auf /mnt/<cache-pool-name>/docker/docker ändern. Grund: Die CPU wird bei /mnt/user... mehr belastet. Optional: Ist das erledigt und setzt man nur eine SSD ein, sollte man außerdem über den Wechsel von BTRFS zu XFS nachdenken, da XFS eine deutlich kleinere Write Amplification besitzt. Das ginge so: Alle Shares beim Cache von "Prefer" auf "Yes" stellen, Docker & VM Service auf "No", Mover starten, SSD sichten ob sie wirklich leer ist, SSD umformatieren, alle geänderten Shares beim Cache zurück auf "Prefer", Mover starten, HDD sichten ob sie wirklich leer ist, Docker & VM Service auf "Yes". Wir ändern über die Go-Datei den Unraid Code, so dass automatisch eine RAM-Disk vom Pfad /var/lib/docker/containers erstellt wird, in dem die healthcheck-Dateien liegen. Alternativ: Bei allen Containern mit "healthy" status folgendes einstellen (siehe auch unten) Wir ändern über die Go-Datei den Unraid Code, so dass automatisch eine RAM-Disk vom Pfad /var/lib/docker/containers erstellt wird, in dem die Container Logdateien liegen. Alternativ: Bei allen Containern die Container Logs umlenken: oder deaktivieren: Was wann gebraucht wird, erfahrt ihr hier. Um die Aktivitäten innerhalb der Container ermitteln zu können, müssen wir wissen welcher Container in welchen Pfad schreibt. Das oben genannte "find" Kommando hat zB diesen Pfad ausgegeben: /var/lib/docker/overlay2/b04890a87507090b14875f716067feab13081dea9cf879aade865588f14cee67/merged/tmp/hsperfdata_abc/296 rgendein Container schreibt also in den Ordner "/b04890a875...". Mit diesem Kommando finden wir heraus welcher das ist: csv="CONTAINER;PATHS\n"; for f in /var/lib/docker/image/*/layerdb/mounts/*/mount-id; do subid=$(cat $f); idlong=$(dirname $f | xargs basename); id="$(echo $idlong | cut -c 1-12)"; name=$(docker ps --format "{{.Names}}" -f "id=$id"); [[ -z $name ]] && continue; csv+="\n"$(printf '=%.0s' {1..20})";"$(printf '=%.0s' {1..100})"\n"; [[ -n $name ]] && csv+="$name;" csv+="/var/lib/docker/(btrfs|overlay2).../$subid\n"; csv+="$id;"; csv+="/var/lib/docker/containers/$idlong\n"; for vol in $(docker inspect -f '{{ range .Mounts }}{{ if eq .Type "volume" }}{{ .Destination }}{{ printf ";" }}{{ .Source }}{{ end }}{{ end }}' $id); do csv+="$vol\n"; done; done; echo ""; echo -e $csv | column -t -s';'; echo ""; In meinem Fall ist das der "unifi-controller": Außerdem prüfen wir genau in welchen Unterordner der Container geschrieben hat: /merged/tmp/hsperfdata_abc/296 Das "/merged" (oder auch "/diff") kann man ignorieren. Der Pfad des Containers beginnt also mit "/tmp". Diesen Pfad können wir normalerweise bedenkenlos in eine RAM-Disk packen, da bei Debian, Ubuntu und Unraid das bereits von Haus aus eine RAM-Disk ist und Anwendungen in der Regel ja auch auf diesen Betriebssystemen laufen. Aber Achtung: Falls ihr einen anderen Pfad ermittelt habt, darf dieser in der Regel nicht in eine RAM-Disk verlagert werden, da dass zum Datenverlust im Container führen kann! Wir öffnen nun also die Einstellungen des ermittelten Containers, scrollen nach unten und wählen "Add another Path...": Nun tragen wir "/tmp" beim "Container Path" ein und "/tmp/<containername>" beim "Host Path": Sobald ihr nun den Container startet, schreibt der Container nicht mehr in "/var/lib/docker/.../tmp", also auf eure SSD, sondern in "/tmp/unifi-controller" und damit in die RAM-Disk von Unraid. Nachdem das getan ist, wiederholen wir das "find" Kommando erneut und vergleichen noch mal die Ergebnisse: 2021-08-18 10:06:36.256939658 +0200 /var/lib/docker/containers/*/hostconfig.json 2021-08-18 10:06:36.256939658 +0200 /var/lib/docker/containers/*/config.v2.json 2021-08-18 09:49:32.698781862 +0200 /var/lib/docker/containers/*/*-json.log Die Schreibzugriffe auf die "/tmp" Ordner sind nun alle verschwunden, da wir diese in die RAM-Disk von Unraid ausgelagert haben. Die Schreibzugriffe auf /var/lib/docker/containers sehen wir zwar noch (außer ihr verwendet die --no-healthcheck/--log-driver Lösung, dann werden auch diese verschwunden sein), können diese aber ignorieren, da wir dafür über die Code-Änderung eine RAM-Disk ergänzt haben. Zur Belohnung genießen wir dann mal keine Schreibzugriffe auf unserem Cache 😁 Pedanterie Eventuell stellt ihr fest, dass trotzdem noch Daten auf die SSD geschrieben werden und nun wollt ihr es genau wissen. In diesem Fall lohnt es sich das "find" Kommando so anzupassen, dass ihr euch die neuesten Dateien in einem "appdata" Share anzeigen lasst: find /mnt/cache/appdata -type f -print0 | xargs -0 stat --format '%Y :%y %n' | sort -nr | cut -d: -f2- | head -n30 In meinem Fall kam das dabei heraus und ich habe auch gleich mal eingekreist, was man optimieren könnte (auf eigene Gefahr, versteht sich): Da der Nginx-Proxy-Manager bereits eine RAM-Disk für /tmp benötigte, habe ich dann entschieden auch /data/logs in eine RAM-Disk zu packen, so dass ich es schlussendlich so gelöst habe: Den Pfad vom Unifi-Controller habe ich gelassen, da der letzte Schreibzugriff bereits vor mehreren Minuten erfolgte, so dass ich keinen Verschleiß der SSD befürchte. Ich habe dann ein paar Minuten gewartet und das Kommando wiederholt und tatsächlich ist mir dann noch was aufgefallen: 1.) Der Zerotier Container schreibt alle 30 Sekunden in eine conf-Datei, was mich nervt, aber nachdem ich die Datei versucht habe zu öffnen und nur Binärdaten darin enthalten sind, lasse ich davon erstmal die Finger. 2.) Der Unifi-Controller schreibt ständig in haufenweise Datenbank-Dateien. Diese sind natürlich für den Betrieb des Containers notwendig, weshalb wir daran nichts ändern können. Da mich aber die Statistiken von Unifi eh nicht interessieren, lasse ich den Container wie gehabt abgeschaltet. Ich aktiviere den nur, wenn ich etwas an den Access-Points ändern möchte. Alternativ könnte man überlegen ein Script zu schreiben, dass /mnt/cache/appdata/unifi-controller in eine RAM-Disk packt und regelmäßig den Container stoppt, die RAM-Disk sichert und dann wieder startet. Den Aufwand spare ich mir aber. 3.) Der Plex-Container schreibt alle paar Minuten in eine Log-Datei, was ich aber akzeptabel finde.

Hello All! As I'd alluded to in my earlier SR-IOV guide, I've been (...slowly...) working on turning my server config/deployment notes into something that'd at least have the opportunity to be more useful to others as they're using UnRAID. To get to the point as quickly as possible: The UnRAID Performance Compendium I'm posting this in the General section as it's all eventually going to run the gambit, from stuff that's 'generically UnRAID', to container/DB performance tuning, VMs, and so on. It's all written from the perspective of *my* servers though, so it's tinged with ZFS throughout - what this means in practice is that, while not all of the information/recommendations provided will apply to each person's systems, at least some part of them should be useful to most, if not all (all is the goal!). I've been using ZFS almost since it's arrival on the open source scene, starting back with the release of OpenSolaris back in late 2008, and using it as my filesystem of choice wherever possible ever since. I've been slowly documenting my setup as time's gone on, and as I was already doing so for myself, I thought it might be helpful to build it out a bit further in a form that could be referenced by others (if they so choose). I derive great satisfaction from doing things like this, relishing the times when work's given me projects where I get to create and then present technical content to technical folks... But with the lockdown, I haven't gotten out much, and work's been so busy with other things, I haven't much been able to scratch that itch. However, I'm on vacation this week, and finally have a few of them polished up to the point that I feel like they can be useful! Currently guides included are (always changing, updated 08.03.22): The Intro Why would we want ZFS on UnRAID? What can we do with it? - A primer on what our use-case is for adding ZFS to UnRAID, what problems it helps solve, and why we should care. More of an opinion piece, but with some backing data enough that I feel comfortable and confident in the stance taken here. Also details some use cases for ZFS's feature sets (automating backups and DR, simplifying the process of testing upgrades of complex multi-application containers prior to implementing them into production, things like that). Application Deployment and Tuning: Ombi - Why you don't need to migrate to MariaDB/MySQL to be performant even with a massive collection / user count, and how to do so Sonarr/Radarr/Lidarr - This is kind of a 'less done' version of the Ombi guide currently (as it's just SQLite as well), but with some work (in progress / not done) towards getting around a few of the limitations put in place by the application's hard-coded values Nextcloud - Using nextcloud, onlyoffice, elasticsearch, redis, postgres, nginx, some custom cron tasks, and customization of the linuxserver container (...and zfs) to get highly performant app responsiveness even while using apps like facial recognition, full text search, and online office file editing. Haven't finished documenting the whole of the facial recog part, nor elasticsearch. Postgres - Keeping your applications performance snappy using PG to back systems with millions of files, 10's or even hundreds of applications, and how to monitor and tune for your specific HW with your unique combination of applications MariaDB - (in progress) - I don't use Maria/MySQL much personally, but I've had to work with it a bunch for work and it's pretty common in homelabbing with how long of a history it has and the dev's desire to make supporting users using the DB easier (you can get yourself in a whole lot more trouble a whole lot quicker by mucking around without proper research in PG than My/Maria imo). Personally though? Postgres all the way. Far more configurable, and more performant with appropriate resources/tuning. General UnRAID/Linux/ZFS related: SR-IOV on UnRAID - The first guide I created specifically for UnRAID, posted directly to the forum as opposed to in github. Users have noted going from 10's of MB/s up to 700MB/s when moving from default VM virtual NIC's over to SR-IOV NICs (see the thread for details Compiled general list of helpful commands - This one isn't ZFS specific, and I'm trying to add things from my bash profile aliases and the like over time as I use them. This one will be constantly evolving, and includes things like "How many inotify watchers are in use... And what the hell is using so many?", restarting a service within an LSIO container, bulk downloading from archive.org, and commands that'll allow you to do unraid UI-only actions from the CLI (e.g. stop/start the array, others). Common issues/questions/general information related to ZFS on UnRAID - As I see (or answer) the same issues fairly regularly in the zfs plugin thread, it seemed to make sense to start up a reference for these so it could just be linked to instead of re-typing each time lol. Also includes information on customization of the UnRAID shell and installing tools that aren't contained in the Dev/Nerdpacks so you can run them as though they're natively included in the core OS. Hosting the Docker Image on ZFS - squeezing the most performance out of your efforts to migrate off of the xfs/btrfs cachepool - if you're already going through the process of doing so, might as well make sure it's as highly performant as your storage will allow You can see my (incomplete / more to be added) backlog of things to document as well on the primary page in case you're interested. I plan to post the relevant pieces where they make sense as well (e.g. the Nextcloud one to the lsio nextcloud support thread, cross-post this link to the zfs plugin page... probably not much else at this point, but just so it reaches the right audience at least). Why Github for the guides instead of just posting them here to their respective locations? I'd already been working on documenting my homelab config information (for rebuilding in the event of a disaster) using Obsidian, so everything's already in markdown... I'd asked a few times about getting markdown support for the forums so I could just dump them here, but I think it must be too much of a pain to implement, so github seemed the best combination of minimizing amount of time re-editing pre-existing stuff I'd written, readability, and access. Hope this is useful to you fine folks! HISTORY: - 08.04.2022 - Added Common Issues/general info, and hosting docker.img on ZFS doc links - 08.06.2022 - Added MariaDB container doc as a work-in-progress page prior to completion due to individual request - 08.07.2022 - Linked original SR-IOV guide, as this is closely tied to network performance - 08.21.2022 - Added the 'primer' doc, Why ZFS on UnRAID and some example use-cases

Iooks like it was usb controller amd You just need to remove the 0a.:0.3 entry from the file. remove 0000:0a:00.3|1022:145f from /boot/config/vfio-pci.conf and it should be fine next reboot.

I can't recall exactly but I think in my case it also happened if I completely powered down the server, the only way to make the USB drive boot again was to change it to another port, let's see what @Austin Detzel says. I also recall that it was not a problem related to Unraid or its booting drive. To isolate the problem I tried with other booting systems (Ubuntu and PassMark's Memtest) and I had the same problem, they would boot fine the first time but they would refuse to boot again unless I changed the USB drive to another port. By the way, this seems to be a known issue: I vaguely remember something about Fast Boot so I would recommend @Austin Detzelto test the following (in order): 1. Disable "Fast Boot" and try again 2. If that doesn't work, in "Settings > Advanced > USB Configuration" set "XHCI Hand-off" to "Disabled" and "Legacy USB Support" to "Auto" and try again 3. If it still doesn't work, try to tweak the booting options to enable UEFI booting/Secure Boot and be sure that you're booting the Unraid USB drive in UEFI mode (rename "EFI-" folder to "EFI"). I can't restart my server right now because I'm rebuilding Parity but if you still have problems let me know and I will check what my settings are in the BIOS so you can compare and see if copying them solves your problem.

I was having this error and disabling docker during setup worked. Perhaps you have a docker messing with the network settings? Did you try a different browser?

I'm surprised by these questions given your 1k+ posts. Create vdisk on the mounted UD. UD mounts are under /mnt/disks/[mount name]. Mount name can be found (and changed) on the UD screen on the Main page. Don't preclear SSD. Poor thing just wasted write cycles.

Hey, I know this is way late to the party, but I had the same issue as OP - initially. However, I looked and saw the "qxldod" folder and that worked for me. I was able to get 1920 x 1080. It seems the "qxl" folder doesn't contain Win 10 drivers. I hope this helps!

Unassigned Devices does not participate in standard Unraid shares. However if the device is mounted then there is a ‘share’ toggle against the drive that can be used to share out the whole drive as a single share.

Make sure the GUI is whitelisted if you are running an adblocker and/or is permitted when using an anti-virus software. You can also try another browser or system to see if the problem persists.

Diese Stick - Lizenz Lösung ist viel zu anfällig. Hätte ich das vorher schon mal gelesen, hätte ich auf unraid verzichtet. Hab seit Tagen mal wieder Fehlermeldungen.... der Support reagiert gar nicht. Dann verzichte ich auf die Connect Anbindung.

So neuen Stick lt. erstellt. Aber nun kommt das.... .... was jetzt? Lizenz Erwerben?..... Nö habe ich ja Aktivierungscode einlösen... ja wenn ich einen hätte 🙂 Warum kann es nicht einmal Einfach sein, aber so ich das Leben, also mal warten, was der Support schreibt 🙂 Und was ich grade sehe, der Stick wurde im Juli 23 Aktiviert, könnte sein das der auch schon mal Defekt war, ich kann mich aber nicht erinnern, wie ist das nun, in darf in 12 Monaten nur einmal den Stick tauschen.. oder? also erst im 2 Monaten... LOL