You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@sriram-govindarajan89 I'm not too familiar with SMB on Windows, but could you provide some more details? Where is the share you're trying to mount located? Is it another pod in the cluster? Does your command test-netconnection -p 445 mean you're trying the local port 445? And then are you trying to mount the share locally from the same pod? Did you double check that file sharing is enabled (again, I'm no expert, but a cursory google search shows error 53 could mean sharing is not enabled on the server)
@coutinhop Test-netconnection is a powershell equivalent of telnet that we normally use to test connectivity to a certain resource. The -p flag is the remote port of the file share. In this case, it's actually a NetApp filer within the corporate network or intranet. The path is definitely accessible as I am able to mount it from the windows node directly but just not from the pod. It kind of beats me how only smb could be impacted and not anything else. I am able to get response to curl commands for intranet rest apis, tcp communication test succeeds but just not the actual mounting.
Expected Behavior
Created a sample windows deployment and added a windows node.
windows pod can mount remote smb shares using net use or New-PSDrive cmdlet
Current Behavior
windows pod can communicate over the tcp port 445 when tested using test-netconnection
PS C:> test-netconnection remote-share -p 445
ComputerName : remote-share
RemoteAddress : remote-ip
RemotePort : 445
InterfaceAlias : vEthernet (3eebfa5489b44238f94e5aecd458f8b859418f7cac936888c187ea627a401574_Calico)
SourceAddress : 10.244.109.74
TcpTestSucceeded : True
When try to use net use command to mount the same share, get an error.
PS C:> net use * "\\remote-share\dir" /persistent:no /user:domain\user pwd
System error 53 has occurred.
The network path was not found.
Note: All other network communications appear to work. Able to perform successful curl commands to external http.
Possible Solution
unknown as of known and looking for some guidance.
Steps to Reproduce (for bugs)
Following setup done as per official documentation with few additions:
https://docs.tigera.io/calico/latest/getting-started/kubernetes/windows-calico/operator#install-calico-for-windows-using-the-operator
Calico setup on control plane for windows support
kubectl patch ipamconfigurations default --type merge --patch='{"spec": {"strictAffinity": true}}'
kubectl patch installation default --type=merge -p '{"spec": {"calicoNetwork": {"bgp": "Disabled"}}}'
kubectl calico patch ippool saga-hybrid-ipv4-ippool -p '{"spec":{"ipipMode":"Never","vxlanMode":"Always"}}'
kubectl patch installation default --type='json' -p='[{"op": "replace", "path": "/spec/calicoNetwork/ipPools/0/encapsulation", "value": "VXLAN"}]'
kubectl apply -f - << EOF
kind: ConfigMap
apiVersion: v1
metadata:
name: kubernetes-services-endpoint
namespace: tigera-operator
data:
KUBERNETES_SERVICE_HOST: "controlplane.host.name"
KUBERNETES_SERVICE_PORT: "6443"
EOF
kubectl patch installation default --type merge --patch='{"spec": {"serviceCIDRs": ["10.96.0.0/12"], "calicoNetwork": {"windowsDataplane": "HNS"}}}'
kubectl patch FelixConfiguration default --type merge --patch='{"spec": {"featureDetectOverride": "ChecksumOffloadBroken=true"}}'
kubectl patch FelixConfiguration default --type merge --patch='{"spec": {"ipipEnabled": false}}'
curl -L https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/hostprocess/calico/kube-proxy/kube-proxy.yml | sed "s/KUBE_PROXY_VERSION/v1.30.3/g" | kubectl apply -f -
Setup a sample windows deployment and ran tests from the pod.
Context
Trying to build a hybrid Kubernetes cluster with calico CNI.
Your Environment
The text was updated successfully, but these errors were encountered: