MowMdown

The only think I can think of is your docker mod doing something. run sonarr without the docker mod Get rid of all of this and run it plain vanilla: Edit: Also, do not give plex read/write access to your data share, make it read-only.

To easily roll back, there should be a "previous" folder on your USB, just copy those files from that folder back to the root of the USB and overwrite the existing ones. This will boot you back into 7.1.4. As always, make a backup of your USB before doing anything.

You didn't enable "Host access to Custom Networks" in the unraid docker settings page.

This one might require its own forum post to get the right eyes on it. If/When you do please make sure to include the diagnostics

click the little blue disk symbol next to the drive:

I would check the drive log for the nvme disk and the USB Drive as well.

What does the BIOS detect as the boot media?

This might be something one of the LT staff members who are more familiar with the webgui backend might need to look at. Im not sure what this really is coming from. Does this behavior persist after rebooting? Does it happen with ALL docker containers or just Binhex containers?

It appears you may have a docker container crashing and restarting over and over which may be why your specific case is causing massive slowdowns. Or it's the php errors. (these two things are probably related) Check all the "Uptime" stats for your containers to see which one is crashing: also your custom qbit mover script has issues you also may want to resolve, looks like you input an incorrect format for the cron timer check your cron formatting: Nov 3 12:48:01 CSC-NAS crond[2639]: failed parsing crontab for user root: 04**** /usr/local/emhttp/plugins/user.scripts/startCustom.php If you intended for it to be 0 4 * * *make sure you correctly add the spaces and/or remove the trailing * as you have one too many. https://crontab.guru/

If you're manually moving files from diskA to diskB, the share settings will not take effect. The share settings only apply when using unraid's automated tools such as mover or when writing files to a share via FUSE (/mnt/user/...)

Almost two hours? That makes no sense. Are you sure it's actually taking that long and you're not just staring at a stale screen? I suspect faulty hardware, have you checked your disk logs or diagnostics?

Always make a backup of your appdata. It can be extremely risky changing the docker branch and rolling back my not always be possible due to technical reasons like one way data migrations. This is why a backup of your appdata is critical. To make the change you simply edit the docker container template, expand to advanced view, and edit (or add) the docker branch tag to the end of the repository: In the example below the tag is the whole part after "plex" :latest so in this case latest is the tag. You will need to figure out what tag was used and append it. You may or may not have a tag, if you don't you will need to add the semi-colon+tag. (then click update) If the action is unsucessful or the docker run says failed, your container will be orphaned, you will need to click on the "add container" button, click on the corresponding template, and fix it and run it again. Here is another example with a custom tag specific for this container:

Sounds like you either didn't actually create the 7.2.0 flash drive or you copied over all the old files from the 4.5.4 flash backup you created instead of the supter.dat and .key files

for this application, it really doesn't matter since the data is moving off of the cache pool. Setting array as the primary storage is probably the safer choice so that way when the cache pool is removed, it will already be defaulted to array. The only critical component is the mover action direction. Currently you have many shares pointing to the cache pool, make sure these are corrected. (yellow = bad, green = good)

Stop Docker/VM services from the unraid settings menu. Assign each share so that each share has the secondary storage assigned, then set mover action so that data is moved from cache -> array and run mover. (note the specific order here) once all shares fully reside on the array, you can remove the cache pool by clicking on the pool name from the Main page, and clicking "remove pool" (array must be stopped)

Nov 3 10:29:54 BoozHSVR kernel: [Hardware Error]: Corrected error, no action required. The error was corrected. Should not result in any issues. (Ill be honest I get one of these types of MCE's per boot on my machine) Edit: Just noticed that you have many of these flagging through out the syslog. You may want to consider replacing the hardware, either ram or CPU. Most likely CPU related. Looks like the cache or memory controller is not happy.

If the minimum free space (share floor) is set to 98GB, this tells unraid that it is acceptable to write a file to that disk as long as there is 98GB of space left. This setting does not keep 98GB of unused disk (unless all your new files happen to be larger than 98GB and you never write a file smaller than 99GB to unraid). What happens is if you have a 98GB file, unraid will write that file to the disk leaving you with 0GB of space. Which is exactly what happened and why you now have 28.7kb left on that disk. If having this little bit is not something you desire, typically setting the min-free space to something like 200GB is what you should aim to do in the future. Also I would recommend using the "Unbalanced" plugin to "scatter" some files from your full disk to other disks.

The solution is to move the data over, new files should be wrote to the new storage location. Existing files being modified wont be moved regardless of what storage pool you selected in the share settings. Stop/Disable docker service in the unraid settings. Set cache_data as the secondary storage for your system share and then set the mover action so that the arrow points to cache_system from cache_data so that it looks like cache_data -> cache_system and run mover.

With using br0 networking, and not enabling host access, traffic through NPM will be able to access your LAN network EXCEPT for anything running on unraid. Unraid becomes a black hole until you enable it. IMO there is zero need to even use br0 networking or assigning custom IPs for individual containers.

As long as everything is under one parent share you're good. This will permit hard-linking (after you enable hard-links) or atomic moves for files between the sub-folders in that parent share.

Needs kernel 6.14, unraid is on 6.12. Once unraid moves to the next LTS kernel it should have everything working with maybe the exception of the SR-IOV stuff.

Im pretty sure it's normal due to it being technically a disk share at that point unraid is just chainging it in the webgui. Ive noticed this behavior as well.

Need to post diagnostics

No. It has nothing to do with internet or servers, it runs a daemon that communicates to your UPS.

Install the NUT plugin and try that (not a NUT server)