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.

But when you run a ssh or web server that requires certificates, your logs will show one connect attempts from scanners and then they will go away when they get a request for the certificate. It's just not meaningful to attack a certificate-based installation unless it is incorrectly configured or too old to have all the required bug fixes and the algorithmic strengthening. When you run a ssh or web server that requires passwords, you will see a huge number of login attempts where password databases are used. Some scanners will try the 100 most common admin accounts with their default passwords. But some scanners will switch over to use very extensive password databases since bandwidth is so cheap and they have robot machines that performs the attack meaning the login attempts comes from many different IP and aren't consuming the bandwidth of the attacker. This is the reason why lots of commercial systems combines the password requirement with 2FA, where you have to supply a time-limited code. Password login are very scary - especially since the machine you login from might have a keyboard logger. You got the answer "No" to that question. And instead got workaround solutions. That made you angry - the attitude you blamed on others.

The pot calling the kettle black.... If people aren't running their unRAID through Caddy then people aren't keeping track of issues with that usage case. So looking into Caddy support is most probably the best route to start hunting for the problem. People are regularly running unRAID with VPN. So you have to accept that people suggests a VPN - since it not only provides good security but also allows access to the shares etc.

A: I can't get my car to run faster than 300 km/h - it only does 220 km/h. B: Get a bigger motor and possibly update the gear ratio for the transmission. A: I don't want suggestions of a bigger motor - I want it to run faster than 300 km/h. Anyway - I think the first step is to look for Caddy support, since it would most probably be log files created by Caddy that might tell what isn't working as expected.

But the front fan is replaced with the two fans at the back of the hotswap bays.

Just note that there is a limit to how large errors the CRC can detect. A well selected x bit wide CRC polynomial can catch all odd bit errors and a single burst error up to x-1 bits long. But if there are two bit errors that are further away than the burst capacity, then the CRC may start to accept broken packets. For a busy system with a single CRC error now and then, that isn't a problem, because the probability of bit errors is then low and the probability of having multiple bit errors in the same packet is then even lower. But for a system with constantly ticking CRC, there is a danger that a packet may have more than one bit error at different locations in the packet - and this may result in a broken packet being accepted. So it's generally ok to have a system where the counter ticks up once/month while it's directly dangerous to have a system where the CRC counter ticks hundreds of times/day. Each user must then decide where their comfort zone is, when transfer errors must be fixed. Note that the frequency of CRC errors must be put in relation to the number of transfers - an idle disk that ticks a CRC error or two every day could produce a huge number of errors if a TB-sized transfer is started.

Thank you for the additional photos. The selected hotswap bays will obviously greatly affect the outcome depending on how deep they are.

Beautiful job. This looks like a nice backup NAS. Please post photos from the inside.

Was it log files? Not too often to get better than 10x compression unless there are lots of regular information in the files.

It's normally when I need to store large log files that compression is meaningful - I want the data to be easily accessible without having to stream through a decompression software. Source code files are normally much too small to make a difference - It would make a difference if the machine is hosting a huge public Git server with millions or billions of source files. Databases needs constant updates where the database update logic interferes with the block-level compression of the file system. And my largest disks normally stores huge but pre-compressed media files. One note is that many SSD performs compression on the inside, to reduce media wear. That's because a lot of SSD writes are made to easily compressed structures like the meta-data used by the file system layer. And writes to files that changes are normally done on files that compresses well. And a SSD is much more likely used as a system disk for a PC than a storage volume of large media files. So quite a lot of files traditionally stored on a SSD can compress quite well.

You should have a routine where all surface of all disks are read end-to-end regularly. Because it's only when the disk tries to read the individual sectors that the disk can detect problems with the surface or with locking on to the servo information that describes the location of the tracks and sectors. Most data loss in traditional RAID systems (except user errors like file overwrites or accidental deletes) is caused by people not having scheduled testing of the drives. So as long as they don't get a read error when trying to view a film or opening a document, they don't know the state of the drives. So when they finally get a read error, they may already have multiple disks with errors - and not enough parity data to recover.