Leaderboard

I started my unraid journey in october 2019 trying out some stuff before i decided to take the plunge and buy 2 licences (one for backups and one for my daily use). I am working with IT and knowing how much noise rack equipment makes at work i had no plans what so ever to go that route. My first attempt at an unraid build was using a large nanoxia high tower case where i could at max get 23 3.5mm drives into, but once i reached around 15 drives the tempratures started to become a problem. Also what i didn't see was how incredible hot the HBA controllers become. I decided to buy a 24bay 4u chassi to see what i could get away with just using the case and switching out the fan wall with noctua fans and such to reduce the noise levels. I got a 24bay case that supports regular ATX PSU because i know server chassis usually go for 2U psu's to have backups and they sound like jet engines so i wanted none of that. Installing everything in the 24bay 4u chassi the noise levels were almost twice as high compared to the nanoxia high tower case even when i switched the fans out and used some nifty "low noise adapters". Next up was the idea of having a 12U rack that is sound proofed, is it possible? How warm will stuff get? What can i find? I ended up taking a chance and i bought a sound proofed 12u rack from a german company called "Lehmann", it wasn't cheap in any sense but it was definitely worth it! I couldn't possible be happier with my build. From top to bottom: 10gps switch AMD Threadripper WM host server Intel Xeon Unraid server Startech 19" rackmount kvm switch APC UPS with Management Card In total 12u of 12u used! Temps: around 5c higher than room temprature, unraid disks average of 27c. Noise level? around 23db, i can sleep in the same room as the rack!

A plugin to create and modify vfio-pci.cfg from the unRAID webGui. Allows you to bind PCI devices by address to the vfio-pci driver. Also displays IOMMU groupings and which devices support reset. Unbound USB controllers display USB devices connected to them. Bound devices will be available to pass through to your VMs under "Other PCI Devices" in the Edit VM Form View. Please see the release notes for 6.7.0-rc1 for more information on this binding method. Search for "VFIO-PCI Config" in Community Applications Github repository: https://github.com/Skitals/unraid-vfio-pci/ URL for manual plugin install: https://raw.githubusercontent.com/Skitals/unraid-vfio-pci/master/plugins/vfio.pci.plg

Nothing, that's why when things are fixed you delete that tag. Sent from my Mi A1 using Tapatalk

I would say it's unlikely.

Like your jeepney's, which come in all shapes and sizes, Unraid can work on a lot of different hardware 😎 Why don't you just try it? Install Unraid and get a trial license to experiment with whatever you have lying around.

The patch modifies source code of the Linux kernel. To make these changes "configurable" would take way too much effort. Theoretically someone could create and maintain a "amd-reset-bug-build" version of the kernel with this patch much like the unofficial "nvidia-build" of the kernel.

In my opinion, about as much as you worry about getting hit by a meteorite on any given day. Yes, these are all security vulnerabilities. Are they likely? Probably not. They are proof of concepts. Are they even likely on a home server? Really doubtful. Sure, in *theory* a piece of malicious software that manages somehow to get itself and installed on your server (very remote odds to begin with) would technically be able to discern through very careful timings the contents of memory (not hard drives, but RAM). But would that information actually be useful? Once again extremely unlikely. These mitigations when push comes to shove are most for data centers because it would allow (in theory) someone to rent out time on a VM running on a server and be able to discern the data that another company has on their VM running on that same server. Intel's recommendation to completely disable hyperthreading is to render yourself safe is ignored by everyone. Personally, I disable all the mitigations for these security concerns that aren't handled via micro-code. I'd rather have the speed of my processor back to what it's supposed to be. But, if you are a member of ISIS, the Black Panthers, or (god forbid) the Mickey Mouse Club then it might not be a bad idea to use all the mitigations and also disable hyperthreading as the NSA obviously has their fingers on you. They are the ones after all who are responsible for the most malicious piece of software ever (Stuxnet)

Thanks for reporting, just issued an update. Please confirm if the bug is fixed.

Assuming you haven't set up any RAID stuff with your 4 USB hard drives, try mounting one of the USB hard drive using the Unassigned Devices plugin and see if you can read the partition. Then you can do copy using the console command line / via ssh / docker.

Unassigned Devices plugin

Not sure why you responded to a 2 year old post? What is wrong with the LUKS based encryption that has been a standard feature of Unraid for some time now?

I upgraded to 6.8.1 and the problem is gone. For now anyway. I'll revert to an older release if the problem persist and see if that makes any difference. Thanks.

You can only rebuild as many disks as you have parity disks, so no you can't do 3 at once. Parity doesn't contain any of your data and can't rebuild any of your disks by itself. It requires data from the other disks to do the calculation. Really it's best to only try to replace them one at a time so you still have some redundancy during the whole process.

I have been experimenting with this today. The transcode->tmp worked fine and Plex is operating without issue. I laugh however when I don't see a notable blip in RAM usage, but I have 192GB of RAM and two Xeon E5-2665 CPUs. I have a gigabit fiber internet connection, and it pisses me off when I see my users transcoding from 1080p down to SD because of their own slow internet. At least I know I am doing everything possible to make the sever side without impedance.

You were absolutely right! it works now! 1000 thanks!

Remember, the team has their own lives, they have day jobs, families and friends heck some are not even in Development or IT in their professional lives. We're all pretty much hobbiest here, and this is being worked on by the goodness of their hearts. I'm OCD when it comes to updating things but you can't just expect everyone to drop everything when a new release hits to be patched. It will be ready when it's done. Thank you guys for all the hard work you put into this project [emoji3590] Sent from my SM-G975U using Tapatalk

I second this request

@Squid - Sorry up front if this has already been asked, but any thoughts on an option to use zstd compression instead of gzip? Here are some quick tests I did on two of my systems that shows much improved speed and slightly smaller sizes: System 1: > cd /mnt/user/appdata > du -d 0 -h . 1.6G . > time tar -czf /mnt/user/UnRaidBackups/AppData.tar.gz * real 1m17.710s user 1m6.245s sys 0m6.219s > time tar --zstd -cf /mnt/user/UnRaidBackups/AppData.tar.zst * real 0m24.039s user 0m10.248s sys 0m5.330s > ls -lsah /mnt/user/UnRaidBackups/AppData.tar.* 814M -rw-rw-rw- 1 root root 814M Jan 16 14:28 /mnt/user/UnRaidBackups/AppData.tar.gz 783M -rw-rw-rw- 1 root root 783M Jan 16 14:20 /mnt/user/UnRaidBackups/AppData.tar.zst System 2: > cd /mnt/user/appdata > du -d 0 -h . 8.9G . > time tar -czf /mnt/user/UnRaidBackups/AppData.tar.gz * real 4m55.831s user 4m19.009s sys 0m27.770s > time tar --zstd -cf /mnt/user/UnRaidBackups/AppData.tar.zst * real 2m1.380s user 0m35.069s sys 0m23.054s > ls -lsah /mnt/user/UnRaidBackups/AppData.tar.* 4.6G -rw-rw-rw- 1 root root 4.6G Jan 16 14:39 /mnt/user/UnRaidBackups/AppData.tar.gz 4.4G -rw-rw-rw- 1 root root 4.4G Jan 16 14:34 /mnt/user/UnRaidBackups/AppData.tar.zst

Sorry...should've explained! I was lucky enough to have recently migrated the VM in question to a second, non-Unraid box to use as a template for another project, so I was able to simply go grab a copy of the OVMF_VARS.fd file from there. Had that not been possible, I suppose I would've grabbed a clean copy of that file from here or here, the downside being the loss of my customized NVRAM settings. I didn't notice if any cores were pegged with this happened, but I rather doubt it, because in my case there was no boot activity--I didn't get to the Tianocore logo, nor even to the point of generating any (virtual) video output for noVNC to latch onto.

Cache performance in v6.8.1 is worse than v6.7.2. See: https://blog.insanegenius.com/2020/01/16/unraid-smb-performance-v6-7-2-vs-v6-8-1/

Okay it seems like having a capital "S" in the password in the beginning breaks it. I changed the password now and it works..

Yep, the ExileMod Server URL changed. In the Docker template please click on advanced and change the server URL to: http://www.exilemod.com/ExileServer-1.0.4a.zip But I would also recommend you to delete the exilemod folder in your appdata and the container completely redownload it from the CA App and change the URL. At the time i'm doing a little code cleanup of all my containers and the ExileMod is one of the next containers that will get the update and then it will stop if it can't download a file (now it doesn't stop, it runns and loops over and over like in your case). Also i changed the template file but it will be updated in a few hours.

Hello! Recently I've had Fix Common Problems plugin let me know about a hacking attempt. That's definitely what the logs imply. Looks like someone was attempting to connect via a bunch of standard / known users and passwords (this was repeated over two days, and 100's of times a day with similar information): Jan 9 02:22:03 Tower sshd[1979]: Failed password for mysql from 91.xxx.x.x port 56816 ssh2 Jan 9 02:22:03 Tower sshd[1979]: Connection closed by authenticating user mysql 91.xxx.x.x port 56816 [preauth] Jan 9 04:43:27 Tower sshd[130858]: Invalid user nginx from 91.xxx.x.x port 52020 Jan 9 04:43:27 Tower sshd[130858]: error: Could not get shadow information for NOUSER Jan 9 04:43:27 Tower sshd[130858]: Failed password for invalid user nginx from 91.xxx.x.x port 52020 ssh2 Jan 9 04:43:27 Tower sshd[130858]: Connection closed by invalid user nginx 91.xxx.x.x port 52020 [preauth] The part that I don't understand is the ports, and what this log really means. My server is exposed to the internet, but only on a non-standard port that is forwarded to SSH, and port 80 (redirected to 443)/443. One of the port 443 redirects goes to the unraid web portal, but hidden behind an NGINX auth - on top of the unraid auth itself. So, my question - how was a login attempt made for these different ports? Beyond taking the access that I have down, what else should I be doing to limit this? Thanks!

For this it's probably best to contact LT directly: https://unraid.net/contact

Please attach diagnostics, which is needed for further investigation. My suspicion is something wrongly configured on your system.

As I mentioned, I don't see any performance reduction before, to prove that, I just did some test to indicate the conclusion you've made is outdated now. VM CPU: 4-7, 12-15, which 4 cores and 8 threads VM OS: Catalina 10.15 (which is as clean as possible, only benchmark softwares) VM Bootloader: opencore with modified to get correct FSBFrequency and Topology (from here) Benchmark software: Cinabench 20 and Geekbench 5 CPU Model: IvyBridge with all features that host supported Results: 4 cores and 8 threads with SMP topology Cinabench: 2554 Geekbench: 1273(S)/5455(M) 8 cores with SMP topology (which MacOS recognized as 8 cores) Cinabench: 2551 Geekbench: 1277(S)/5433(M) 8 cores without SMP topology (which MacOS recognized as 8 sockets, I don't know if there any differences) Cinabench: 2546 Geekbench: 1279(S)/5387(M) Conclusion: I don't see any performance reduction between SMP using and not using hyper-threading during my test. I'm not saying you did things wrong, it may just outdated or apple changes their codes. My point is I won't just buyin someones' conclusion which is rather old from now. It didn't make sense to me, if I fool the MacOS that it is not a thread but a core then there will get some performance gain?On the contrary, performance reduction makes more senses to me. Because it didn't change the fact it is actually a thread, its performance limit by the hardware anyway. Host: VM CPU pins: CPU features: <qemu:commandline> <qemu:arg value='-device'/> <qemu:arg value='-cpu'/> <qemu:arg value='IvyBridge,vendor=GenuineIntel,+hypervisor,-erms,+invtsc,kvm=on,+topoext,+svm,+invtsc,+fma,+mmxext,+avx,+avx2,+aes,+xsave,+xsaveopt,+ssse3,+sse4_2,+popcnt,+sse4a,+bmi1,+bmi2,+arat,+abm,+3dnowprefetch,+adx,+clflushopt,+cr8legacy,+fsgsbase,+fxsr_opt,+misalignsse,+movbe,+osvw,+pclmuldq,+pdpe1gb,+rdrand,+rdseed,+rdtscp,+sha-ni,+smap,+smep,+svm,+vme,+xgetbv1,+xsave,+xsavec,+clwb,+umip,+topoext,+perfctr-core,+amd-ssbd,+wbnoinvd'/> <qemu:arg value='-overcommit'/> <qemu:arg value='cpu-pm=on'/> </qemu:commandline> Cinabench screenshots: Geekbench Screenshots:

People, we have a genius here, seriously. It works! Moving the built-in audio to bus 0x00 and slot 0x02 finally makes AppleALC work. So, resuming: - AppleALC+Lilu kexts in CLOVER kexts Other folder - built-in audio bus 0x00 and slot 0x0y (where y is a number different from 0) - In clover config.plist: Devices --> Audio: Inject=No - In clover config.plist: Devices --> Audio: check ResetHDA - In clover config.plist: Devices --> Properties --> Devices: fill in with the proper address (use gfxutil with command gfxutil-1.79b-RELEASE/gfxutil -f HDEF) - In clover config.plist: Devices --> Properties --> Add property key: layout-id, Property value: x (where x is a number reflecting the audio layout, see here for layouts for supported codecs: https://github.com/acidanthera/applealc/wiki/supported-codecs ) (my working layout is 7), Value type: NUMBER - (Optional) In clover config.plist: Boot --> add boot arguments -liludbg and -alcdbg: this will work if you use the DEBUG kexts; when your system boots you can give this command in terminal to check for Lilu/AppleALC: log show --predicate 'process == "kernel" AND (eventMessage CONTAINS "AppleALC" OR eventMessage CONTAINS "Lilu")' --style syslog --source Unfortunately I cannot check for HDMI audio of my GPU as I don't have a hdmi cable, but from the attached log it seems ok (HDAU). Relevant parts of the xml for the vm: Passed through GPU and audio of the GPU: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x83' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> <rom file='/mnt/user/GTXTitanBlack.dump'/> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x83' slot='0x00' function='0x1'/> </source> <alias name='hostdev1'/> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x1'/> </hostdev> As pointed out by Leoyzen, gpu and gpu audio must be in same bus (in this case 0x03) and different function (0x0 for gpu, 0x1 for gpu audio). Built-in audio (passed through): <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/> </source> <alias name='hostdev2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </hostdev> Built-in audio in bus 0x00. Siri is working ok. Clover settings for built-in audio I'm saving the VoodooHDA as a second option for the audio and use AppleALC. @Leoyzen May I ask you, what was the input to make me change the bus of the built-in audio? lilu-AppleALC-log.txt

Port 80 is already used by the Unraid GUI. Map the first entry for the Container Port 80 to something that isn't used, like 8080, 8002, etc

Dynamix cache dirs. And momentary usage by a background process isn't something to be particularly worried about Sent from my NSA monitored device

I can't get my cert to work with Let's Encrypt. Whenever I request an SSL certificate from Let's Encrypt, I get an internal error from the IP address and port of the Nginx GUI. When I refresh the SSL certificates tab, it shows the certificates I requested, but the expiration date and time are the exact date and time I requested them. Not sure what could cause this.

@DJoss Thanks man, I finally got it working! For me, a few things that may help others: 1. This only works if the various containers are in bridge mode (which I think was previously discussed on this board, but I forgot). All my containers had their own ip addresses so I had to change each, stop and restart them. Remember once all containers using this app are in bridge mode, in proxy manager, the ip address is now unraid's ip (with different ports). 2. Also, its worth noting, you DO NOT have to port forward in your router to any of the containers. Only forward ports to this app as required and that's it. So I had to remove all the port forwards and ips for the various containers within my router. 3. My namecheap subdomain set up was right on. Cname subdomains for each app linked to the domain name seems to be work. No need to do a wild card. 4. In the apps, I made sure all containers did not reference ssl anywhere. 5. All destination ips in proxy manager were set to http (so http://unraidip:appport). 6. I knew I was on to something when, looking at the logs, lets encrypt would accurately send an crt. Still could not get my custom cert to work but beggers cannot be choosers. 7. One annoyance -- the proxy app times out when trying to secure an ssl certificate via lets encrypt. So it appears to fail, but when you cancel the function you are able to select the ssl cert. 8. Finally, once lets encrypt had the cert, I set each subdomain to force use the crt and it works. Great app!

Strictly speaking step 5 is normally not necessary as KVM can handle .vmdk files directly. To do so you need to enter the path to the .vmdk file directly into the template as the unRAID GUI does not offer such files automatically.

try switching over to SeaBIOS when creating your VM, that's what fixed my issue.

Yes that will work, but the problem is that it increases the disk space required by the VDisk. For example if a VM has a 30GB virtual hard drive but is only using 13GB of it. It actually only takes up 13GB on the cache drive. The copy will take up the 30GB on the cache drive. The same is true in vmware esxi, if you just try to copy the thin disk it will expand its size. Note that ls -l will show you it takes up 30GB, but du will show you what it really uses. Easiest way to copy a vdisk with it taking up more space is to install libguestfs-tools to a ubuntu vm mount your shared vm folder to the vm. open terminal. cd to the mounted vm share and run virt-sparsify --format raw --convert qcow2 --compress vdisk1.img vdiskcopy.qcow2 This will sparsify convert raw to qcow2 then compress the image so your copy is correct size You will need as much space in your ubuntu vm as the raw image is as it uses a temp file to do this.