WSL Ubuntu Distro | How to solve `Operation not permitted` on cloning repository

Question

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.

Solution 1

/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.

Solution 2

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.

Solution 3

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.

Solution 4

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

View more solutions

Comments

[Dimitris Efst]

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?

[Dimitris Efst]

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...

[Dimitris Efst]

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

[akohlsmith]

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.

[UpTheCreek]

Worked for me. Is there some reason MS is not doing this when they mount windows locations automatically?

[pooya13]

Note that this is available after build 17063: docs.microsoft.com/en-us/windows/wsl/release-notes#build-170‌​63

[hoaphumanoid]

This is working for me at the moment

[Thomas Ward]

@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)

[Justin]

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.

[epikhighs]

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

[a.s.t.r.o]

This works as of WSL 2 in Windows 10 2004

[cheesus]

Should be the accepted answer.

[Alex]

Thanks! This worked for me in combination with re-mounting the drive.

[Andrew Koster]

I had to restart my computer after doing this.

[xxpor]

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.

[Valorad]

I am using WSL2 and this does not work similar to @akohlsmith 's scenario. However, I find out that mounting as a normal user will work: sudo mount -t drvfs C:\\folderVolume /mnt/folderVolume -o metadata uid=1000,gid=1000,umask=22,fmask=111. Now I can do chmod without any issue.

[elkarrde]

Did the trick for me!

[RAM237]

Saved my day, thank you so much. For some reason I haven't found it anywhere regarding my particular issue, but I started to look at similar issues and finally stumbled upon this one! What a luck :)

[RAM237]

This helps a lot, thank you!

[BelgoCanadian]

The savior we need! thanks :)

[Kevin Shea]

@Valorad has the correct addition in their comment - adding the uid and gid are necessary to avoid the file's owner being root. Note that a comma is needed between the metadata and uid options though.

[Big Rich]

Just did this on WSL2 and it worked, shutdown WSL2 via powershell, no reboot required.

[Admin]

worked as a charm, should be accepted answer