Unable to save correctly to network share (PC Specific)

Question

Good Afternoon

I have a PC specific issue which is doing my head in! Was wondering if anyone is able to help.

The symptoms:

Saving any file to the local PC is fine

Saving any file to a network share running Windows Server (on multiple file servers and OS) brings up an error message:

\path to network share

You don't have permission to modify files in this network location.

Contact the administrator per permission to make these changes.

However, a file with the correct name and extension is created but it is 0kb.

If you save the exact same file again and try to overwrite the 0kb file then the document saved correctly the second time .

The user can log onto any other PC on the domain and does not have the issue. I log on to the user's PC with my administrator account and I then have the issue as well. So it is definitely PC specific rather than permissions in my opinion.

Have tried all the obvious like removing / disabling AV, tried flushing DNS, disabling / re- enabling SMB etc. but I'm now stuck with what could be causing this problem. I've also compared Group Policy & local group policy to a known good PC and there's no differences.

I've checked the event viewer and there is nothing being written that would indicate what the problem is but I could be looking in the wrong place.

Any suggestions please ?

Answer 1

Hello @Andrew Moore ,

One could try using Event Tracing for Windows on the client to get more understanding of why it is behaving so. From your description, my first guess would be that a filter driver (typically an anti-virus filter) is responsible for the problem, but you say that you have reproduced the problem with the installed AV product disabled.

One would probably need to make (and analyse) more than one trace - the first trace to get a rough idea of what might be happening and subsequent traces to focus on questions raised by previous traces.

A way of starting a simple trace (whilst running as Administrator) is to issue the command logman start why -ets -p Microsoft-Windows-SMBClient -o why.etl; after reproducing the problem, the trace can be stopped with the command logman stop why -ets.

The trace file (why.etl) can be shared here via a link to OneDrive, Google Drive, etc. (the trace data is not easy to understand).

Gary

Answer 2

Hi Gary

Thank you for your response. I have reproduced the error using 3 separate traces.
In Why1 I reproduce the error alone and do not save the file again.
In Why2 I reproduce the error, and then save the same file again over the original (which saves successfully as expected).
In Why3 I reproduce the error alone and do not save the file again.

A link to the traces is as follows:
https://www.dropbox.com/sh/so68inmsn6wc7ud/AACcSQ-lZyb6GXkX1puqH3o7a?dl=0

I appreciate any help you can provide

Thank you

Andrew

Answer 3

Hello @Andrew Moore ,

Thanks for those traces The traces show that everything is working at the SMB level. There are no "permission" errors in the trace and the file is initially 0 bytes in size because a file create (new) is immediately followed by a file close with no intervening (or subsequent) write.

This all points to a "filter driver" driver of some sort intervening between the application and SMB (e.g. prevents an application write request from reaching the SMB driver).

The remote file system behaviour in the trace is quite complex. My guess is that Windows File Explorer was open and was showing the folder and that the file "save" was the result of saving an open Winword document - both add to the complexity of the trace.

What happens if you just copy (from the command line) a file to the share?

The next step will be to extend the trace to capture high level file system operations (effectively application open/create/read/write/close operations) and SMB operations so that we can see how the two relate. Let me think about the most effective trace command to obtain that view.

Gary

Answer 4

Hi,

Welcome to our Q&A platform.

I would suggest you could enable Audit Object Access audit policy from Windows File server to see if there is any related event log will be trigger when the issue reproduce. It will help track who accesses files on Windows File Severs in your organization. The related event log might help for further troubleshooting.

Please refer to methods in the following article to enable the audit log:

https://www.lepide.com/how-to/track-who-read-files-on-your-windows-file-servers.html

Best Regards,
Sunny

----------

If the Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 5

Hello Andrew,

Here is an update on the things to do:

Try using the share with simple tools like notepad to create/modify/delete/replace files on the share and judge whether this is working normally.

If simple tools do seem to be working, try using Word in safe mode and check how that behaves.

To check for unexpected filter drivers installed on the system, issue the command "fltmc instances -v \Device\Mup". On my system this shows:

Instances for \Device\Mup volume:

Filter                  Altitude        Instance Name       Frame   SprtFtrs  VlStatus  
--------------------  ------------  ----------------------  -----   --------  --------  
WdFilter                 328010     WdFilter Instance         0     00000007  
FileInfo                  40500     FileInfo                  0     00000007  

Your system should look similar.

Check whether Offline Files is enabled (select "Sync Centre" from the Control Panel and then click on "Manage offline files" in the left panel - that should show this dialog:

There is still a lot more tracing that can be done. The results of the above steps will guide what to include in the next trace (if needed).

Gary