BRiT

Everything I have seen with networking is to run both IPV4 and IPV6 at the same time, which is called dual stacked, or to run only IPV4. The attempts at only running IPV6 currently results in not being able to reach huge portions of the internet. The rest of the network world simply isn't ready yet.

For files that are never supposed to change, look into marking them as immutable with, chattr +i filename . The only way the file can be changed is through removing the immutable attribute first with, chattr -i filename.

Isn't there enough hardware level support in hard drives where they detect and correct bitrot from a sector perspective? I vaguely recall a post by Limetech (maybe?) that went into all the various levels of protection that is actually built into the storage hardware systems.

Maybe Hairpin NAT ?

Post your parity check history so one knows when it faltered. You do have it scheduled to run regularly, like monthly right? You can see this on the Web UI by looking at parity history and posting a screenshot of the window captured. I dint know where that info might be inside the diag file, otherwise I'd look there.

That's not the installed to directory. Look under /usr/local/emhttp/plugins/ hierarchy, that will have plugins installed.

Run and finish Parity check at all of the following times: 1. before any server maintenance. 2. after any server maintenance 3. before moving a server 4. after moving a server But its your data and your server so feel free to take whatever risks you're comfortable with.

I would not want to put any of my servers on the internet with DNS records pointing to them, so using CloudFlare as a security firewall proxy makes sense. But its your server and your data so take whatever highstakes risks that you are comfortable with.

Are you sure it's not from one of your Windows VM?

If you already have it installed you can look at the php files itself.

Hate to be that guy, but ... You should attach diagnostics to your next post in the thread. That will provide comprehensive set of actual information that others can use to possibly assist you.

And you removed any and all your array drives from off the controller card mentioned? (Because it uses port multipliers which provides slower performance when all drives are in use)

Are you located in Canada or trying to pull anything from there? If so, it's likely because Rogers has royally fraked their network. It's been a major outage across the country since 5am Friday. https://www.cnbc.com/2022/07/08/rogers-network-outage-across-canada-hit-banks-businesses-and-consumers.html

That's should just be an escaped TAB character, \t

Do you have any actual power draw measurements?

Run SMART reports on all smaller drives. Examine SMART results. Replace the most questionable drive going off the reports. Consolidate the content of the second most questionable drive going off the reports onto the new 12TB drive. No sense in keeping more drives than needed to store your content.

The moment that happens is the moment I and perhaps others prune that entire forum subsection off our "New Posts" feed. That is to say we ignore it entirely. All of it ignored. We dont have time to sort through 240+ new threads for Docker Apps we don't use. Your intention may be good but the actual impact is less community members will be willing to help out where they can.

Try using Docker IPVLAN mode for each docker container so they have their own local IP address, which should enable the router to track the traffic separately.

Setup for "newperms ." misbehavior, here are the raw command to duplicate this from a root command prompt: cd /mnt/cache mkdir tmp cd tmp touch testfile.txt ls -al . ls -al /usr/local/emhttp/plugins/dynamix/scripts/ newperms . ls -al /usr/local/emhttp/plugins/dynamix/scripts/ ls -al . Setup: Execution: Examination of the bad behavior:

Try it as shown in the previous screen attachment and you will see that when passing in "." instead of using the current directory the user is in, it for some reason interprets it to mean the current location of the script which is /usr/local/emhttp/plugins/dynamix/scripts/ It used to work perfectly before whenever these changes were done. Do you need me to attach another screenshot to show how to reproduce the bad behavior?

I figured out some of my grief was caused by using "newperms ." at the command prompt, that should set new permissions for the current working directory, which I normally had always done when managing media content with unraid 6.8.3 or earlier. Issuing that command instead completely clobbers the permissions of several scripts at /usr/local/emhttp/plugins/dynamix/scripts/ instead, which leads to all sorts of bad behavior from the UI.

I didn't notice this until today, but has the syntax to "newperms" script changed after unRaid 6.8.3 ? I used to always use "newperms ." to change the permissions on the current directory I'm in. Doing so on 6.10.3 results in the permissions of /usr/local/emhttp/plugins/dynamix/scripts/ changing instead. This breaks things.

Mine spin down fine. I know that doesn't help you, but know that it does work.

Updated yesterday and so far so good. The system came up after reboot without issues.

Can you provide more specifications as to what you define as mobile? What size screen? What browser? For the most part I find the current UI usable on my Android Tablet with Chrome browser, but I know that my tablet has better screen resolution than what most users are likely using.