'Azure CLI in WSL2 uses Windows home directory
Running this in WSL2 (current folder /home/my-linux-user/
):
az aks get-credentials --resource-group my-resource-group --name cluster-name
Outputs:
Merged "cluster-name" as current context in C:\Users\my-windows-user\.kube\config
What do I need to do to get Azure CLI to put the kube config in the Linux home folder in WSL instead?
Solution 1:[1]
What Linux distribution are you using in WSL? Another pertinent question is from @Philippe
The kubectl you use, is it WSL or Windows version ?
Are you running the kubectl client provided by az aks install-cli in the WSL Linux distribution? C: is going to be only available from the WSL Linux shell as /mnt/c/ so you are not supposed to get any message with a path like C:\Users\my-windows-user\.kube\config
. Please ensure you are using the linux kubectl executable from a WSL shell.
In my case, I use Ubuntu 20.04 LTS [How-to install] with WSL. Following is a sample:
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
Install the latest PowerShell for new features and improvements! https://aka.ms/PSWindows
Loading personal and system profiles took 1725ms.
? srbose@xxxxxxx ? ~ ?
? bash
srbose@xxxxxxx:/mnt/c/Users/srbose$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
srbose@xxxxxxx:/mnt/c/Users/srbose$ az aks get-credentials -g $RG -n akstest
The behavior of this command has been altered by the following extension: aks-preview
/home/srbose/.kube/config has permissions "644".
It should be readable and writable only by its owner.
Merged "akstest" as current context in /home/srbose/.kube/config
srbose@xxxxxxx:/mnt/c/Users/srbose$
The default behaviour is as follows:
If the --kubeconfig
flag is set, use only the specified file. Do not merge. Only one instance of this flag is allowed.
Otherwise, if the KUBECONFIG
environment variable is set, use it as a list of files that should be merged. Merge the files listed in the KUBECONFIG
environment variable according to these rules:
- Ignore empty filenames.
- Produce errors for files with content that cannot be deserialized.
- The first file to set a particular value or map key wins.
- Never change the value or map key. Example: Preserve the context of the first file to set
current-context
. Example: If two files specify ared-user
, use only values from the first file'sred-user
. Even if the second file has non-conflicting entries underred-user
, discard them.
For an example of setting the KUBECONFIG
environment variable, see Setting the KUBECONFIG environment variable.
Otherwise, use the default kubeconfig file, $HOME/.kube/config
, with no merging. For more information please check this article.
You can check if the KUBECONFIG environment variable is set using
echo $KUBECONFIG
Solution 2:[2]
I believe the root of the problem here is that the Azure CLI being run is actually the Windows version. I struggled with precisely this same issue until I discovered I was running the Windows version of AZ, thus it assumed Windows paths. This is one of those areas where Microsoft wanted to make things super easy for folks by just running Windows apps in WSL, yet it bites you in the arse.
Solution: install the Linux version of Azure CLI. Instructions found here: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-linux
On Ubuntu it's as easy as:
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
Then all will "just work" as you expected. Super clean and easy, and also easy to overlook.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
Solution | Source |
---|---|
Solution 1 | Dharman |
Solution 2 | BrettRobi |