BRiT

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.