Cannot git clone to VMWare shared folder

Question

Weird problem this morning - I'm not able to git clone from a public repo on GitHub to my shared VMWare folder with either SSH or HTTPS. I'm working on Fedora 22, and if I try this command anywhere on the system other than the shared folder, it works perfectly.

git clone https://github.com/twbs/bootstrap.git
Cloning into 'bootstrap'...
fatal: 'origin' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Steps I have tried:

• Rebooting VM and host Mac (running El Capitan)
• Reinstalling git
• Checking permissions (drwxr-xr-x)

Does anyone have any idea why the shared folder might be causing this?

Chancroid

Before using git, can you make a file in the folder? try touch foobar.txt and ls – Woolley

Yes, I can make files and folders from both host and guest. All files/folders in the guest show the owner/group as: 501 games And I'm not permitted to chown anything in the folder, even with sudo. – Chancroid

Read the error message again: fatal: 'origin' does not appear to be a git repository fatal: Could not read from remote repository. There is a problem with the remote repository. Or with some local git configuration to access it. – Preshrunk

As stated in the question, this command on the same system anywhere other than the shared folder works exactly as expected. In this case the error message is definitely erroneous. – Chancroid

@Chancroid - did you ever solve this? – Grisaille

Unfortunately the only solution I ever found was to handle the git side of things on the host. It's literally just the shared folder where git clone fails, so it's a pain, but not a showstopper (for my needs). – Chancroid

I'm getting issues when commiting as well - so I have to use git entirely in the host - which is not what I want – Grisaille

@Grisaille What version of VWVare (and which VMWare product) are you using? Fusion 8? – Weinert

@Weinert VMWare Workstation Pro 12.5.2 build-4638234 (latest version) – Grisaille

This is the box I am trying to use atlas.hashicorp.com/laravel/boxes/homestead - version 1.0.1. Basically it seems to break from version 0.6.0 onwards. Version 0.4.4 works. i.e. I can "switch" to 0.4.4 and my Git works inside the VM. If I switch to 0.6.0 onwards - Git fails as above. The difference between the versions is the version of VMWare Tools used inside. Apparently the newer boxes use VMWare v10 inside, as that is needed for Ubuntu 16.04 onwards. So VMWare v10 seems to break the shared folders somehow... – Grisaille

Can you clone even a tiny, test repository into the VMware shared folder, or does any Git clone fail? – Curet

@Curet - anything/everything fails. So trying to clone a public repo still results in the errors above – Grisaille

@Chancroid - I just solved this (at least for me). See my answer below – Grisaille

I'm seeing similar issues with hyper V when trying to add using git. – Muckraker

Same here, I am forced to clone in my host. – Tramway

Answer 1

I have the same issue. I believe this may be because the VMWare shared folder filesystem does not support all filesystem operations properly. For instance, you cannot create a hardlink:

$ touch foo
$ ln foo bar
ln: bar: Operation not supported

... and you cannot copy a symlink:

$ touch foo
$ ln -s foo bar
$ cp -R bar baz
cp: bar: could not copy extended attributes to baz: Invalid argument

Furthermore, once the git clone fails, the filename of the checkout can never be used again:

$ git clone https://github.com/twbs/bootstrap.git
Cloning into 'bootstrap'...
[...]
fatal: index-pack failed
$ touch bootstrap
touch: bootstrap: Input/output error

Others have noticed the issues with hardlinks and git clone in VMWare shared folders. Nobody has found a solution.

I have worked around this issue when using an OS X guest by saving a disk image to the shared folder, mounting the disk image in the guest, and then git-cloning into the mounted filesystem. A similar technique may work in Linux, but I haven't tried it.

Sortilege

Thanks for this - I had wondered if there would be other symptoms because of this issue. I will try the Linux workaround. – Chancroid

An unfortunate consequence of using a disk image in this manner is that the files on it aren't accessible to the host while the guest is running, but this approach does have the benefit that the image is preserved on the host even if you vagrant destroy the guest. – Sortilege

This is only partially correct. I can use VMWare shared folders with Git on my old VM box. But I cannot use it with VMWare shared folders on my new box. I think it might be related to the VMWare tools - but I'm not sure. – Grisaille

I know this is a dumb question, but regarding the "VMWare shared folder filesystem", what filesystem is it, do you know? Is it a "local" filesystem like ext4 or a "remote" one like SMB/CIFS? – Aldred

Answer 2

As Laurence pointed out, this is an issue from VMWare version 0.6.0. This is because:

VMware changed the tools package and moved from HGFS to FUSE instead of being in the kernel.

There are no folders under /mnt/hgfs and shared folders are created under a folder named shared_folder.

Symptoms:

• Cannot access a shared folder in a virtual machine from other machines in the network.
• A shared folder with appropriate permissions in a virtual machine is not accessible over the network

The error similar to:

You cannot access ip_address\folder_name
You do not have permission to access ip_address\folder_name. Contact your network administrator to request access.

Cause:

As far as I see, this is the reason behind this issue and other bugs related to other filesystem operations. More appropriately,

This issue occurs if the Audit object access GPO is enabled on the shared folder and the shared folder resides on a hot-pluggable device.

Solution:

Mount shared folders. Refer this

Locate the shared folders.

Disable audit file access on the shared folder and remove all hot-pluggable devices.

Hope this will help.

Few months ago, my development team faced a similar issue regarding which a colleague contacted the support team on behalf of the organization.

Alvaro Aguilera from Hashicorp support was gracious enough for pointing out the issue. Initially, the support team had suggested to move to Fusion 8.0.2 which also works in case one wants to avoid the hassle.

Following is the concluding message from the support team on 20th May 2016:

Thanks for reaching out to us.

As per the log, it seems the HGFS module is not present on the VM.

Additionally, there is a VMWare fusion issue with 8.1.* and forwarded ports, please try to go to Fusion 8.0.2 since that is the last one known to work without issues.

Please use old boxes for your use case instead of the latest VMware Fusion as the developer team has confirmed that it is expected to be solved in Q1 2017.

Thanks for understanding.

We had moved to Fusion 8.0.0 and this issue was solved.

Thoraco

Interesting. I can access the shared folders and see them inside the VM - it is only Git that has the trouble. But it might be related, because of the permission issue. I'll look into it now and see – Grisaille

Thanks for this. It didnt solve the problem - although it pointed me in the right direction. I've provided an answer below – Grisaille

Answer 3

I found the fix today. Not sure if it is the same for everyone - but you need to configure your VM sync folder to use smb and also mfsymlinks

config.vm.synced_folder ".", "/vagrant", type: "smb", mount_options: ['vers=3.02', 'mfsymlinks']

I can now use Git and symlinks correctly inside the VM without issue.

Grisaille

I'm on VMWare Fusion 8.1.1. Any idea if and how this fix would be applied to it? I tried to edit the VM settings, adding it to the end of the settings file and changing the "/vagrant" path to that of my shared folder, but there was a dictionary error immediately. – Ocelot

Where do you make this change? – Wexler

Answer 4

Here is my solution. Since in VMware Machine can't git clone, and when use other commands, it may cause problems. So I git clone in windows systems, and do my git jobs in my windows system. And it works for me.

Decare

Answer 5

I do not have a relevant setup here, so I might get wrong, but - you say that the problem only happens on shared folders. One option I might think of is that SSH/HTTPS uses a different key than your own when on such a folder.

If this is the case, a possible solution is to define keys for whoever is considered by VMWare as the user.

BTW, have you tried cloning a repository to a private folder and then sharing it? It is interesting whether it will work that way (which might indicate that the problem only happens upon local creation of the folders) or fail with a similar or different error when trying to further pull or push (which might indicate that the problem is in the connection itself, but not necessarily).

Cordovan

Answer 6

I had the same issue but i found a solution. My setup is using VMware Workstation 12.5.5 and Linux kernel 4.4 for the guest.The host runs Linux kernel 4.10.8. You need to git clone the latest openvm-tools in your Linux guest under $HOME (not under your HGFS mount directory of course): https://github.com/vmware/open-vm-tools

follow the instructions and compile openvm-tools from the source.After compiling, backup /usr/bin/vmhgfs-fuse (cd /usr/bin; mv vmhgfs-fuse vmhgfs-fuse.bak) and copy $HOME/open-vm-tools/open-vm-tools/vmhgfs-fuse/.libs/vmhgfs-fuse to /usr/bin.

Then copy $HOME/open-vm-tools/open-vm-tools/libvmtools/.libs/libvmtools.so.0.0.0 to /lib64 and create a link to it: ln -s libvmtools.so.0.0.0 libvmtools.so.0

Check for other libraries that could be needed. (use ldd /usr/bin/vmhgfs-fuse to know which libraries are missing and copy accordingly)

That's it, reboot the vmware guest machine and you will be able to use your hosts mounted directory via HGFS to store Git repositories, clone, pulls, pushes are working fine now :)

Plurality

Answer 7

I have found a workaround for this issue, share a folder from windows and then in your linux guest intall samba and cif-utils You can then mount the share by ip of the host like this

(add this line to your fstab)

//YOUR_HOST_IP/share /PATH_TO/GUEST_SHARE cifs user,noperm,rw,username=YOURUSERNAME,password=YOURPASSWORD 0 0

the key here is the noperm designation

note: for security purposes you can store your windows password in a credentials file and call it here or create a user on your windows instance that is designated only for share access and then grant access on your primary user account to the share user.

Hope this helps.

GIT CLONE TO YOUR HEARTS DESIRE

Skeen

Answer 8

Git 2.27 (Q2 2020) illustrates another case where that clone can be problematic, even using a CIFS network drive:

See commit 23eafd9 (10 Apr 2020) by Nathan Sanders (sandersn).
^{(Merged by Junio C Hamano -- gitster -- in commit a41b41c, 22 Apr 2020)}

mingw: cope with the Isilon network file system

^{Signed-off-by: Nathan Sanders
Signed-off-by: Johannes Schindelin}

On certain network filesystems (currently encountered with Isilon, but in theory more network storage solutions could be causing the same issue), when the directory in question is missing, raceproof_create_file() fails with an ERROR_INVALID_PARAMETER instead of an ERROR_PATH_NOT_FOUND.

Since it is highly unlikely that we produce such an error by mistake (the parameters we pass are fairly benign), we can be relatively certain that the directory is missing in this instance. So let's just translate that error automagically.

This fixes git-for-windows/git issue 1345 "Unable to clone a repository on a CIFS share on Isilon storage. Error: unable to append to 'X:/git/Win32-OpenSSH/.git/logs/refs/remotes/origin/HEAD': Invalid argument".

Weinert