Ok I got the log running. Left it going until it started acting up. I was able to eventually get a clean shutdown. Here is the log from the flash drive.

There is also a smaller "previous" file. I have added that as well. The help here is much appreciated.

syslog syslog-previous

Jun 18 13:56:23 Unraid smbd[5048]: [2024/06/18 13:56:23.730972,  0] ../../lib/util/fault.c:184(smb_panic_log)
Jun 18 13:56:23 Unraid smbd[5048]:   PANIC (pid 5048): reinit_after_fork() failed in 4.17.12
Jun 18 13:56:23 Unraid smbd[5048]: [2024/06/18 13:56:23.731373,  0] ../../lib/util/fault.c:292(log_stack_trace)
Jun 18 13:56:23 Unraid smbd[5048]:   BACKTRACE: 13 stack frames:
Jun 18 13:56:23 Unraid smbd[5048]:    #0 /usr/lib64/libgenrand-samba4.so(log_stack_trace+0x2e) [0x14b32450b64e]
Jun 18 13:56:23 Unraid smbd[5048]:    #1 /usr/lib64/libgenrand-samba4.so(smb_panic+0x9) [0x14b32450b8a9]
Jun 18 13:56:23 Unraid smbd[5048]:    #2 /usr/sbin/smbd(+0xb13b) [0x5646a80e013b]
Jun 18 13:56:23 Unraid smbd[5048]:    #3 /usr/lib64/libtevent.so.0(tevent_common_invoke_fd_handler+0x91) [0x14b3244cd8c1]
Jun 18 13:56:23 Unraid smbd[5048]:    #4 /usr/lib64/libtevent.so.0(+0xee07) [0x14b3244d3e07]
Jun 18 13:56:23 Unraid smbd[5048]:    #5 /usr/lib64/libtevent.so.0(+0xcef7) [0x14b3244d1ef7]
Jun 18 13:56:23 Unraid smbd[5048]:    #6 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x91) [0x14b3244ccba1]
Jun 18 13:56:23 Unraid smbd[5048]:    #7 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x14b3244cce7b]
Jun 18 13:56:23 Unraid smbd[5048]:    #8 /usr/lib64/libtevent.so.0(+0xce97) [0x14b3244d1e97]
Jun 18 13:56:23 Unraid smbd[5048]:    #9 /usr/sbin/smbd(main+0x1489) [0x5646a80dd259]
Jun 18 13:56:23 Unraid smbd[5048]:    #10 /lib64/libc.so.6(+0x236b7) [0x14b3242d56b7]
Jun 18 13:56:23 Unraid smbd[5048]:    #11 /lib64/libc.so.6(__libc_start_main+0x85) [0x14b3242d5775]
Jun 18 13:56:23 Unraid smbd[5048]:    #12 /usr/sbin/smbd(_start+0x21) [0x5646a80ddb31]
Jun 18 13:56:23 Unraid smbd[5048]: [2024/06/18 13:56:23.731414,  0] ../../source3/lib/dumpcore.c:315(dump_core)
Jun 18 13:56:23 Unraid smbd[5048]:   dumping core in /var/log/samba/cores/smbd
Jun 18 13:56:23 Unraid smbd[5048]: 
Jun 18 13:56:34 Unraid smbd[9365]: [2024/06/18 13:56:34.003054,  0] ../../source3/lib/util.c:491(reinit_after_fork)
Jun 18 13:56:34 Unraid smbd[9365]:   messaging_reinit() failed: NT_STATUS_DISK_FULL
Jun 18 13:56:34 Unraid smbd[9365]: [2024/06/18 13:56:34.003114,  0] ../../source3/smbd/server.c:1033(smbd_accept_connection)
Jun 18 13:56:34 Unraid smbd[9365]:   reinit_after_fork() failed
Jun 18 13:56:34 Unraid smbd[9365]: [2024/06/18 13:56:34.003121,  0] ../../lib/util/fault.c:173(smb_panic_log)
Jun 18 13:56:34 Unraid smbd[9365]:   ===============================================================
Jun 18 13:56:34 Unraid smbd[9365]: [2024/06/18 13:56:34.003125,  0] ../../lib/util/fault.c:174(smb_panic_log)
Jun 18 13:56:34 Unraid smbd[9365]:   INTERNAL ERROR: reinit_after_fork() failed in pid 9365 (4.17.12)
Jun 18 13:56:34 Unraid smbd[9365]: [2024/06/18 13:56:34.003128,  0] ../../lib/util/fault.c:178(smb_panic_log)
Jun 18 13:56:34 Unraid smbd[9365]:   If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting
Jun 18 13:56:34 Unraid smbd[9365]: [2024/06/18 13:56:34.003133,  0] ../../lib/util/fault.c:183(smb_panic_log)

 

Seeing this over and over.

Those Samba call traces explain the share issues, not necessarily the flickering GUI, start by booting in safe mode, also leave the containers disabled, and see if the Samba panics are still there.

Ok I've done that. So far it's not there but it is also not having any weird activity. I'll leave i t alone for a bit and see if it does it. Docker is totally disabled.

 

On another note:

 

I was also  greeted with this when I first booted up (not in safe mode) "503 Service Temporarily Unavailable nginx"

syslog(8).txt

8 hours ago, JorgeB said:

Those Samba call traces explain the share issues, not necessarily the flickering GUI, start by booting in safe mode, also leave the containers disabled, and see if the Samba panics are still there.

Uptime 3 hours nothing yet. I believe it has went longer before acting up. What would be the next move? Enable docker and start turning stuff on one by one?

23 minutes ago, lightsout said:

Enable docker and start turning stuff on one by one?

Worth a try.

24 minutes ago, JorgeB said:

Worth a try.

Would you recommend a different approach?

That's a good option, to see if it's one of the containers, just make sure you only enable the next one after enough time has passed.

I'm curious since this happened while in safe mode, is safe mode necessary? Does that rule out a plugin issue?

I don't remember you posting that it still happened in safe mode, but if it did, that rules out plugins, and you can boot in normal mode.

So I have been up for 24 hours. No longer in safe mode. I have reinstalled a few plugins, mainly just what was need to use Intel quicksync with Emby.

I also have my main dockers up, which is the arr stack, and media servers like plex and emby.

 

So far I see some smb panics and no issues with the webui or drives falling off. Pretty happy about that. Going to forgo dockers that I wasn't really needing, and slowly re-add the plugins that I need.

 

A question on restoring the flash drive. Can I copy and past things into the config folder of the flash drive, like plugins, and then reboot and have them show up. Or do I need to shut down and pull the drive and add stuff that way? Thanks for all your help @JorgeB!

4 minutes ago, lightsout said:

Can I copy and past things into the config folder of the flash drive, like plugins, and then reboot and have them show up

You can.

12 minutes ago, JorgeB said:

You can.

Great thanks.

I have been able to accidently reproduce the same behavior.

 

Testing different HBAs for my cache, I would run 

dd if=/dev/zero of=/mnt/cache/tempfile bs=1M count=8192 conv=fdatasync

but when running accidently to of=/tmp/tempfile, I basically encountered the exact same issue shown on video, and similar log whining, SMB howling and also a bit of unassigneddisks plugin winces..

 

Could it be that something in your setup was hammering tempfiles like there was no tomorrow?

2 hours ago, Keexrean said:

I have been able to accidently reproduce the same behavior.

 

Testing different HBAs for my cache, I would run 

dd if=/dev/zero of=/mnt/cache/tempfile bs=1M count=8192 conv=fdatasync

but when running accidently to of=/tmp/tempfile, I basically encountered the exact same issue shown on video, and similar log whining, SMB howling and also a bit of unassigneddisks plugin winces..

 

Could it be that something in your setup was hammering tempfiles like there was no tomorrow?

Honestly I have no idea but that's helpful if it happens again. I did what was recommended. Can't remember exactly but partially started over. Didn't touch the array but got rid of all plugins and turned off all dockers. The problem went away and I slowly started adding things back to see if it acted up again. Haven't had any issues since.

Yup no clue if it's that in your case or just a totally new and original way to crap Unraid out, but having seen your post a while back and this happening today, I figured it could be worth going back here to offer the info up just in case.

2 minutes ago, Keexrean said:

Yup no clue if it's that in your case or just a totally new and original way to crap Unraid out, but having seen your post a while back and this happening today, I figured it could be worth going back here to offer the info up just in case.

For sure I appreciate the effort. I'll definitely come back here if it happens again. And helpful for anyone who runs into the same issue.

This is the top result on google for this issue that the imgur link shows of the array flashing drives on and off. Though this thread was not very helpful for my case I can say that this was caused by me mistakenly running rclone copy to /root instead of /mnt

Basically I filled my USB drive to the max with an rclone process and I saw this flashing. Figured I'd share since this a top google result. Check your USB drive space.

5 minutes ago, wheezy1749 said:

rclone copy to /root instead of /mnt

/root isn't on the flash drive. It is in the RAM space reserved for the OS files. The OS runs completely in RAM. If you fill up the OS reserved space all sorts of things can go wrong since the OS no longer has room to work.

On the other hand, /boot is exactly the flash drive.