77

I am running Ubuntu 18.04, as a Subsystem for Windows. I have done this in mutliple PCs and never had this problem. I try to to git clone <repo>, and I get this:

Cloning into '<repo>'...
error: chmod on /mnt/c/Users/Efsta/Code/<repo>/.git/config.lock failed: Operation not permitted
fatal: could not set 'core.filemode' to 'false'

I tried the following:

  1. ❯ git config core.fileMode false, with this result fatal: not in a git directory

  2. ❯ git config --global core.filemode false

  3. ❯ git config --add --global core.filemode false

Nothing seems to work. I already tried a couple of answers here, but WSL seems a little bit more tricky. Anyone have any idea about how to solve this?

I have also tried everything in this question : https://stackoverflow.com/questions/1580596/how-do-i-make-git-ignore-file-mode-chmod-changes, nothing seems to work.

4 Answers 4

123

I had the same issue. Try this:

sudo umount /mnt/c
sudo mount -t drvfs C: /mnt/c -o metadata

Change the drive letter to whatever one you're having the issue with.

11
  • 4
    The command was successful but this did not change the issue for me. I still see "operation not permitted" as git tries to chmod .git/config.lock.
    – akohlsmith
    May 22, 2019 at 13:55
  • 5
    Worked for me. Is there some reason MS is not doing this when they mount windows locations automatically?
    – UpTheCreek
    Oct 10, 2019 at 15:27
  • 5
    Note that this is available after build 17063: docs.microsoft.com/en-us/windows/wsl/release-notes#build-17063
    – pooya13
    Dec 4, 2019 at 22:54
  • 1
    confirmed this fixed the issue for me - had to change directory from windows file system to ubuntu to get the unmount command to work, but after running the commands, i was able to git clone my repo without permissions issue
    – epikhighs
    May 26, 2020 at 22:04
  • 7
    Should be the accepted answer.
    – cheesus
    May 29, 2020 at 9:15
80

You can automatically mount your Windows drives under WSL with the metadata option that allows apps, like git, to use chmod and fix this issue.

Edit /etc/wsl.conf (create it if it doesn't exist). Add the following:

[automount]
options = "metadata"

Then either:

  • Reboot Windows
  • Exit any WSL sessions, run wsl --shutdown from PowerShell or CMD, and start WSL again
  • Exit your only session, terminate it with wsl --terminate <distroName>, and start it again,

Then never worry about it again.

7
  • 1
    Thanks! This worked for me in combination with re-mounting the drive.
    – Alex
    Jul 28, 2020 at 0:11
  • I had to restart my computer after doing this. Aug 23, 2020 at 0:11
  • 7
    Instead of rebooting, with WSL 2 you can exit out of all WSL 2 shells, and then run wsl --shutdown from powershell instead. When you start a new WSL shell, it'll automatically start the underlying VM again with your new config.
    – xxpor
    Sep 20, 2020 at 21:17
  • This helps a lot, thank you!
    – RAM237
    Jan 28, 2021 at 15:05
  • The savior we need! thanks :) Jun 6, 2021 at 18:49
32

/mnt/c/Users/... is on the Windows NTFS partition itself, and not within the WSL's ext4 formatted system. Therefore you have to treat it as you would an NTFS partition on a USB stick on an actual Ubuntu installation, and accept the limitations of NTFS.

NTFS partitions do not support chmod or similar Linux permissions commands, and unlike in actual Ubuntu instalations which don't error but don't make any permissions changes, WSL doesn't relay this information back to you, it simply errors out as you see here.

You cannot do a git clone sanely into the /mnt/c/... space within WSL because of the Linux permission schemas and chmod not working right. This is a limitation of WSL in its current form.

5
  • 3
    Ok let me confirm some things. Microsoft says, that I should develop in WSL within Windows, so I can modify them on both the WSL and Windows sides. So, in every other installation I had until now, I did the same. And if we assume that what youa re saying is correct, what would you recommend as a soution to my problem? Feb 4, 2019 at 16:45
  • And to add to my above question. What do I do about ssh? Can I resuse the same key on both. There are situations like gcloud where I want to use my windows deve enviroment instead... Feb 4, 2019 at 16:47
  • Also, previously I was using WLinux, which was slow, but witht the same underlying theory used the Windows filesystem, and I could do it as well. So, not an Ubuntu specific thing.Sorry for spamming you Feb 4, 2019 at 16:50
  • @DimitrisEfst you should be using the in-built Linux partitions within WSL and not /mnt/c/Users/... or such. This is, again, a WSL limitation. (That is, use your /home/USER/... directory stored within Ubuntu WSL for *nix permissions and copy built binaries, etc. out into /mnt/c/Users/... for use in the Windows native environment. (There's a lot of limitations for WSL though, so keep that in mind)
    – Thomas Ward
    Mar 2, 2020 at 14:01
  • 8
    This answer may have been accurate at the time it was written but isn't any more. I clone repos from WSL into /mnt/c/ all the time without any problems, with obvious usability benefits over cloning into ~/. See Wojtek's answer instead.
    – Justin
    Apr 21, 2020 at 13:02
8

I was having the same issue. My solution is to git clone my repo in the default WSL location (it works), and use Visual Studio Code to remote access my WSL's repos. That way you won't have to use /mnt/c at all.

Links: https://code.visualstudio.com/docs/remote/wsl

Not the answer you're looking for? Browse other questions tagged or ask your own question.