Faceman

Yes I've also noticed xvnc is running with the ipgu active, can that be configured or disabled?

I also noticed the editor had stopped working, I was able to make a new folder with JSON but couldnt edit or make new ones from the ui, I cant be terribly helpful since I cant say how long it's been like that because I haven't had to change my folder setup since folderview 3 was first spun off. However, I just rebooted my system to move to 7.3 RC2 and its working again, perhaps just a reboot was in order, or perhaps something was broken in RC1

14600 is a decent chip for everything. since you already have a GPU you could get an F variant to save a few dollars, but having no igpu can be annoying for troubleshooting or when you want to offload some action from the B580 to something lower power for background use. performance difference between base 14600 and 14600K for a home server build isnt particularly relevant unless you need a lot of single thread high clock performance for things like game servers etc, even then its not a huge difference. I'm on a 14600K (it was cheaper than the non-K at the time due to a sale, and I wanted an IGPU since I didnt have PCIE space free for a dGPU) and just have it power limited in the Bios just a bit (PL1 is set to 80W rather than 125W, PL2 is currently 180W which I think is stock for that chip) to keep it happy as it is a chip on the caution list for potentially nuking itself. More than enough grunt and core count for what I do with it, and I have 41 containers currently running doing moderately heavy media operations, image recognition, audio recognition, hosted cloud services with a dozen users etc.

clear your cache, that worked for me.

How did you move it? if you moved the file itself but didnt point docker to the new location, go to Settings/DockerSettings, disable docker, then change the location of the docker vdisk to your new location. if you changed the location in docker settings but didnt move the file, it has created a new empty docker image at the new location and you will have to find the old file and copy that to the new location, overwriting the empty one. then re-enable docker.

There is a way to empty a disk from the webUI now, but it does the move according to share settings, rather than forcing the move to one disk, but that should still work in most users cases. Unbalance plugin does make it easy and safe too, probably the safest option if you've never done these operations manually before, but I've always just done it in MC and manually copied each share folder, one at a time, disk to disk in there (probably safest to do this in maintenance mode to ensure nothing is trying to access the files), ensure the files are good and safe, then delete the originals or just remove the disk via new-config as is when copied completely. I do always to a copy then delete rather than a move just to be safe if something goes wrong during the operation, no unraid doesn't want you to have duplicate files but it does handle them just fine and they are temporary.

I did something similar recently by swapping one disk and rebuilding onto that, then emptying the second disk to the new disk and removing it from the array via new config, that opens up a slot to use for a new second parity. Do you have a second 18TB disk to add as the second parity?

the "AI" didn't mention checking the share.cfg files? broken share.cfg files are one of the most common causes of "mover not working" issues at the moment.

sometimes that selection drop down gets confused and you need to save the settings, reload the page then check it again and you will see it unlocks more options. In your case, you would want to run the mover schedule fairly frequently (I do hourly, but you do you) have your threshold at 80%, free down to level set to 70% and file age set to AUTO. this will check the fill amount every time the mover is triggered, if 80 or higher it will start moving files, oldest first (mostly, file dates can be changed/modified in some cases), until it reaches 70% fill, then it will stop and wait for the next mover trigger. if the cache pool is under 80% it just skips everything and doesn't do anything until the scheduler runs it again. your appdata share is locked to the cache so it will never be moved, but it does still count to the usage as far as I know, so keep that in mind.

Last I checked you would need to build a special FFMPEG with VVC (H.266) encoding enabled as per documentation here, it's still a very, very new codec and is extremely poorly supported. AV1 is better at the moment if you want to churn some CPU cycles for something you can actually play back, HEVC is almost as good and much more widely compatable. look at applications like Fileflows, Unmanic or Tdarr to automate those processes on your server.

leave it for a while. mine did that too. took hours.

I use a different container for JF, but my update to 10.11 took about 5 hours. very little CPU usage so dont be thrown off by that, I knew it was working on the database. It was live fairly quickly, but unusably slow until it had completed the migration a few hours later.

its a bit of a general Linux / rsync in particular thing, not really an Unraid issue specifically, though symbols in filenames is a general no-no for most OSs. it can be worked around but the dev of the mover tuning plugin hasn't gotten to that yet. for now, try to avoid symbols in filenames, or use the stock mover. I just handle them manually when they do pop up, it's rare but it happens.

You have mover tuning plugin running, so you can check for files with symbols in their names using the validation option, Top Gear US S02 has an episode called "The $500 Challenge" which will fail to move due to the '$' symbol. the default unraid mover should move it though, you can configure move tuning to use that if needed. either rename them, or move them manually.

My motherboard has a similar thing, but it is just that the board was designed with some unused PWM channels. it shows 5 PWM channels (labelled 1,2,4,6,7 just for fun), has 4 physical ports, but only 3 can be fully controlled. In my case, one of them is labelled CPU_OPT on the board which can have its RPM read independently of the CPU_FAN pin, but its PWM value cant be set separately as far as I can see. The Bios treats both of those as one, but with two RPM readouts. the other unused PWM channel on my motherboard is simply not there at all, a higher end version of the same motherboard has an extra connector for chassis fans.

7.2 shaping up to be the most solid release in a long while in my opinion, not a jab at the previous releases of course, but it's good sign of another solid stable landing point for the few that have been hanging onto older versions for a little too long.

I can see the issues you mentioned with the CPU and RAM, but mine do work fine when the folder is opened, they dont work for the total when a folder is minimised. That's pretty minor. There are minor rendering issues due to the responsive UI changes, but for the most part it renders properly on my screen, and mobile.

current manually installed version is working for me on 7.2b3 nothing seems broken.

You have your mover direction for the Appdata and System shares set to move data off the cache to the array (Cache -> Array), but then you also have Docker and all applications looking only at the cache directory for it's image file (/mnt/cache/system/docker.img) and appdata location (/mnt/cache/appdata/) This means that while it may have worked at first, the mover would have started pulling data away from where the system was expecting it to be and things would start to break quickly. So the solution here is to disable docker temporarily (so we can move things freely), change your mover direction for the appdata and systemshares to pull files from array to cache (Array -> Cache), force run the mover and let it run, then ideally you should set the appdata and system shares to use cache only, no secondary storage, no mover, so that those files stay where they need to stay. you can use the appdata backup plugin to regularly back up the appdata folder to the array for safe keeping.

I have it on a separate server because HAOS runs a lot of essentials (mainly AV control sequencing for a complex whole-home video distribution setup with 8 TVs, 4 users, ~14 sources, and all the power, control, input and room lighting, climate, fans, etc that go with all of them) and I cant have that system go down if I need to reboot my server or shut it down to work on it. Having a second device also helps with never losing DNS when one goes down, even if its just a few seconds to run an update. HAOS is backed up to unraid daily, and I can pretty quickly spin up a HAOS VM with that backup if the Pi dies. So while I've consolidated pretty much everything else down to just unraid and mostly gotten out of the homelab side of things, I still need some services to be separate or duplicated to minimise downtime. The spare NUCs are still in use as regular desktops.

last year I consolidated most of my homelab back down to the single unraid box, used to be my main unraid server, my old dual xeon box plus a pair of mini-pcs running proxmox for a handful of applications and vms mostly idling 24/7 eating power but now it's just the main unraid box and a Pi for HAOS (also runs nodered, secondary DNS, mqtt, etc). so my server is a 50/50 storage and services, and I don't even run any 24/7 VMs anymore as the one windows application I needed now runs in a container with wine, and I can spin up a linux or windows instance if needed in about 5 seconds.

I'd suggest rolling back to 7.1.4 for now. looks like a Linux kernel issue with the XE driver that is affecting the latest Beta, we will have to wait for a newer Kernel to have that fixed.

just gotta pipe in here and and say Freelancer was such a great game..

Also it looks like there is one long SATA power cable with multiple joiners coming out of the back of the PC down to the HDD cage, that is guaranteed to be worsening the issues due to massive voltage drop, even before all the daisy chained power splitters come in. I had similar issues in one of my earlier DIY builds and it also turned out to be a power issue due to too much daisy chained power splitting, easy fix with some re-wiring to better branch out the splits from the PSU evenly and minimizing the length of cables.

Is your docker image full? The logs look like that might be the case.