[Bug Report / 5.2.a.7 Draft] SMB/CIFS service keeps crashing (tsmb timeout)

[KYTECHNGAMING]

Hi everyone,

I just updated my router to the latest 5.2.a.7 draft firmware, and I have completely lost access to my USB SMB shares.

I checked the system log to see what was going on, and it looks like the tsmb-server is stuck in a continuous crash loop. It keeps trying to start, times out with an error (Cifs::ServerTsmb: system failed [0xcffd0516], operation timeout), and then stops unexpectedly.

I am attaching my self-test file so the developers can take a look. Has anyone else lost their SMB access after this update?

Thanks in advance for the help!

[KYTECHNGAMING]

Update: The issue resolved itself without a reboot.

Hi again, I wanted to provide an update. I left the router alone since yesterday, and today my SMB access is fully working without me having to reboot the device.

I checked my new self-test logs and the tsmb-server crashes have completely stopped. It looks like right after the firmware update, the router was doing some heavy background processing on the connected USB drives (possibly filesystem checks or DLNA media indexing). This heavy I/O load caused the SMB service to time out (0xcffd0516) and crash repeatedly. Once the background disk activity settled down, the SMB service started normally and has been completely stable.

Perhaps the developers could look into increasing the timeout threshold for the tsmb service during heavy disk load so it doesn't enter a crash loop? I am attaching my latest self-test file for reference.

[KYTECHNGAMING]

Update: The issue is tied to heavy I/O load during boot.

I rebooted the router to install a new component, and I observed the exact same behavior: the tsmb-server went into a crash loop but eventually fixed itself after a few minutes and stayed stable.

After reviewing the logs, the root cause seems to be an I/O bottleneck during startup. I have three drives connected (5TB, 1TB, and 480GB). Right after boot, MiniDLNA and Transmission start scanning and indexing these large drives simultaneously.

Because the disk I/O is completely saturated, the tsmb service fails to initialize in time, hits an operation timeout (0xcffd0516), and gets killed/restarted by the system repeatedly. Once the initial DLNA/Torrent disk storm calms down, tsmb starts successfully and works perfectly.

Perhaps the startup timeout threshold for tsmb could be increased in future drafts to handle scenarios with heavy background disk activity?

I have attached my latest self-test taken right after the reboot for your reference.