Not working in Windows Docker Container

[philippkratzer]

I just tried to use the package inside a windows docker container (using the container with the tag mcr.microsoft.com/dotnet/runtime:5.0.7-windowsservercore-ltsc2019).

The package shows unexpected behaviour:
I am able to get a node using the following code snippet: (Note that pathSource is the path to a folder on a network share)

using(var node = await Node.GetNode(pathSource, username, password))
{
...
}

The package behaves as expected and returns a non-null for the node object. The node type is correctly identified as "Folder". When I try to get the files and folders inside of the node using the snippet

using(var node = await Node.GetNode(pathSource, username, password))
{
    var childs = await node.GetList();
}

I get an empty collection, even though there are files on the share.

Interestingly, the code works as expected on Windows 10 Pro.

[ume05rw]

hmm... I try on Docker Desktop ver 3.4.0, It worked as expected.

image: mcr.microsoft.com/dotnet/runtime code:

using EzSmb;
using System;
using System.Threading.Tasks;

namespace ConsoleTest
{
    class Program
    {
        static void Main(string[] args)
        {
            Task.WaitAll(Program.Test());
        }

        static async Task Test()
        {
            Console.WriteLine("Start");
            using (var node = await Node.GetNode("192.168.0.1/Share", "userName", "password"))
            {
                Console.WriteLine($"Node.GetNode Succeeded: {node.Name}");
                var children = await node.GetList();
                foreach (var child in children)
                {
                    Console.WriteLine($"Node.GetList Succeeded: {child.Name}");
                }
            }
            Console.WriteLine("End");
        }
    }
}

output:

# ./ConsoleTest
Start
Node.GetNode Succeeded: Share
Node.GetList Succeeded: Folder1
Node.GetList Succeeded: Folder2
...
End

What is different about your environment?

[philippkratzer]

Thank you very much for your fast response and confirming that it is working in your stated environment.

I will do further investigations an post my findings here.

Thank you

[philippkratzer]

I did further tests in my environment and would like to share my results with you.

When I opened this issue, i used EzSmb version 1.3.1.

Today I experimented with the newer version 1.3.5 to see if the problem was fixed now. Interestingly, it got even worse, i see the described behaviour now reproducable also on my Windows 10 host machine. When downgrading to 1.3.1 it works again on Windows 10. I could not reproduce the Docker issue again today, so you might be right that Docker is not the problem here.

Anyways, it looks like there is something not compatible (EzSmb with one of my NAS), which might have caused the initial problems with Docker. The SMB share works as expected using the Windows Explorer, thus the share is functional in general.

I tested your code snippet with different NAS in my network. Two of them are Synology NAS. The code you provided works only with one of them, but not with the other one.

After calling the method node.GetList() the node object reports an error: 23:21:15.179: [EzSmb.Transports.Connection.Constructor] Connection Failed.

[ume05rw]

Thank you for you detail.
I'm testing with Windows and Samba, but unfortunately I don't have a Synology.

the NAS does not accept the requested dialect. Is there a way to request using a different dialect using Ezsmb?

The current EzSmb has only the SMB1 / 2 choice as the only connection option.

Maybe it is possible to connect by Named-Pipe in the original SMBLibrary.
EzSmb uses only Direct-TCP connections, but the original SMBLibrary allows Named-Pipe connections.

Named-Pipe can be selected in the second argument of the client.Connect method in the second line of this login sample.

If not, I can't think of a solution...

[philippkratzer]

Thank you for your assistance.

The current EzSmb has only the SMB1 / 2 choice as the only connection option.

I just analyzed the network traffic with Wireshark again. From my understanding of the captured traffic, the SMB client offers the following dialects:

• 2.0.2
• 2.1
• 3.0

The server then selects 3.0 in the negotiation.

If SMB is not supported in versuon 3 it should not be offered to the server in the request.

[philippkratzer]

The issue appears to be resolved in version 1.3.8.

Thank you for your work!