joelones

it appeared to be the usb_manager plugin causing the array not starting, closing.

Sorry by what is your question? I'd like to stop the array manually to test something and then bring it up manually. The problem is that it doesn't come up. That's the problem. There's no indication in the log why the array could not come up. It's terrible from a user experience perspective that there's no warning or visible error. I'm spinning in circles with this now.

I will try but what would booting in safe mode confirm? Does it have something to do with this error? No internal boot setup detected. Launch Internal Boot to configure one. Would this prevent the array from starting once I stop the array ? If so why is this happening? And why would the array come up fine on reboot?

Running 7.3.1 and it appears that while stopping and then starting the array manually, the array does not come up. Seems fine on a complete reboot. I see this in the log. Thoughts on what might be going on here? emhttpd: cmdStart: already starting clarabell-diagnostics-20260603-1136.zip Maybe this go be the culprit? I also see a stale reference to vm directory, not sure how to remove this reference, is it in the img file? 2026-06-03 15:26:54.398+0000: 14020: info : libvirt version: 12.2.0 2026-06-03 15:26:54.398+0000: 14020: info : hostname: clarabell 2026-06-03 15:26:54.398+0000: 14020: error : virDirOpenInternal:3163 : cannot open directory '/mnt/user/kvm/domains/windows7': No such file or directory 2026-06-03 15:26:54.398+0000: 14020: error : storageDriverAutostartCallback:213 : internal error: Failed to autostart storage pool 'windows7': cannot open directory '/mnt/user/kvm/domains/windows7': No such file or directory 2026-06-03 15:26:56.705+0000: 14020: warning : qemuDomainObjTaintMsg:5727 : Domain id=1 name='windows10' uuid=589b80db-794f-9069-8df3-49347dab4887 is tainted: high-privileges

Thanks. But what you're saying is to rollback to a previous version of my containers exhibiting this issue? But the problem seems unraid / GUI related, no? Not sure sure I want to rollback my containers., interesting though, I'm having problems with some binhex containers too but they did communicate with each other despite the GUI anomaly

Thank you for your help anyway.

Thanks for the help. tried recreating / removing the custom network a bunch of times, whenever I set the driver to macvlan it doesn't appear in the gui...why it does it for some dockers on the same custom network and not others is a real mystery

How does one recreate the custom network? I think my 192.168.10.1/25 network br1.10 was automatically created when I created a bridge on eth1 with a specific VLAN. I tried using the UI to uncheck the docker network (restarted) and then recreate it, not sure if this is the right way (see screenshot) but it did not change anything.

No they don't. Makes no sense to me. I did a normal downgrade via the UI, no dice. Then I actually took a backup of the USB before I started and overwrote the UNRAID USB and still the same. So confused

I'm also experiencing this after installing 6.12.11 for some reason: help?

Just upgraded to 6.12.11 and now some of my IPs for docker on a custom network don't show in the GUI and link goes to about:blank#blocked. Can someone please shed some light here? Why it is all of a sudden happening to some but not all customer IP containers ? Deleting the docker.img and containers does nothing.

I'm still on 6.12.3 and would like to upgrade but facing multiple issues upon trying 6.12.6. Any guidance would be appreciated. The Intel GPU CometLake-S GT2 [UHD Graphics 630] fails to load upon bootup thus the Jellyfin docker fails to start as it is used for gpu transcoding My Windows 10 VM with a pass-through nvdia quadro fails to start All is fine on 6.12.3. Thoughts? clarabell-diagnostics-20231206-1504.zip

I'm trying to the new UniFi Network Application container and getting a tomcat 404 error using a custom bridge setup. Previous container works well with this setup. Can anyone please advise (unraid 6.12.3)

Just tried it again today, same issue same call trace

No I reverted back to 6.12.3 which is working fine. I would add this as the following: mkdir -p /boot/config/modprobe.d echo "options i915 enable_fbc=1 enable_guc=3" > /boot/config/modprobe.d/i915.conf mkdir -p /boot/config/modprobe.d echo "options i915 enable_dc=0" > /boot/config/modprobe.d/i915.conf what does this do? for 6.12.3, no need to add the modprobe lines, it just works. odd