Super flustered about this, so I'm finally posting diagnostics. I just upgraded to 7.2 (from 7.1) with latest nvidia driver and it hasn't helped. I always have at least 30 parity corrections written to disk on every. failed. shutdown.

I do not wish to go to v7.3. I was more stable on v6 and I'm anxious about the updates causing this.

This particular failure, I couldn't see the remote screen with my kvm. Any thoughts/ suggestions would be welcome, I'm absolutely exhausted. It also keeps wiping out my docker.img and I have to rebuild (service could not start). I've opted to do direct to disk to stop this from happening. Probably the most intensive process I have running is Frigate, which is pretty light on CPU when using coral + nvidia graphics card.

uhive-diagnostics-20260712-1210.zip

Regular syslog starts over after every boot, enable the syslog server and post that after the next crash.

Are you using a docker folder instaed of docker.img vdisk?
If you are using a docker folder, your docker folder disk is 86% full and is likely filling up crashing the system.

also it appears you have two shares named "docker" but one of them uses a capital D and if that is the case your /mnt/user/Docker share is running on disk2 and not your cache pool

d----r                            shareUseCache="only"    # Share does not exist
D----r                            shareUseCache="no"      # Share exists on disk2

Cant say for sure this is the cause of the crashes, but I would start here and get my system in order if this was not the intended destination.

Typically when a disk or ram fills up where system services run, it's bad news.

Edit, nvm I see you did move it to your disk2 on purpose, in that case you might want to check the cache drive health and/or check to see that you are not filling the cache drive/pool completely which can crash the docker service and/or corrupt the docker stuff.

Edited July 13Jul 13 by MowMdown

uhive-diagnostics-20260712-1210-PRE-RESTART.zip

Just now, moka939 said:

Did this just strip out all of my text and fail to upload the cache image?

Replying again since the text didn't send.

The logs are from /boot/logs. Several logs in there, the one from 0712 doesn't appear to have been overwritten. The log attached is BEFORE the system was rebooted, copied to the new zip file. terminal was responsive on the unraid gui, but the FF ui was not. The server could not be reached when it was in this state. It did not respond to a restart command.

To answer questions, Docker with cap D is set to cache, not disk, I don't know why you are seeing otherwise. The cache is a 1tb ssd with 256 used and I've not really seen more than about 256 usage on it. Yes, I stopped using vdisk because I had to rebuild it so frequently it wasn't worth it.

4 minutes ago, moka939 said:

Did this just strip out all of my text and fail to upload the cache image?

Replying again since the text didn't send.

The logs are from /boot/logs. Several logs in there, the one from 0712 doesn't appear to have been overwritten. The log attached is BEFORE the system was rebooted, copied to the new zip file. terminal was responsive on the unraid gui, but the FF ui was not. The server could not be reached when it was in this state. It did not respond to a restart command.

To answer questions, Docker with cap D is set to cache, not disk, I don't know why you are seeing otherwise. The cache is a 1tb ssd with 256 used and I've not really seen more than about 256 usage on it. Yes, I stopped using vdisk because I had to rebuild it so frequently it wasn't worth it.

6 minutes ago, moka939 said:

uhive-diagnostics-20260712-1210-PRE-RESTART.zip

Unsure why I can't see the body of my response unless I quote myself. Odd.

1 minute ago, moka939 said:

To answer questions, Docker with cap D is set to cache, not disk, I don't know why you are seeing otherwise. The cache is a 1tb ssd with 256 used and I've not really seen more than about 256 usage on it. Yes, I stopped using vdisk because I had to rebuild it so frequently it wasn't worth it.

What I suspect happened is you have Docker and docker, linux is case-sensitive, FAT32 is not case-sensitive. Unraid is randomly picking one and applying it's settings.

Docker.cfg is set to cache and docker.cfg is set to cache or something of that nature. In fact Docker.cfg doesnt even have proper share settings where docker.cfg does. This issue isnt the source of your problems BUT you should address it by clicking on "Clean up" from the shares tab/page. Then clicking on the docker share and validating the settings, hitting save on your way out to properly apply them.

disk2 also contains docker folders so you should do some housekeeping to make sure youre using the right docker stuff.

6 minutes ago, MowMdown said:

What I suspect happened is you have Docker and docker, linux is case-sensitive, FAT32 is not case-sensitive. Unraid is randomly picking one and applying it's settings.

Docker.cfg is set to cache and docker.cfg is set to cache or something of that nature. In fact Docker.cfg doesnt even have proper share settings where docker.cfg does. This issue isnt the source of your problems BUT you should address it by clicking on "Clean up" from the shares tab/page. Then clicking on the docker share and validating the settings, hitting save on your way out to properly apply them.

disk2 also contains docker folders so you should do some housekeeping to make sure youre using the right docker stuff.

Thanks! I ran that and it cleaned up something.

1 hour ago, MowMdown said:

What I suspect happened is you have Docker and docker, linux is case-sensitive, FAT32 is not case-sensitive. Unraid is randomly picking one and applying it's settings.

Docker.cfg is set to cache and docker.cfg is set to cache or something of that nature. In fact Docker.cfg doesnt even have proper share settings where docker.cfg does. This issue isnt the source of your problems BUT you should address it by clicking on "Clean up" from the shares tab/page. Then clicking on the docker share and validating the settings, hitting save on your way out to properly apply them.

disk2 also contains docker folders so you should do some housekeeping to make sure youre using the right docker stuff.

I did some housekeeping, thanks for suggestions. appdata folder had the same issue so I cleaned that one up, but the Docker share cannot be deleted, and settings can't be changed (maybe it is required, I can't recall defaults). I'm unable to do anything with folder on disk2 and clearly unraid sees it as existing on that disk from the pic I sent even though it says it is on cache (shows protected whereas cache is not). Strange. Anyhow, I moved my docker disk contents to docker-direct which is what I originally intended (correctly shows unprotected and on cache). In terms of speed, it is fast as I initially expected (it was not fast before, downloads took ages). I'm concerned about Unraid lying to me on that Docker share.

I doubt I'm out of the woods at the moment, so hopefully those logs reveal more about the cause of the crashing.

Edited July 13Jul 13 by moka939

you might have to manually go into /boot/config/shares and delete the docker.cfg or Docker.cfg

Docker.cfg didnt even have share settings, so I suspect this tried to create itself and failed. Probably easier to delete both and reboot and then correct the settings.

On 7/13/2026 at 11:31 AM, MowMdown said:

you might have to manually go into /boot/config/shares and delete the docker.cfg or Docker.cfg

Docker.cfg didnt even have share settings, so I suspect this tried to create itself and failed. Probably easier to delete both and reboot and then correct the settings.

Confirmed this is no longer an issue after completely wiping out Docker share. the docker.cfg and Docker.cfg do not exist at all, just the new docker-direct.