pwm

Multiple arrays are great. More than two parity drives is great. But remember that parity is intended for improved availability - it is not a replacement for backup. So you should really, really look into cheap USB disks and copy out your "must not lose" data on them and then store them at parents/children/friends. A single "big oops" with the PSU may kill all drives in the machine. And a fire may kill all data on every piece of hardware in the house. So only use single storage for data you can afford to lose, whatever number of parity drives you may be allowed use of.

Did you need the extra transfer speed? RAID-0 means you lose all data if one drive fails.

Backblaze also see failed Seagate drives. But they note that they buy the Seagate drives cheaper than WD Red drives. And since their infrastructure can handle broken disks, it's more profitable with the Seagate disks. If 5 disks in 100 fails, that still only represents 5% of the purchase cost - and if they buy the drives 15% cheaper than WD Red and the WD drives maybe have 3 disks in 100 fail then it's clearly an advantage to select Seagate drives. For normal home users, it doesn't work well to consider amortized costs like that - we don't have the same routines to maintain redundancy even with multiple broken disks. And we don't have the same routines to restore data to new disks. And we have so few disks, that a single broken disk will represent a significant percentage of the total purchase price of the storage server disks.

Remember that helium drives draws much less energy (so less heat) than older technologies. So you can have 7200 rpm helium drives produce less heat than some 5400 rpm drives. And there isn't a clear rule about amount of noise between 5400 rpm and 7200 rpm drives.

The PSU itself doesn't care. It's a question of if you are using a power cable that contains 3V3 or if you have a cable that only has 5V and 12V.

No, I haven't. Most of the time when I need changes to an unRAID machine, I just make the changes I need. But obviously I sometimes have to repair/modify my own patching after unRAID updates. Such as my original iptables firewalling of the machines that had to be modified after unRAID started to use iptables for docker.

Yes I could. But the problem is I don't "own" the group file, and so do not know what requirements unRAID might have. If I update and unRAID requires additional system groups that I don't know about, then I will overwrite them. That's why I would have liked unRAID to change behavior and store the group file in the config directory just like the password file instead of trying to force a system-supplied file on us. I feel patching the file is the most compatible way to make use of groups. I would like that LT spent some time on hardening unRAID. Official use of account groups, firewall rules etc. The IoT revolution means people will bring in hundreds of new networked devices with totally unknown security levels - so there are just so many more ways we may get infestations in our local networks.

Yes, I'm a bit sad that the groups file isn't represented in /boot/config like the other files. So the machine needs to recreate custom groups and assign users to them on boot (the 'go' file), like this: root@n54l-3:/etc# groupadd -g 1101 pwm_test root@n54l-3:/etc# usermod -a -G pwm_test fs_cesium root@n54l-3:/etc# tail -1 group pwm_test:x:1101:fs_cesium And it's obviously important to reuse the same group ID on every boot - and use an ID that isn't likely to collide with future unRAID versions. root@n54l-3:/mnt/disk2# ls -l /mnt/disk2/radium/ total 0 drwxrws--- 2 root pwm_test 112 Jun 28 00:07 test/ -rwxrwx--- 1 fs_cesium pwm_test 0 Aug 25 12:27 test-pwm_test* root@n54l-3:/mnt/disk2# ls -l /mnt/user/radium total 0 drwxrws--- 1 root pwm_test 112 Jun 28 00:07 test/ -rwxrwx--- 1 fs_cesium pwm_test 0 Aug 25 12:27 test-pwm_test* And I like to have: chmod 2770 <dirname> so new content created in the directory will inherit the group instead of getting the main group from the account adding the content.

I have manually (i.e. on command line) made use of group rights and it works well.

The main advantage with encrypting the disk, is that if you have a warranty issue you can send in the drive as is without caring about the content. An unencrypted disk that fails may be so broken that it can't even be erased. But as noted by @John_M - most people don't need encryption. How much it slows down the system? That depends completely on amount of processing power. Note that unRAID parity work is done on raw disk sectors, so it isn't affected by the encryption - unRAID does the work below the file system layer.

To a big part, the routers needs to be better, and I think with the loss of SMBv1 more routers will introduce better support to handle this problem. A router that shares the information between DHCP and DNS will be able to catch a DHCP request from the unRAID machine and automatically insert a DNS entry so you can find unRAID on name without SMBv1. Next thing is that with a router with SNMP support, Windows Network Discovery can ask the router for information to find other equipment in the network so that Windows can enumerate the equipment in the network. So it's a question of having decent routers that helps the Windows machines give the same functionality but without involving SMBv1. My firewall doesn't allow any SNMP but it does supply the DNS information so I can access equipment on name without SMBv1 and without use of any hosts file - the hosts file is the machine-local IP resolve for people not doing DNS-based IP resolve. It really isn't Microsoft that is the bad party - it's lots of equipment developers who haven't bothered to configure and support alternative protocol solutions.

People who use it in a home environment doesn't have a CSO that works with the security. And they do not have any policy for what programs may, or may not, be run. It really doesn't hurt to make use of a DNS for name lookup instead of having every machine wildly broadcast their names. Or unless the router runs a DNS that includes a lookup for the unRAID machine and the Windows machine is configured to use the router as DNS.

No reason to. Only fix what is actually broken.

The error message indicates that the time has stepped back. If it doesn't happen regularly, then I would ignore.

What does the support of "some application" say about this? Maybe that their intention is that "some application" should not be able to run in a virtualize environment? What does google for "some application" say? Anyone else managing to get "some application" to work in a VM?