As the title says, ever since the update to 7.0.1, my shares will disappear and I have to restart the server to get them back. I don't check my server often but noticed it when I tried to use Plex and it said Plex was offline. So I went to my docker which showed Plex was running. So then I try to access the movie directly through Windows network drive and the drive is offline. That's when I went to the shares tab and saw there were no shares. Did a google search and found if you restart the server the shares come back but that post said "It only happens one time after the update." Well, its happening more than one time to me. I've been checking my server daily and every single day my shares are gone again until I restart. What's going on? I know diag files will be needed. Do I just attach the whole zip file?

12 minutes ago, ElectroBlvd said:

Do I just attach the whole zip file?

this

Eh....I clicked to download the zip file this morning when I noticed my shares were missing again. And then restarted my server. But I guess I didn't notice the file didn't download before restarting. So I don't have that zip file. I guess I'll have to wait till the shares disappear again, and then get the zip file and upload it here.

 

EDIT: I did notice it looked like there was an oom error right before the shares went down.

Edited April 22, 20251 yr by ElectroBlvd

Here's the zip

main-ur-data01-diagnostics-20250423-2213.zip

In the diagnostics I can see:

Apr 23 04:09:36 Main-UR-Data01 kernel: docker-proxy invoked oom-killer: gfp_mask=0x140cca(GFP

and that the process killed was

Apr 23 04:09:36 Main-UR-Data01 kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=shfs,pid=9305,uid=0
Apr 23 04:09:36 Main-UR-Data01 kernel: Out of memory: Killed process 9305 (shfs) total-vm:29626212kB, anon-rss:28993760kB, file-rss:800kB, shmem-rss:1440kB, UID:0 pgtables:56860kB oom_score_adj:0
Apr 23 04:09:38 Main-UR-Data01 kernel: oom_reaper: reaped process 9305 (shfs), now anon-rss:0kB, file-rss:800kB, shmem-rss:0kB

the shfs process that supports User Shares (which is why they are no longer available).   What I cannot see is what was the trigger for that process to use so much memory.  Someone else may have an idea.

 

All I can suggest is to keep monitoring as if it keeps happening around the same time then it may be due to something that is scheduled to run at around 4:00am.

So confirmed at 430a this morning that it is happening at 4am every day. I read somewhere, before creating this thread, that there's some automated process that happens around that time built into unraid but can't remember what it was or where I read that. I looked through every setting I could think of in unraid to see if I had anything scheduled during that time and found nothing. Would you be able to advise me on where all the scheduled tasks sections are in unraid so I can make sure I didn't miss anything?

1 hour ago, ElectroBlvd said:

scheduled tasks

What do you get from command line with this?

cat /etc/cron.d/root

 

 

I don't see anything that says Scheduled Tasks but I do see an icon that says Scheduler. I'm assuming that's what you're referring to? Is that the only place? Cause the only things in there is Parity Check, Mover and Trim which none of those are set for 4am daily.

 

Running the command you asked gave me.....

 

17 minutes ago, ElectroBlvd said:

Running the command you asked gave me.....

You can see

17 minutes ago, ElectroBlvd said:

Parity Check, Mover and Trim

among many others in that output. Some are from plugins which have schedule settings.

 

None are at 4am

 

crontab.guru

Ok, so how do I figure out what's going on at 4am every morning that eats up my memory forcing my server to stop a process that ultimately makes all my shares disappear? Having to restart the server every day is starting to get....frustrating. Especially if I forget to restart it before leaving for work and then need to access something on it and can't cause its down.

setup syslog server

So I found the problem with this. The Plex docker from pms-docker from plexinc was causing the memory issue when it would run its daily maintenance. Even if I went into plex and unchecked everything in the scheduled maintenance tasks, it would still run and just flood the memory slowly until the server crashed. I stopped the official plex docker from running and installed the binhex version and have not had an issue since.