Samba shares contantly disrupting (smbd crashing) on RT-AX68U

[xtvst]

The main use of my RT-AX68U besides providing a fast wifi connection is to be able to have a shared drive between two computers and few other devices.
However since I started using this router for a shared network drive it's being a pain with constant instabilities (Windows explorer freezes, the PC gets unresponsive, open application using network files aborts and I lose my unsaved job).
Attached my UI screen and smb.conf.
Any help will be appreciated. I'm using SMBv2 only (please don't suggest me to add support for SMBv1; it's an insecure and inneficcient protocol).

Below samba.log and nmbd.log (smbd.log doesn't have anything logged recently)

admin@RT-AX68U-F300:/var/log# cat samba.log
[2021/09/24 09:05:44.295688, 0] smbd/negprot.c:706(reply_negprot)
No protocol supported !
[2021/09/24 09:05:45.426740, 0] smbd/negprot.c:706(reply_negprot)
No protocol supported !
[2021/09/24 11:49:09.478335, 0] smbd/negprot.c:706(reply_negprot)
No protocol supported !
[2021/09/24 11:49:09.488205, 0] smbd/negprot.c:706(reply_negprot)
No protocol supported !
[2021/09/24 11:51:53.854850, 0] lib/fault.c:47(fault_report)
===============================================================
[2021/09/24 11:51:53.856264, 0] lib/fault.c:48(fault_report)
INTERNAL ERROR: Signal 11 in pid 31644 (3.6.25)
Please read the Trouble-Shooting section of the Samba3-HOWTO
[2021/09/24 11:51:53.856434, 0] lib/fault.c:50(fault_report)

From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf
[2021/09/24 11:51:53.856525, 0] lib/fault.c:51(fault_report)
===============================================================
[2021/09/24 11:51:53.856632, 0] lib/util.c:1117(smb_panic)
PANIC (pid 31644): internal error
[2021/09/24 11:51:53.859937, 0] lib/util.c:1221(log_stack_trace)
BACKTRACE: 0 stack frames:
[2021/09/24 11:51:53.860065, 0] lib/fault.c:345(dump_core)
Exiting on internal error (core file administratively disabled)

nmbd.log looks like this:
[2021/09/24 11:06:34, 0] nmbd/nmbd_browsesync.c:351(find_domain_master_name_query_fail)
find_domain_master_name_query_fail:
Unable to find the Domain Master Browser name WORKGROUP<1b> for the workgroup WORKGROUP.
Unable to sync browse lists in this workgroup.
[2021/09/24 11:21:44, 0] nmbd/nmbd_browsesync.c:351(find_domain_master_name_query_fail)
find_domain_master_name_query_fail:
Unable to find the Domain Master Browser name WORKGROUP<1b> for the workgroup WORKGROUP.
Unable to sync browse lists in this workgroup.
[2021/09/24 11:36:34, 0] nmbd/nmbd_browsesync.c:351(find_domain_master_name_query_fail)
find_domain_master_name_query_fail:
Unable to find the Domain Master Browser name WORKGROUP<1b> for the workgroup WORKGROUP.
Unable to sync browse lists in this workgroup.
[2021/09/24 11:51:33, 0] nmbd/nmbd_browsesync.c:351(find_domain_master_name_query_fail)
find_domain_master_name_query_fail:
Unable to find the Domain Master Browser name WORKGROUP<1b> for the workgroup WORKGROUP.
Unable to sync browse lists in this workgroup.

 

[ColinTaylor]

The only thing that looks odd in your config file is the fact that most of the shares have the user "user" set as both an valid user and an invalid user!?

 

[eibgrad]

Any help will be appreciated. I'm using SMBv2 only (please don't suggest me to add support for SMBv1; it's an insecure and inneficcient protocol).

Fair enough, but I'd *still* like to know if perhaps that is the problem. IOW, it still makes sense to try the older protocol for diagnostic purposes, rather than chasing down what may be other deadends.

And btw, at least for my purposes, the fact it's insecure only matters to the extent it's exposed directly to the internet. There's NO WAY I'd be exposing anything directly to the internet except within the confines of a VPN anyway, whether (supposedly) secure (e.g., RDP) or insecure. Telnet, http, ftp, etc., are completely insecure, by definition, but I have no issue with using them *provided* it's within the security blanket of my VPN.

 

[xtvst]

The only thing that looks odd in your config file is the fact that most of the shares have the user "user" set as both an valid user and an invalid user!?

Yes, this seems to be a bug about the router generating the smb.conf file.
In my case I do have two users, "admin" and "user". And "user" shouldn't be added in valid users' shares that are set to "no" in the UI.