Change:
} } <del> output, err := exec.Command("cmd", "/c", "mklink", "/D", target, bindSource).CombinedOutput() </del> <ins> // There is an issue in golang where EvalSymlinks fails on Windows when passed a // UNC share root path without a trailing backslash. // Ex: SERVERshare will fail to resolve but SERVERshare will resolve // containerD on Windows calls EvalSymlinks so we'll add the backslash when making the symlink if it is missing. // https://github.com/golang/go/pull/42096 fixes this issue in golang but a fix will not be available until // golang v1.16 mklinkSource := bindSource if !strings.HasSuffix(mklinkSource, "") { mklinkSource = mklinkSource + "" } output, err := exec.Command("cmd", "/c", "mklink", "/D", target, mklinkSource).CombinedOutput() </ins> if err != nil { <del> klog.Errorf("mklink failed: %v, source(%q) target(%q) output: %q", err, bindSource, target, string(output)) </del> <ins> klog.Errorf("mklink failed: %v, source(%q) target(%q) output: %q", err, mklinkSource, target, string(output)) </ins> return err } <del> klog.V(2).Infof("mklink source(%q) on target(%q) successfully, output: %q", bindSource, target, string(output)) </del> <ins> klog.V(2).Infof("mklink source(%q) on target(%q) successfully, output: %q", mklinkSource, target, string(output)) </ins> return nil }

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Deploy a Windows cluster with containerd configured, SMB mount does not work by trying following project: It reports following error: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.6 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig windows /sig storage
/cc
I was able to repro your issue using the azurefile-csi-driver for Windows. I also tried to set up a repo where I would mount an azure file share to a Windows node manually, create symlinks to the share and then schedule a pod to the node using a hostPath volume and the container was able to start up fine using contianerd. Here is the pod-spec i used I tried to mount the Azure file share with both New-PsDrive and New-SmbGlobalMapping and saw date being written the the in the azure file share in both instances. I used mklink /D to create the symlinks - and also tried creating a symlink chain because it looks like that is how they get set up when when using azurefile-csi-driver and csi-proxy Right now I think this issue may be specific to either how the csi-proxy is setting up the SMB share for Windows or how paths are getting passed around between the various components.
this is not related to csi-proxy, in-tree azure file does not use csi-proxy, and it does not work
hostPath on containerd Windows does not work too:
I captured containerd logs for this and see I spoke with and he thinks this may be related to a known issue where go-lang is getting confused on Windows if a symlink points directly to the root of a SBM share (which is does in this case). He suggested adding a trailing  to see if this fixes the issue. I will try that out now and report back.

I tested some updates to CSI proxy to ensure the symlink to the sharepath had a trailing backslash and it looks like that resolved the issue. On my node running contianerd i have the following symlinks Previously the  on pvc--f195-4d9e-841b- was missing.
The core issue here is that containerd calls on the mount source path, and that function has a bug which prevents it from working when the path is a UNC share root. If the path has a trailing appended, then works properly. I have filed a bug on Go to fix this, and am working on a fix: golang/go
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is not resolved, right?
I see this issue is resolved in csi-proxy v0.2.2, while it's not resolved for the in-tree azure file driver.
/triage accepted
Ah, good point. yes, this is not fully resolved.