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.

Attach Diagnostics to your NEXT post in this thread

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

Looks like the array is started in those. Didn't notice anything wrong. Post a screenshot of MAIN - Array Devices

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.

 

Edited January 24, 20251 yr by FlexibleToast

Do you have adblocker or anything else that might interfere with browser?

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

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.

Have you tried just refreshing the browser?

 

What happens if you boot in GUI mode with an attached keyboard and monitor?

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.

3 minutes ago, FlexibleToast said:

switched docker from an image to directory mode

That isn't usually a solution. I didn't notice in your earlier diagnostics that you had 100G specified for docker.img. Have you had problems filling it? The usual reason for filling docker.img is an application writing to a path that isn't mapped. Making it larger won't fix that, it will only make it take longer to fill.

17 minutes ago, trurl said:

That isn't usually a solution. I didn't notice in your earlier diagnostics that you had 100G specified for docker.img. Have you had problems filling it? The usual reason for filling docker.img is an application writing to a path that isn't mapped. Making it larger won't fix that, it will only make it take longer to fill.

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...

5 minutes ago, FlexibleToast said:

It got corrupted

That isn't something that happens by itself.

 

Have you done memtest recently?

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.

16 minutes ago, FlexibleToast said:

I didn't run out of space. It got corrupted. I was hoping the directory would be better

docker.img is btrfs

1 hour ago, trurl said:

docker.img is btrfs

Correct, but that docker.img is on ZFS.

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

Are those diags after that boot? Not seeing any issues, the server booted at 08:47:55 and at 08:50:37 all disks and pools were mounted.

2 hours ago, JorgeB said:

Are those diags after that boot? Not seeing any issues, the server booted at 08:47:55 and at 08:50:37 all disks and pools were mounted.

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.

Edited September 10, 2025Sep 10 by FlexibleToast

I do see some strange messages for the unassigned disk you have set to automount. Disable automount for that disk, reboot, and see if it starts normally.

16 hours ago, JorgeB said:

I do see some strange messages for the unassigned disk you have set to automount. Disable automount for that disk, reboot, and see if it starts normally.

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...

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

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.

I think that there may be too many snapshots/datasets on that disk, and it's taking a long time to mount them. Recreating the pool may help, at least initially. One of the issues may be the Docker folder backups, since it's using the native ZFS driver, it can create hundreds, if not thousands, of legacy datasets.

I recommend recreating the folder with the overlay2 driver, or better yet, and image isnatead, suince docker folders can sometimes cause strange issues.

48 minutes ago, JorgeB said:

I think that there may be too many snapshots/datasets on that disk, and it's taking a long time to mount them. Recreating the pool may help, at least initially. One of the issues may be the Docker folder backups, since it's using the native ZFS driver, it can create hundreds, if not thousands, of legacy datasets.

I recommend recreating the folder with the overlay2 driver, or better yet, and image isnatead, suince docker folders can sometimes cause strange issues.

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.