FlexibleToast

Btw, at least for Ollama specifically I did have to leave the --gpus=all otherwise it never saw the GPU. I think that is on a per container basis though because it seems like some others did not need it.

I removed the --runtime=nvidia from my Ollama's "Extra Parameters" and it seems to work just fine. It's even still using the GPU. I did leave the --gpus=all but, I don't know if that is needed.

I think you're having the same issues I'm having. Is that one container using the Nvidia runtime? All of my Nvidia runtime containers fail to start with that same error. I made sure I have the latest Nvidia driver.

Or at least semi random. They seem to happen occasionally when I'm running AI inference workloads like Ollama. I'm suspecting it's heat related, but this time the room was relatively cool. Like the room was cooler than it usually is. Is there any insight in this diagnostic as to what caused the last reboot? It just happened right before this diagnostic was pulled.kerbol-next-diagnostics-20250920-2100.zip

That's not a bad idea. It will take a little bit of planning now that I'm using the Nextcloud AIO container that uses docker storage. Granted, that's what the borg backups are for I suppose. Thanks for the help on this. Glad it was as simple as just a drive (not even one in the array) causing issues. Since that drive is just there as a local backup, I'm wiping it now and starting fresh.

I agree with your assessment. However, I used to use the docker image in the past (it is the default after all). That image got corrupted and while it was relatively easy to recover from because all the container settings were saved by Unraid, it was annoying to have to do. That's when I switched to the folder method. I also, didn't realize at the time it would use the ZFS driver and create all those snapshots. That's the "I realized that my sanoid/syncoid settings where messed up". On top of docker creating lots of snapshots, sanoid/syncoid where also creating a bunch of snapshots and causing general havoc. Now I have system/docker excluded from those tools.

That seemed to be it. I rebooted the server and it was back up and array started in 10 minutes... Guess I need to come up with a different way to store local zfs snapshots.

Oh, the settings finally opened. I've turned off automount. I'll try rebooting later tonight when I'm not about to watch Plex.

I think you're on to something, because I can't. I can't umount it because target is busy. If I try to lsof the mount I get spammed with lsof: no pwd entry for UID 1001 and various other UIDs. I realized that my sanoid/syncoid settings where messed up and where essentially stuck running. In the UI I've tried pressing the cog next to the device so I can change the automount setting, but it never opens...

Yes, that diag is directly after that boot. I can tell you that my array wasn't actually started until about 10:36, that's when docker finally came online and my containers came back up. It sounds like the disks and pools are working as expected, but for some reason the array is taking a really long time to form/start.

This is getting brutal. Something caused the system to hang last night around 00:30. I had to reboot it and it took 1:40 for the array to come up. Nearly 2 hours, that's wild. I'm thinking of going back to Proxmox as my homeserver, virtualizing unraid, moving all/most of my docker stuff off to a different vm, and let unraid just be storage. kerbol-next-diagnostics-20250910-1040.zip

It's weird that I didn't get the notifications for updates. I'm on v7.1.2 now and it still doesn't work.

I swear I had this working in the past... I'm positive at one point Plex was using hardware transcode just fine and now it seems nothing can use it. Relevant specs/info: Intel i9-12900KS Unraid 7.0.1 Intel-GPU-TOP app installed Relevant containers have `--device=/dev/dri:/dev/dri` as extra params I suppose I first noticed with tdarr that QSV wasn't working. That would have been around March 2nd. I didn't think much of it, but now after setting up Jellyfin I really started to look into things. I installed intel-gpu-tools in the Jellyfin container and `intel_gpu_top` would error and not find any GPUs. I then looked in `/dev/dri` and renderD128 is there along with card0. I tried the same thing on the Unraid host and it didn't work. I even tried modprobe i915: root@Kerbol-Next:~# modprobe i915 root@Kerbol-Next:~# intel_gpu_top No device filter specified and no discrete/integrated i915 devices found root@Kerbol-Next:~# ls /dev/dri by-path/ card0 renderD128 I'm not sure what else to look for and test? kerbol-next-diagnostics-20250508-0930.zip

Correct, but that docker.img is on ZFS.

I haven't. But, we're talking a ZFS pool here. ZFS won't just barf out corruption like that. That shouldn't be the problem, but I should check anyway.

I didn't run out of space. It got corrupted. I was hoping the directory would be better because I've never had issues with containers before. My day job is an OpenShift consultant, so I do a lot of container work...

It's not the browser that's the problem. Services that wait on the array also don't start. It took 1h05m to start this morning. My containers seem to have gotten thrashed too. I switched docker from an image to directory mode. I good amount of the containers were broken after the reboot. Recreating the containers worked just fine. So the images were fine, but the live overlay got wrecked. This system is starting to feel really fragil. I'm getting tempted to just run Unraid in a VM or something and let it just handle storage.

Months later and on 7.0.1 this is still an issue. The array takes ~1 hour to start. Recently now if I disable docker and then try to re-enable it, it basically locks up the system. I guess luckily I only boot ~once a month for updates.

I have ublock origin and decentraleyes. You think it could be the web app itself? I just added the server to the ublock whitelist.

So, I walked away to finish making dinner and it is now showing "Array Started". When I walked away I think it was 20+ minutes and still starting. That means at some point between 20 minutes and 1:20 hours it finally is started. It's an egregiously long time to start the array. You see the array as up in the logs because it kind of was. I could navigate to it at `/mnt/user`, but it was still showing "Array Starting" and wouldn't have allowed starting of VMs or Docker.

I figured there was some report like that I needed to get. I'll remember that for next time as well. The server had been up for 35+ minutes still "Starting" so I did shut it down all the way instead of a reboot. Sometimes a cold boot is a little different than a warm boot in my sysad experience. Anyway, it's up for 16 minutes right now and still "Starting" so I think the problem has persisted. kerbol-next-diagnostics-20250123-1733.zip

I'm fairly new to Unraid and I dread having to restart or upgrade my Unraid server because it takes so long to boot. I just upgraded from whatever the latest 7 rc was to the full 7 release. It came up pretty well that time. For some reason the array seemed to just stop working. I couldn't even cd into /mnt/user, but I could go into any individual disk/pool. So, I restarted the server. According to the logs, that was 25 minutes ago and it is still "Array Starting", heck the last thing that happened in the logs was spinning down one of the disks it's been taking so long! I even shut down the VM and Docker services before rebooting this time. I don't know what to do at this point.

@binhex I can't figure out how to get this to work with docker on the Unraid host. I've tried both the `/var/run/docker.sock` and by ip `192.168.10.20:2376`. Both methods seem to encounter permission issues. First I passed through `/var/run/docker.sock` to the container by adding it as a path. If I try to add a docker cloud as `unix:///var/run/docker.sock` I get permission denied So, I tried the other method based on previous replies in this thread. First I modified the `/boot/config/docker.cfg` file and added `DOCKER_OPS="-H unix:///var/run/docker.sock -H tcp://0.0.0.0:2376"`. I then rebooted Unraid so it would start docker with this options. I then changed the setting to `tcp://192.168.10.20:2376` and get a connection refused. I am stumped on how to get this to work. I want Jenkins to build container images. Without it being connected to docker I don't think it can do that and it makes it useless to me...

I forgot to report back on Friday. I did the recommended uninstall, reboot, reinstall and now everything appears to work as expected. Thanks for the help.

To be clear, the running state it is in right now works. I followed the upgrade messages that said not to reboot until I receive a notification saying it was okay to. I can get the screenshot of the plugin page, but like I said I travel for work and I don't want to reboot a working system while I'm away. I can do that part of the troubleshooting Friday.