BRiT

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.

Pretty sure all those ini files are in RAM if they're under /usr/local/emhttp, unless they're linked back to /boot/ or elsewhere that is on the flash drive?

No meaningful difference between the two lists. If you have time and are in a troubleshooting mood, you could see if anything happens after running CA Backup before it's next scheduled time. If you see similar or odd behavior, at an open shell, type "sync" before you try troubleshooting again and then see what's what.

Well I can't think of other commands to run to troubleshoot things as to the cause or what really happened. I was hoping someone else would jump in with ideas to run. If you want to resolve the situation now, you can reboot the system. However, that will prevent additional troubleshooting steps, but I think to trigger it you might only have to run CA Backup. If you do reboot now, comparing the earlier posted emHttp.txt file to one generated after the reboot and you verify the system is functional again might be interesting to see what exactly disappeared.

There's also log files from the CA Backup process located in /var/lib/docker/unraid/ca.backup2.datastore/appdata_backup.log or /tmp/ca.backup2/tempFiles/ that you should look at to see if you can find anything in there. I see a line in the syslog that was at the end run of CA Backup at 03:46:10, not sure if that's normal to have it echoed in the syslog.

It's very bizarre that those ini files would not be there as they are part of every running system, and what you described is very close to what I and another experienced after CA Backup ran. Have a deeper look inside there, like can you look at a recursive listing [ find /usr/local/emhttp -print ] to get a manifest of what is or isn't there? It will prob be pretty big so might need to redirect output to a file.