Issue reported when doing write action on smb share

David Lechevalier 1

Hello,

On Windows server 2019, I often have the error 59: An unexpected network error occurred.
I did a python sample script which reproduce the issue doing write test on a Windows smb share.
I got the following errors:

The error returned by the script can be

Traceback (most recent call last):
File "Test_integrity.py", line 153, in <module>
test_integrity()
File "Test_integrity.py", line 149, in test_integrity
file_write_content(path, info)
File "Test_integrity.py", line 125, in file_write_content
os.remove(path)
WindowsError: [Error 59] An unexpected network error occurred: 'U:\data\Desktop\.\pref.ini'

Traceback (most recent call last):
File "Test_integrity.py", line 153, in <module>
test_integrity()
File "Test_integrity.py", line 149, in test_integrity
file_write_content(path, info)
File "Test_integrity.py", line 140, in file_write_content
win32file.WriteFile(handle, data, None)
pywintypes.error: (59, 'WriteFile', 'An unexpected network error occurred.')

To reproduce

Create a share on another Windows server
Map a share using the letter U:
Install python + pywin32 (pip install pywin32)
Start the script test.py

Actual result

The above error occur

I made some tests:
* The issue seems to only occurs from a Windows server 2019.
* It occurs with many samba version, (tested on centos7:4.10.16, bionic:4.10.13, xenial:4.3.11), many windows server share (Windows server 2012R2, Windows server 2019)
* It occurs even if I force dialect to 3.10, 3.02 or 3.00.
* The Windows server is fully updated (Build 17763.rs5_release.180914-1434).
* On procmon, I have the following error

I wanted to join the wireshark trace of my issue (U:\data\Desktop\.\pref.ini) and the script used to reproduce my issue.
But The interface does not allow it.

I would like to understand more this issue and eventually find a workaround.

Thank you for your help.

David Lechevalier.

Gary Nebbett 6,216 Reputation points

2021-03-17T09:30:49.81+00:00

Hello @David Lechevalier ,

Sharing the WireShark trace would help. The normal way of doing this is to place the trace file on a file service like OneDrive, Google Drive, etc. and then post the URL to the file here.

Gary
David Lechevalier 1 Reputation point

2021-03-17T10:44:59.433+00:00

Hello @Gary Nebbett

Here are the link to wireshark trace:
* https://drive.google.com/file/d/1jkIjGiWbHIBHRodQQ7YhUfgJvLKu6r12/view?usp=sharing => full trace
* https://drive.google.com/file/d/1ATUG9BXjbPgATICBmUZNRMDJzwsp4TY2/view?usp=sharing => an extract with the file which does not work (U:\data\Desktop.\pref.ini)

Then you for your help
David.

14 answers

Gary Nebbett 6,216 Reputation points

2021-03-18T19:37:19.34+00:00

Hello @David Lechevalier ,

I think that the ReactOS implementation of RxFsdCommonDispatch (viewable at https://doxygen.reactos.org/d8/d89/rdbss_8c_source.html) is reasonably close to that of current versions of Windows. The only cause of STATUS_UNEXPECTED_NETWORK_ERROR in that implementation is the "orphaning" of the File Control Block (FCB) of a remote file.

I don't think that you will be able to "eliminate" this problem via system configuration - it is probably a timing bug in the Windows Server 2019 implementation; I will however continue to try to identify exactly what goes wrong and when on the basis of the existing traces.

In the last trace that you sent, the problem actually occurred a few times, but some occurrences had no visible impact. As I mentioned previously, the if file exists then delete file should not be necessary if the subsequent CreateFile uses the CREATE_ALWAYS flag. In one case, the STATUS_UNEXPECTED_NETWORK_ERROR event causes the if file exists function to return false (because of the error - the file actually does exist) and so the delete file statement is not executed; this however has no consequence since the CreateFile with CREATE_ALWAYS overwrites/truncates the existing file. Your script finally fails when either the file write or delete functions incur STATUS_UNEXPECTED_NETWORK_ERROR.

It would be possible to code your script to handle this STATUS_UNEXPECTED_NETWORK_ERROR error by just "retrying" the operation that failed (win32file.CreateFile or win32file.WriteFile) although, of course, this should not be necessary in a correctly functioning system.

Gary
Please sign in to rate this answer.
Gary Nebbett 6,216 Reputation points

2021-03-19T08:53:07.25+00:00

Hello @David Lechevalier ,

The "\FI_UNKNOWN" path that appears in the trace data (shown in an image that I posted earlier) is correlated with the "orphaning" problem. "FI_UNKNOWN" is used by the ETW provider for file system events when it can't determine the actual name - in this case because the FCB has been orphaned and removed from the FCB to name mapping table.

The trace that you made also records the "orphaning events" (from the Microsoft-Windows-Remotefs-Rdbss provider).

I am still working on establishing causal relationships between key events in the trace; it is still quite possible that Windows Defender is the cause of the problem. I believe that there have been problems with Windows Defender and the normalization of UNC paths in the past (I can't immediately find a reference though), so making sure that all potentially relevant updates have been applied might be helpful.

Gary
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
David Lechevalier 1 Reputation point

2021-03-19T09:17:27.957+00:00

Hello @Gary Nebbett

Interesting, ReactOS implementation is so close to the reality ?
I really think that defender is linked to this situation. After having disabled the live protection, I don't have this issue anymore.

I'm agree, the delete operation is optional. The original code does not contain this action. During my investigation to reproduce this situation all the time, the remove have increased the frequency of the issue.

I have joined a new trace after having removed the remove instruction: https://drive.google.com/file/d/1O1Un_9k4Tx2jPGRTjAOyq8RXpAWD7Ny9/view?usp=sharing
In this case, the error occurs on the WriteFile. (cf first message).

I tried last week to replay the action but I can't. The replay WriteFile without reopening the file does not work. It seems that the handle is no more valid.

Regarding the update, the VM is fullly updated. I check today again.

Again, thank you for your help on this topic.

David.
Please sign in to rate this answer.
Anonymous

2021-03-22T09:21:21.583+00:00

You could accept the useful reply as answer if you want to end this thread up.
If there is anything else we can do for you, please feel free to post in the forum.

David Lechevalier 1 Reputation point

2021-03-22T09:44:47.277+00:00

Hi @Anonymous
I'm waiting for a response of @GaryNebbet in order to understand the issue, find a workaround or a way to fix the issue.
He said that he is still working on it.

For the moment, I have disabled the live protection, it is not the best way.

Best regards,
David
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
David Lechevalier 1 Reputation point

2021-04-13T13:35:47.617+00:00

Hello @Gary Nebbett ,

Do you have news about the live protection issue ? (workaround, tweak, KB, ...)

I updated my Windows today, the issue still exists.
I can only confirm that the issue does not occurs when live protection is off.

Thank you for your help.

Best regards,
David.
Please sign in to rate this answer.
Gary Nebbett 6,216 Reputation points

2021-04-13T18:59:22.153+00:00

Hello @David Lechevalier ,

Sorry, I did not see your previous message (that you were waiting for me) - the final "t" in my username was missing from the tag you used, so I did not get notified.

I tried my best with the resources available to me, but I was not able to make any further progress.

Sorry about that,
Gary
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
David Lechevalier 1 Reputation point

2021-04-14T07:05:10.95+00:00

Hello @Gary Nebbett ,

I thank you for your effort.
Do you know if there is another way to deal with this issue: a Microsoft bugtracker, another forum,... ?

Best regards,
David.
Please sign in to rate this answer.
Gary Nebbett 6,216 Reputation points

2021-04-14T07:40:15.06+00:00

Hello @David Lechevalier ,

For a not widely reported (by other users) problem of this complexity, it is unlikely that you will be able to find more support in another forum.

I don't have any recent (i.e. in this millennium :-)) contact with Microsoft support. @Anonymous often writes things like:

So we recommend you open a case with MS Professional tech support service, they will help you open a phone or email case to Microsoft, so that you would get a technical support on a one-to-one basis while ensuring private information. Here is the link: https://support.microsoft.com/en-us/gp/customer-service-phone-numbers

I think (but don't know) that this method costs money and that many people balk at the expense; perhaps the costs are reimbursed if it is determined that Microsoft software is at fault...

Gary
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Issue reported when doing write action on smb share

To reproduce

Actual result

14 answers

Your answer