bitcore

Hello, Old thread, but were you able to resolve the drive spindown issue with your 9600-24i which uses the mpi3mr driver?

I'm having similar issues with VMs recently on 7.0. No passthrough, just a load of VMs with a 3960X thradripper on ASRock TRX40 Creator. Windows VMs will start to freeze and start to stutter and not be as smooth as usual, and often ultimately lock up. My fresh W11 VM is showing weird behavior as well. Remote desktop will connect to an existing logged in session, but load the pre-login screen - but not respond. But connecting via the VNC console and logging into an existing session that way seems to kick it back into life momentarily and you can login just fine, and then it freezes again. Previous W10 VM essentially broke when I increased it's RAM. It would drop to EFI shell and refuse to boot. After switching machine types around, nothing would recusitate it. I eventually copied the qcow2 disk and created a new VM pointing to the copied disk, and restored the VM, but the poor performance, stutter, and etc remained. No memory over commitment, cpu cores are pinned and isolated (not shared). Just upgraded to 7.0.1 about 12 hours ago, we'll see how stable it is. Seems to initially be better on my machine.

Running Unraid 7.0 now, and only one disk (my cache disk) is detected as a valid LUKS device according to cryptsetup. This is with the array started and disks mounted. Previously I seem to remember being able to do this while the array was mounted? root@server:/# cryptsetup luksDump /dev/sda Device /dev/sda is not a valid LUKS device. root@server:/# cryptsetup luksDump /dev/sda1 Device /dev/sda1 is not a valid LUKS device. Same situation for the /dev/md devices and the /dev/dm- devices. Any ideas?

Hi Chester! (reference to your avatar from sifl & olly show) After an upgrade to 7.0, encountered this with one of my VM. Started with a reboot of the VM not loading anymore - would just drop to EFI with "map: no mapping found" and not boot into windows bootloader. Messing about and changing Q35 version to q35-9.1 (edit: From an earlier Q35 version) restored the VM's boot capability, but performance was AWFUL, and freezing up entirely shortly after boot. I implemented the changes in this thread: Enabling hyper-v enlightenments as described in that article restored performance to what it use to be. Maybe give that a try with the <hyperv mode='custom'> block options, and check that your 'migratable' setting is off, and 'hypervclock' is enabled. I'm still having the same issue I've always had, where the redhat virtio ethernet driver appears to completely consume one CPU thread with kernel load any time the VM was receiving more than around 700mbit. (In windows task manager, you can observe this on the performance tab by right clicking you CPU graph, change graph to 'logical processors' and 'show kernel times' - I see 1 thread at 100% and it's the darker color, indicating that portion of CPU utilization is kernel mode - indicating that driver code is the culprit) I couldn't saturate my 10G connection at all. Upload seems to not be as affected, strangely. I'm using virtio, NOT virtio-net.

Thanks for this script! Giving this a little bump since I think it's an important that people who use encrypted volumes perform. I noticed when I dumped all of my headers, I had bin files of different sizes. Turns out, my disks in the array have a mixture of header version 1 and version 2 - where a version 1 header dump is about 1.1MB and version 2 is about 16MB. This must have been from disks that were formatted in older versions of unraid. I was completely unaware of this, however to me it seems to be inconsequential in daily operations. For users who have not read-between-the-lines in the script or know how to work with cryptsetup, you can print out the headers and see things like what ciphers and hashes are in use, header version, and other information about your disks that you don't normally see in the GUI. Run the following in the unraid console or SSH to present a human readable version of the header to you: cryptsetup luksDump FileName.bin You can also do this directly to mounted disks instead of an image. For example, change the filename to "/dev/sdb1". I suppose you can perform this to manually verify your backups were successful.

Cheers for the follow-up, @JC-303, appreciate it. When you say "The backups need to be written to an unRAID directory shared to a path within the VM", does this mean that if the target VM to be backed up itself gets compromised or has a ransomware infection - your backups can be destroyed as well since that share must be mounted/available? (that would be very disappointing.) Or, does this required mapping only apply to the VM running the veeam server application only?

Nice work @sticklyman! Thanks for the help @itimpi ! Glad to hear that it seems to stop the exploit POC! @sticklyman, Would a community applications plugin be easy to build/deploy with your binaries to make this as easy as a few clicks for the entire unraid userbase? I've not made one of these before so I'm unsure if it's even possible to distribute binaries as part of a plugin...

Apparently you can set the following at boot and it disables the chicken bit (edit) without microcode update: wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9))) Reference: https://news.ycombinator.com/item?id=36852699 Reference that it works better than a microcode update for one person's hardware combo: https://news.ycombinator.com/item?id=36854488 I've not tested it myself yet but apparently it's rather well supported across the linux ecosystem. I'm not sure of the best way to implement this automatically at boot in Unraid... perhaps someone else can chime in and add a recommended method? I'm running threadripper and a lot of VMs, so this is a particularly desirable fix that I want to be reliable.

I agree, a link to the discussion forum in the little release notes provided in the webGUI (the "i" button) would be very helpful and courteous to users. Additionally, I'd love to have more than just the changelog in there. The same text blurbs that are posted in the forum post for the release notes would also be helpful. I'm personally pretty diligent about reading the upgrade threads from top to bottom, and I'll admit that though it's great we have organized release threads, it's a little annoying to have to search for the thread to be sure I don't run into any show-stoppers. A link would really be lovely. Anyway, thanks for the release! Edit: Also, my upgrade from 6.10.1 to 6.10.2 went just fine.

I have similar issues with SHFS CPU utilization very high. Have you found any solutions?

Great. How do I manually reset the counter via SSH. How do I increase the failed attempt count to something reasonable like 10 attempts within 15 minutes? IMO, a limit of 3 is asinine.

I confirm that this also works on my system. 6.9.2 Thank you booman! This effectively downgraded my ncurses package from 6.2 to 5.9. +============================================================================== | Upgrading ncurses-6.2_20201024-x86_64-1 package using ./ncurses-5.9-x86_64-4.txz +============================================================================== Hopefully nothing else breaks...

Same issue here. Also tried uninstalling and reinstalling - no difference. I also uninstalled python 2.7.11 and then reinstalling iotop. Same errors. Edit: I ran across this thread: https://github.com/dmacias72/unRAID-NerdPack/issues/59 which seems to indicate both an ncurses incompatibility, and that the iotop app is massively out of date anyway.

+1. Virtualizing a firewall makes using unraid as the bare metal OS for an all-in-one server a problem. Consider: I have an encrypted array. If I have an extended power failure and UPS goes flat, I can't get back into the array without physically being present to enter the key and start it up again. I don't want to have to virtualize unraid itself to achieve this.

I'm very excited to see a larger push for security. Thank you. Security is very important to me, and I applaud the efforts! I'm very pleased to see this! However, is there a way to adjust the GUI's failed login lock threshold, or cool-down timer? I personally believe that a max of 3 attempts is... extremely aggressive, such that it's counter-productive. This leaves very little room to allow humans to be humans; fallible, and prone to mistakes. These values are simply a punishment and unfriendly to those cursed with fat fingers, rather the serving as an effective protection measure. This is especially true with long and complex passwords. It would be brilliant to provide us a drop-down to let us adjust these values ourselves, or at least share the config value names in the config files, if they exist. Please allow me to articulate an argument to change these default values away from 3 and 15 minutes. Yes, a tight value like this is technically more secure, but doing so renders the extra layer of protection impractical. It's not sensible or realistic. I would suggest a default value of at least 5 attempts, better 10. Actually, you could flip these values: 15 attempts, 3 minute cool-down, and this would still be incredibly effective at protecting a moderately complex password, yet still minimizing the friction of getting an authorized user logged in. That would result in only 300 password attempts per hour. You are not cracking an 8 character password at that rate within a single year. An attacker would be better served profiling and exploiting a vulnerability. Honestly, a 15 minute cooldown after 3 type-os is a "go sit in the corner time-out, and wear this dunce cap" punishment. These are not sensible values for a home NAS. I suggest taking the minimum password length allowed, calculating the worst case keyspace (user chooses a dumb password with minimal complexity), and work from there to establish an acceptable "attempts per minute" to prevent brute forcing.