[Help] How to debug failing SMB connections

[k0d3g3ar]

Hi there, I have a F6-424 MAX running TOS 6.0.783 with about 72TB of disks installed. The system has been working great for about 6 months but recently I started to notice that after about 3 days of operation, it started to behave weird. The most noticeable thing was SMB connections couldn't see the server anymore. I was able to login via the web to the TOS admin portal, and all problems are resolved if I restart the box, or power cycle it. But this is clearly not a desirable position to be in, with what I was hoping was an "always on"/"just works" NAS solution.

So I'm trying to debug what might be the issue. Are there logs I can review somewhere that will help me identify exactly what is going on here?

[TMjack]

Hello, based on your description, can I understand it as follows: After restarting the device, the SMB service will temporarily return to normal, but after a while, it will become inaccessible again? If this is the case, please follow these steps: Go to the navigation bar of the TOS desktop and enable Debug mode; When the problem occurs again, send us the Debug logs by email; We will analyze the log content and assist you in resolving the issue.

[k0d3g3ar]

Hello, based on your description, can I understand it as follows: After restarting the device, the SMB service will temporarily return to normal, but after a while, it will become inaccessible again? If this is the case, please follow these steps: Go to the navigation bar of the TOS desktop and enable Debug mode; When the problem occurs again, send us the Debug logs by email; We will analyze the log content and assist you in resolving the issue.

You are correct in your understanding of my issue. I have enabled debug mode now. I'll wait for it to fail, and hopefully the answer will lie in the debug log. I appreciate your help with this.

[mrslother]

I, too, have seen this. A Win11 client can connect and transfer several gigs of files then it loses the connection. This only started happening over past month when I had to flatten and reinstall tos6 (updated to 783 from 500) on my u4-423. It is also happening on my new f6-424 (same build).

Previous to this build the u4 was functioning correctly.

RSync from the f6 to the u4 seems to work correctly, even over mounted smb share.

[k0d3g3ar]

I, too, have seen this. A Win11 client can connect and transfer several gigs of files then it loses the connection. This only started happening over past month when I had to flatten and reinstall tos6 (updated to 783 from 500) on my u4-423. It is also happening on my new f6-424 (same build).

Previous to this build the u4 was functioning correctly.

RSync from the f6 to the u4 seems to work correctly, even over mounted smb share.

Interesting. This is about the same timeline that I'm seeing it, and it definitely was noticed after a TOS update. It does look like a software issue to me, as I have no failing hardware being reported. I should add that we installed an external Terramaster DAS device as a USB3 device, with two drives running in a Raid0 format, as a backup system to the NAS. This synchronizes the delta on a schedule from the NAS, but it isn't moving massive amounts of content. I'm not sure if the sheer size of file transfer is the trigger for me. But it has been 3 days so far, and no fail. I'll hopefully know more once I see the failure re-appear.

[mrslother]

I think I solved my problem, however I do believe it is a TOS6 regression.
In my case I changed the windows LM security compatibility security policy from highest (5) to the default policy (3, LMv2 responses only). Since that change I no longer see the constant LM negotiation challenge (in my network traces) and file copy doesn't just stop partway through (at least so far).

I believe this is a TOS regression because earlier builds worked correctly with my previous security setting (my day job is in cybersecurity so I always run with highest levels of paranoia).

[k0d3g3ar]

It failed again today. I have the system logs from the unit. I attempted to email it, but my mail gateway is stopping it - saying that the ZIP file contains a phishing virus? Is there another way I can get this to you? Like an online portal or something?

UPDATE: Tried it with Google Gmail and got the same blocking. It doesn't like something that is in the ZIP file. I opened it, and it appears to be many of the Linux directories (ie. /etc). I think there needs to be another way available to get this file to you.

[k0d3g3ar]

I think I solved my problem, however I do believe it is a TOS6 regression.
In my case I changed the windows LM security compatibility security policy from highest (5) to the default policy (3, LMv2 responses only). Since that change I no longer see the constant LM negotiation challenge (in my network traces) and file copy doesn't just stop partway through (at least so far).

I believe this is a TOS regression because earlier builds worked correctly with my previous security setting (my day job is in cybersecurity so I always run with highest levels of paranoia).

I wish I could do that, but I'm running MacOS here. Unless this is a setting on the TNAS itself?

[k0d3g3ar]

Hello, based on your description, can I understand it as follows: After restarting the device, the SMB service will temporarily return to normal, but after a while, it will become inaccessible again? If this is the case, please follow these steps: Go to the navigation bar of the TOS desktop and enable Debug mode; When the problem occurs again, send us the Debug logs by email; We will analyze the log content and assist you in resolving the issue.

FYI, I can't upload the ZIP file created from your logs. Both my mail gateway and Gmail state that the attached file contains a "phishing virus". It doesn't, but they are both interpreting it that way. Is there another way I can upload this file to tech support?

[TMzethar]

You can try sending Debug logs via cloud disk sharing links or WeTransfer links.
Alternatively, you can just bypass the detection by simply changing the ".zip" extension to another format.