JonathanM

Yes.

Cache prefer is a better option, and if you are using multiple drives managed by unraid in the cache pool with a RAID level that supports redundancy it will not show as orange, because unraid knows you have RAID redundancy.

Running processes with unknown and ongoing security concerns with more privileges than are necessary. Root should only be used to do things that a sandboxed user can't accomplish. General web browsing should be isolated from root functionality.

This^ We've been fighting for years to get unraid secured, letting people have at it with a firefox browser running as ROOT is hardly best practice.

Sound card device drivers. They would have to be built in to the OS, like the DVB custom build that is currently maintained by a third party.

Why not run the openvpn server built in to pfSense?

Bingo. User0 is everything EXCEPT the cache drive.

All hail our robot overlords.

2 physical locations separated by 10 miles bridged by pfsense always connected site to site VPN, but the backup is done using duplicati sending data to nextcloud. I also back up several desktops using duplicati to the same server.

Nextcloud docker along with the nextcloud app on the phone does exactly that.

It all depends on your risk tolerance. The next closest thing to a parity check would be long smart tests, those you can start on individual disks whenever you feel like it, and they should only be run when that specific drive is expected to be not needed for the duration of the test to ensure a clean run. It shouldn't affect other drives performance. A parity check is needed after unclean shutdown though. No, it's more that drive throughput in MB/s has not increased linearly with capacity. One of my test servers takes around 4 hours for a parity check, because it only has 1.5TB drives and still manages 90+MB/s, where my main production server takes 19 hours because it has 8TB parity and only manages 115MB/s. It would be much quicker if ALL the drives were 8TB instead of only a few.

Do NOT use drives with known health issues in the array. Many years ago I lost data because a drive I thought was in perfect health failed, and the drives I knew to be dodgy, predictably failed during the recovery. ALL remaining drives must be read completely perfectly to successfully recover a failed drive.

Need is maybe too strong of a word, but they sure are prudent. Not only for the detection of parity inconsistency, but mostly for the regular exercise of disks. If a disk is purely archive, it may never be called upon to read, but if another drive fails, the long dormant drive will suddenly be called into duty to perform perfectly in the reconstruction of the failed disk. Think of regular parity checks as confirmation that the system is healthy and able to perform a recovery if a drive fails. Traditional RAID systems that stripe data across all volumes don't have to contend with this exact scenario, as all drives are spun up and read from every time the system is accessed. Unraid is pretty unique in the ability to keep certain drives spun down during normal usage. Problem is, if the drive is never used, it can fail silently and bite you when you need it most. Regular parity checks keep an eye on your drive health.

What is your definition of dated? Last update was a month ago. Look at the last post of the thread.

Third party ios or android app that will do what you want, but not webgui.

No.

Not a good idea. Daily "all ok" messages are necessary to test the communication channel. If you miss a daily email, you know to check on the server to see why. If you have it set to send errors only, you will never know whether it can successfully reach you. In your case, getting daily status and not getting alerts was a bad combo.

Rethink this. If there is anything that needs to be backed up inside the docker.img, you need to change how you set up that docker. Currently the way to fix a number of different docker issues is to delete the docker image and let it rebuild from scratch. Doesn't take more than a few minutes, and if everything is set up correctly no data is lost.

Are there any rules in your router referencing your unraid box? Attach the diagnostics zip file here and someone will have a look.

I use retired unraid servers, they just do backup now. After you have run unraid for as long as some here, you build up an inventory of boxes that still work fine, they just don't have the horsepower for VM's and dockers. If you buy cheap consumer grade hardware, you are lucky to get 5 years continuous duty as a server. If you buy server grade stuff, you end up scrapping perfectly running hardware after about 15 years. 😁

Temporarily uninstall it. Completely. Disabling it isn't enough.

If you are still having issues, try mapping out the IP's for all devices behind your router. It almost sounds like you have some other device with the same IP as your problem child is grabbing. Normally that's not supposed to happen, but obviously it can. Quick way to check if that is indeed the issue is to find the local IP of the iMac, power it off completely and make sure it's not connected to the network in any way, then ping that local IP from another machine. If you get a response instead of a time out, there's your problem.

Think of each container as a tiny VM. loopback only works inside each individual container. Container to container communication goes through the docker network.

Which means you can't use that VPN with trackers that require real seeding. Opening ports in your router is meaningless if you are tunneling through the VPN.

I use the low capacity castoffs from my main arrays for backup arrays. Since the duty cycle is low on the backup unit, power usage is not a concern. The only issue is the low data density requires a large case, PSU and HBA. Drives are effectively "free" as I upgrade the capacity on the main arrays. I don't keep 1:1 backup, as there are some things that I honestly wouldn't miss if they were gone, but I'm loath to delete on purpose because reasons.