Hello,

This is my first forum thread, so please be gentle if I make any missteps!

I have had my Unraid server running relatively smoothly for the last few months, but recently (ie. in the last couple weeks), I have been noticing an increase in the frequency of my Docker applications stopping. When I click on the application to try and start it again, I get an error message. The only way to get them running again is with a system reboot.

For context, I only have 4 Docker apps running: binhex-emby, binhex-plexpass, binhex-sabnzbd, and netdata.

Typically, by the time I realize the Docker apps have stopped (usually because I launch Plex on a device and it cannot connect to the server), they have either all stopped or at least 3 of the 4 (in these cases, I have noticed binhex-emby is usually the one that has not stopped). Again, reboot is the only way to fix.

Yesterday, the above happened, and when I went to check the system, it was only netdata that had stopped. Even though the other 3 apps were still running, Plex could not see the server. As per usual, I attempted to reboot, only this time, the reboot process got stuck on repeatedly trying to stop the array... after a couple minutes, I manually powered off the server with the power button. After restarting, the system booted with the array offline and reporting that it could not find the cache disk. Indeed, the cache disk was not listed in anywhere as a device. So I initiated the reboot process again, and it proceeded smoothly... the system restarted normally with the array and cache disk present as it should be. 24-hours later and there has been no hiccups yet.

I just downloaded the syslog file and have attached it to this post. I will be honest in saying it is beyond my understanding, so I am hopeful this forum will apply it's vast wealth of knowledge. I will do my best to answer and follow all questions, comments and instructions to provide anything further.

Thank you in advance to all.

syslog-192.168.2.61.log

Attach Diagnostics to your NEXT post in this thread.

Diagnostics Attached... thank you.

tower-diagnostics-20250529-1547.zip

Your system share has files on the array. In fact, it is configured to be moved to the array.

Best if your "default" shares have all files on cache or other pool, with nothing on the array, so Docker/VM performance will not be impacted by slower array reads and especially writes, and so array disks can spin down since these files are always open.

https://docs.unraid.net/unraid-os/manual/shares/user-shares/#default-shares

Nothing can move open files, so you have to disable Docker and VM Manager in Settings before you can work on these shares.

Hey trurl,

Thanks for the feedback.

Judging by the link you provided, am I safe to assume the default shares you are referring to are "appdata", "system", "domains", and "isos"?

If so, are you recommending they all be on "Cache" for the "Primary Storage" setting, and "None" for "Secondary Storage"? Because they are all set to "Cache" for "Primary Storage" already, with only "appdata" being "None" for "Secondary Storage". The rest of the shares have "Array" for "Secondary Storage", with "Allocation Method" set to "High-water"... If memory serves, I set them up this way following a Tutorial where my understanding was the "Array" for "Secondary Storage" was for backup purposes and were only written when "Mover" was initiated/scheduled.

In terms of function, do they not run effectively run exclusively from Cache when setup this way? Or was my understanding in error? If you are suggesting this might be the contributing to the crashes, should they be changed to "None" for "Secondary Storage"? Wouldn't that put the server at risk if there was a Cache drive failure?

Apologies for the repetitive details... just want to be 100% clear.

Thanks again.

Mover ignores all shares that don't have a Mover action specified.

Set each of the default shares to

Primary:cache; Secondary:array; Mover action:array->cache

On 5/29/2025 at 6:45 PM, trurl said:

Nothing can move open files, so you have to disable Docker and VM Manager in Settings before you can work on these shares.

Then run mover, wait for it to complete, post new diagnostics.

These details are unlikely to cause crashes though.

Hey trurl,

Just wan to clarify your instructions here:

26 minutes ago, trurl said:

Set each of the default shares to

Primary:cache; Secondary:array; Mover action:array->cache

In particular, the "array->cache" option... the Mover description says it moves from Primary to Secondary... but if I set it as you say, would this not be contrary to how it works? Or is this intentional?

Thanks again.

4 minutes ago, Minawee said:

the Mover description says it moves from Primary to Secondary... but if I set it as you say

Does it not change the description when you do as I say?

19 hours ago, Minawee said:

In particular, the "array->cache" option... the Mover description says it moves from Primary to Secondary... but if I set it as you say, would this not be contrary to how it works? Or is this intentional?

Mover moves in the direction you specify for mover regardless of what any help text might say.

On 6/5/2025 at 12:40 PM, trurl said:

Does it not change the description when you do as I say?

Indeed it does... thanks for clarifying... will do so and report back.

Changes made... diagnostics attached!

tower-diagnostics-20250607-1841.zip

Those diagnostics shows Docker and VM Manager are enabled.

On 5/29/2025 at 6:45 PM, trurl said:

Nothing can move open files, so you have to disable Docker and VM Manager in Settings before you can work on these shares.

Your system share still has files on disk7