Hello.

I have issues with my SMB protocol running on the Unraid server.

Symptoms are as follows:

 

1. I setup share to be private and only read/write from particular user.

2. I authenticate as the user in windows, and i get access to the share, everything is good so far.

3. I start sending a large mount of data to the smb share, around 10tb... Soon enough when smb is trying to close/open new connections during transfer unraid is replying with access denied.

4. SMB will wait a period of time (a few seconds) and attempt a new connection, then the server gives access.

 

It's just like that under load SMB fails to properly authenticate or ignores the authentication but while not under heavy load everything works properly.

 

Example of a fix that works 100%:

I set the smb share to public for everyone thus disabling unraid from checking the credentials, now smb works properly all the time, there's no weird timeout and smb runs smooth without issue.

 

I have isolated that the issue is NOT any of my windows machines, it is not an issue with credential manager having mutliple entries, this is an issue on the unraid server so i believe anyone running Unraid Version: 6.7.2 can re-create this issue in their lab rather easily.

 

It's hard to detect this issue if you are using windows explorer and transfer file this way, it's much easier to detect the problem using something like FreeFileSync which has by default a feature called "Fail-safe file copy" and that means whenever a transfer is initiated it will name the file on the destination it is writing to filename.extention.randomhash.ffs_tmp

 

Whenever the file has written complete it does a crc check and then renames the file to it's original filename removing the .randomhash.ffs_tmp but when the unraid server is having issues handling the credentials it will return an access denied while FileFreeSync is doing it's rename and FreeFileSync will cause a popup dialog telling you that it has no access to the file it is trying to rename.

 

The same thing does occur i windows explorer but windows explorer does not give error, it stalls to 0kb/s transfer speed, waits for 5-10 seconds then tries again and new then your transfer continues which makes the error harder to spot.

 

Is there anything i can do to fix this issue without having to do Public? I was looking at the /etc/samba/smb.conf and there's something called: "ntlm auth = Yes" what would happen if we force more modern credential handling such as the modern NTLMv2?

 

Your ideas are welcome.

Edited November 10, 20196 yr by je82

You probably should add  the diagnostics files  (    Tools    >>>   Diagnostics  ), one which includes the time period in which you were doing transfers with the condition that has the problem and the other the time period with your fix in place  to your original post.

 

Then request a Moderator to transfer this thread to the appropriate section of the Bug Report sub-forum ----   https://forums.unraid.net/bug-reports/

I suspect that @limetech  should be made aware of this problem using that forum so that it doesn't get lost.

I believe i found the issue, it is related to my array's performance... and it is the array when under heavy write load this happens. When writing to the cache array there's no issues what so ever.

 

My follow up question would be, what can i do to improve array performance? My 2 parity drives are 2x 12tb ironwolf hdds.

In my chassi i have set 1 parity drive to be connected to my first LSI card, and the second parity drive to be on the second LSI card, i figured this would be a good idea in case one card becomes bad and start writing corrupt data the other card has a parity drive that works?

 

Would it be a better idea to put both parity drives on the same LSI card?

 

Or is there any other "good practices" in order to improve write performance directly to the array? It's obviously not a huge issue, i have 2x 1tb ssd for cache and once my data is all moved this wont be a problem anymore. The only thing that surprised me is the fact that the plugin "CA Auto Turbo Write Mode" which i more or less though would improve writing to the array directly didn't really do anything for me. Maybe i failed to really enable it, but it said it was on in the plugin options window.

 

I'm marking this as solved as it appears it is not a samba issue after all, it is the array having trouble dealing with big writes directly to the array resulting in files locking etc. Reading performance direct from array seems fine, i guess it is all about those parity drives doing their magic that really slows down writing to array directly.

Edited November 10, 20196 yr by je82

22 minutes ago, je82 said:

I believe i found the issue, it is related to my array's performance... and it is the array when under heavy write load this happens. When writing to the cache array there's no issues what so ever.

6.8 solves the issue of concurrent writes to the cache drive significantly degrading array performance.  You should install it to see if the issue goes away.

Writing speed to dual parity is dependent on the CPU.   See here:

and here:

The CPU is never a factor with single parity (PARITY 1) as that calculation uses the XOR operator which has been around since Intel 4004 processor days.