tower-diagnostics-20260702-1452.zip

In the syslog.txt file it states that the server ran out of memory so it killed shfs.

Jul  2 14:45:57 Tower kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=shfs,pid=14909,uid=0
Jul  2 14:45:57 Tower kernel: Out of memory: Killed process 14909 (shfs) total-vm:1371552kB, anon-rss:958604kB, file-rss:60kB, shmem-rss:1464kB, UID:0 pgtables:2036kB oom_score_adj:0

Does unraid not restart this process automatically?

If not, should it not since it is critical to the base functionality of Unraid?

The main reason for the high ram usage I suspect is my two new ZFS drives I added to the array. I thought that 48 GB of ram for 28 TB of ZFS would have been enough, but I guess not.

Other than that, can anyone figure out what was the other source of high ram usage before the crash based off the diagnostic?

Unlikely to be the ZFS drives - more likely a docker contaoiner.

You are likely to get better informed feedback if you attach your system’s diagnostics (with everything in the one zip file) to your next post in this thread. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

shfs was just the victim; you need to figure out what caused the OOM, a container like mentioned is a good suspect.

12 hours ago, Gray J said:

The main reason for the high ram usage I suspect is my two new ZFS drives I added to the array. I thought that 48 GB of ram for 28 TB of ZFS would have been enough, but I guess not.

ZFS doesn't "need" the RAM, it just uses it if some is available and frees it when something else needs it.

On 7/6/2026 at 2:23 PM, itimpi said:

Unlikely to be the ZFS drives - more likely a docker contaoiner.

You are likely to get better informed feedback if you attach your system’s diagnostics (with everything in the one zip file) to your next post in this thread. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

My post states that it has the diagnostic's zip attached as the very first item. Does it not show for others?

On 7/6/2026 at 11:48 PM, JorgeB said:

shfs was just the victim; you need to figure out what caused the OOM, a container like mentioned is a good suspect.

only problem is that I don't run any containers on this server. I do use copious plug-ins though.

Perhaps one has a memory leak...

As a temperament solution, is there any way to bring shfs back online via a script?

I was thinking of having a script that runs every few minutes that checks uses a conditional like:

lines <= ``ls -la /mnt/``
for ln in lines:
	if ln is "d?????????  ? ?      ?        ?            ? user/":
		restart shfs

Edited July 24Jul 24 by Gray J

1 hour ago, Gray J said:

As a temperament solution, is there any way to bring shfs back online via a script?

Nope, you'll need to reboot, try booting in safe mode to rule out a plugin issue.

5 hours ago, JorgeB said:

Nope, you'll need to reboot, try booting in safe mode to rule out a plugin issue.

Well that is truly unfortunate....

I guess I could just make the script restart the server instead...

Any advise on how I could debug this?

My current idea is just using a python script to run a capture of HTOP (or alternative) every few minutes.

7 hours ago, Gray J said:

Any advise on how I could debug this?

My first recommendation would be to see if it still happens in safe mode.

Okay I will do that after I complete my parity check.

As a side though, why does SHFS have such a high OOM value by default?

Look at it in HTOP, SHFS has the highest value with 672 by default, you would think such an important task in the OS would be much lower, closer to 0 like SSHD.

Docker has a lower value as well at 666.

18 hours ago, JorgeB said:

My first recommendation would be to see if it still happens in safe mode.

Okay I have booted into safe mode, would I just enable plug ins one by one and go from there?

First run the server in safe mode without any plugins to confirm the issue doesn't happen. If it doesn't, then start enabling them, you can start with half, if it still doesn't happen, try the other half, then keep drilling down.