pwm

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.

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.

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.

Maybe drifting time that got corrected when the time client got in contact with a time server. Maybe a time server that is bad at keeping track of time. Have you configured the use of ntp to set the clock? And have you specified a good time server?

Desperate situations may warrant desperate actions. I have placed overheating Seagate USB drives in a Peltier-cooled food cooler just because it was faster/easier to read out the data that way instead of having to spend time to identify exactly what data was on different backups and restore. In the end, the actual heat power emitted isn't very high - likely 8-10W depending on disk model when active. So it doesn't take very much to affect the equilibrium temperature.

The claim was to taking the temperature down from 40°C to 35°C.

That depends on what reads you are performing. No striping, so no transfer speedup when reading a single file. But having multiple independent file systems still means you can concurrently read from all data disks and perform independent seeks on the data disks. If you need to read multiple larger files on RAID-6, then you still get a significant slowdown from all the disk seeks. All disks needs to seek to retrieve a stripe block of file A. Then seek to retrieve a stripe block of file B. Then seek to retrieve a stripe block of file C. Then back to A again.

Directly you write @ and a character, a popup should show up. And the text you write will then match account names.

Do you get a popup with you write @ and the start of the name? And do you then click on the correct name? @Switchblade

Exactly. But you, on the other hand, can't expect every single forum user to make individual posts "no". So you have to accept the fact that there isn't a well-known issue with unRAID and Caddy. It still boils down to what I did write earlier "If people aren't running their unRAID through Caddy then people aren't keeping track of issues with that usage case." I'm not forcing anything onto you. You may run with an unencrypted connection if you feel that is fine. Run Caddy if you want - just that you can't expect much help in a unRAID forum if people aren't much using Caddy. But you might get help in a Caddy forum, since people on a Caddy forum are quite likely to use it and/or have knowledge of how to turn on suitable logs to figure out what goes wrong. There is a Caddy Docker for unRAID. Below is the support thread for this Docker. The silence in the thread indicates that people are either not using it or are using it without having any issues. And you haven't mentioned Docker anywere so your problem is most probably not related to @cmer's docker. If you post that password-based solutions are secure, then I have a reason to note that they aren't as secure as certificate-based solutions. This may be "your" support thread, but all support threads are open and other people will read this thread too. So you can't demand that people mustn't recommend VPN. There are too many happy VPN users so if anyone finds this thread using a Google search it's best that they clearly see that the general recommendation is to use VPN. A reverse proxy is common when lots of users should reach a system - and the backend system is then often placed in a separate, firewalled, network. A VPN is much more common when there are a limited number of specific people that should have access but the security requirements are high.