Windows-Containers icon indicating copy to clipboard operation
Windows-Containers copied to clipboard

SmbGlobalMapping Username and Domain is set to Null/Null after beeing mounted

Open jcarnus opened this issue 5 months ago • 8 comments

Describe the bug After an SMB Share is mounted using a SmbGlobalMapping (using https://learn.microsoft.com/en-us/powershell/module/smbshare/new-smbglobalmapping?view=windowsserver2019-ps), the initial authentication request does contains the username and domain specified with the -credential option but when the global mapping is used under windows container/docker, it contains NULL/NULL. It does lead to try to establish a session for every file read/write and can also lead to network port exhaustion if the NAS Provider does not support those null/null

Image

To Reproduce

  1. Mount a SmbGlobalMapping using using https://learn.microsoft.com/en-us/powershell/module/smbshare/new-smbglobalmapping?view=windowsserver2019-ps
  2. Start a docker with a -v option
  3. Take some network capture with Wireshark

Expected behavior We expect authentification token to contains the user given with the -credentials option when mounted the folder

Configuration:

  • Windows Server 2019

jcarnus avatar Jul 24 '25 12:07 jcarnus

Thank you for creating an Issue. Please note that GitHub is not an official channel for Microsoft support requests. To create an official support request, please open a ticket here. Microsoft and the GitHub Community strive to provide a best effort in answering questions and supporting Issues on GitHub.

github-actions[bot] avatar Jul 24 '25 12:07 github-actions[bot]

Sounds same issue which we did see but in our environment it happened only with one file server. I was not able to find root cause but expected that it has something to do it authentication settings.

Anyway, I was able to find that: you can avoid this issue by adding hosts file line like this to container:

0.0.0.0 server.domain.local

where you use same server name than is used to create that mapping.

That way container cannot resolve file server name and connect to it directly like it tries but instead of host OS will refresh authentication.

Alternative solution which just came to my mind would to be to disable LanmanWorkstation service completely from container but haven't tested that.

olljanat avatar Aug 19 '25 16:08 olljanat

Thanks for the solution. You made my day! I can confirm this seems all good, and the host file is more flexible in case of multiple mappings

jcarnus avatar Aug 19 '25 20:08 jcarnus

@ntrappe-msft I see you reply to few other bug of this repo. Any insights on this issue ?

Thanks

jcarnus avatar Aug 20 '25 00:08 jcarnus

@jcarnus btw. Have you tried to use -RequirePrivacy $true parameter suggested in https://github.com/moby/moby/issues/37863#issuecomment-583016113 ?

It was not explained in there but I would assume that it will enforce SMB version 3 to be used and I can see Encrypted SMB3 messages in Wireshark when it is used.

PS. I also highly recommend upgrading to Windows Server 2025. 2019 is very old already and missing many improvements in this area.

olljanat avatar Aug 20 '25 10:08 olljanat

The -RequirePrivacy is already set to $true on the SmbGlobalMapping and I see the same issue with Win2022. Adding to this, not all NAS providers support a login mecanism with NULL username and password.

jcarnus avatar Aug 20 '25 14:08 jcarnus

This issue is still relevant

jcarnus avatar Sep 21 '25 10:09 jcarnus

This issue has been open for 30 days with no updates. no assignees, please provide an update or close this issue.

This issue has been open for 30 days with no updates. no assignees, please provide an update or close this issue.