I would run
journalctl -u smbd
directly after the smb server appears to be down (when it was running before)
or run it with "-f" ("f" for ~follow up~) all the time
journalctl -u smbd -f
to see all what's up with your box
maybe with increased log level:
the smb server box is connected via ethernet, too ?
maybe something in your smb.conf is ~slightly~ wrong (full wrong => smb wouldn't start)
I'm unsure here: I guess it cry's when error are found, anyway I fetched the return status via "echo $?" where I guess "0" means no errors
one of this has caused trouble for some users (I guess the first one)
server max protocol ?
server min protocol ?
I've attached the output of testparm -v
- it's from nightly
- it's the untouched default, cause smb is here NOT in use
if you've a linux box available you could e.g. use "meld" to compare yours and mine
There is nothing in the log that helps solving the problem:
journal log files are thrown away when you reboot the box ...
and you just checked for smb only, so maybe it's not smb (my bet: it's network ...[if you don't find any weird config settings with testparm] or it's something with the kernel)
last part could be checked with nightly (newer kernel: 5.15.y)