Samba Problem: The File Does Not Exist

Notepad says: “The file does not exist”. WordPad works. And I can clearly see the file in the Windows explorer.

Today, I’ve had to debug a really weird issue with the Samba 2.1 network protocol on Windows 10. Two nearly identical machines are accessing the same network share using the same Windows 10 version. Yet on one computer, accessing the network share works flawlessly, but on the other, it only works halfway.

When I opened the network share in the Windows explorer on both computers, the results looked exactly the same. When I opened a test text file in WordPad on both computers, it worked exactly the same. But when I try to double-click the text file, it will open in Notepad, which only worked on one computer but not on the other.

C++ Test

Rather quickly, I was able to track down this behaviour difference between Notepad and Wordpad to the use of GetFileInformationByHandle and so I built a tiny test program:

1
2
3
4
5

HANDLE h = CreateFileW(L"T:\\test.txt", 0x80000000, 3, nullptr, 3, 0x80, nullptr);
BY_HANDLE_FILE_INFORMATION out;
BOOL OK = GetFileInformationByHandle(h, &out);
if (!OK) ErrorExit(L"GetFileInformationByHandle");
CloseHandle(h);

I set up T: to be the mapped network share. As expected, this program would work on one computer, but crash on the other.

Different IRP results

Next up, I started the amazing Process Monitor from Sysinternals to see what was going on at the kernel level. I saw that on the good computer, the QueryInformationVolume IRP produced STATUS_BUFFER_TOO_SMALL (BUFFER OVERFLOW in ProcMon) as the result, which apparently was good enough to make the GetFileInformationByHandle call succeed. On the bad computer, the QueryInformationVolume IRP produced STATUS_INVALID_NETWORK_RESPONSE (INVALID NETWORK RESPONSE in ProcMon), which suggests that the bad computer is receiving broken data over the network.

So I fired up Wireshark to capture the SMB2.1 traffic. Boy was I surprised when I saw that both computers had issued the exact same SMB requests and had received the exact same SMB responses.

In other words, both computers were receiving the same data on the network level, yet one computer’s kernel translated this data into STATUS_BUFFER_TOO_SMALL and the other into STATUS_INVALID_NETWORK_RESPONSE.

At this point, I checked both computers with sfc /scannow, compared the hashes of fltMgr.sys, verified again that both are running the exact same windows build, rebooted both machines, and ran fltmc to check if there’s any difference in the file system filter drivers. I couldn’t find any difference.

Configuration Differences

But using Get-SmbClientConfiguration in an administrative PowerShell, I noticed that the good computer had caching and opportunistic locking turned on, while the bad computer has both disabled.

Good computer:

1
2
3
4

DirectoryCacheLifetime                : 10
FileInfoCacheLifetime                 : 10
FileNotFoundCacheLifetime             : 5
UseOpportunisticLocking               : True

Bad computer:

1
2
3
4

DirectoryCacheLifetime                : 0
FileInfoCacheLifetime                 : 0
FileNotFoundCacheLifetime             : 0
UseOpportunisticLocking               : False

Changing these configuration options on the bad computer fixed the problem :)

It appears that somewhere in the SMB2.1 kernel module there’s a bug that will misreport STATUS_BUFFER_TOO_SMALL as STATUS_INVALID_NETWORK_RESPONSE if – and only if – caching is turned off.