Vagrant shared folders unable to install Package Management Plugins (Composer, PHP)

[Svpernova09]

## Versions

• MacOS: Mojave 10.14.5 (18F132)
• Virtualbox: 6.0.10 r132072 (Qt5.6.3) (And Exentions)
• Vagrant: 2.2.5
• Vagrant box: bento/ubuntu-18.04 201906.18.0

## Problem

Unable to install Composer (PHP Package Manager) plugins on folders shared via Virtualbox (vboxsf)

## Steps To Reproduce:

Clone: ​https://github.com/svpernova09/vagrant-test

• Adjust folder share of ~/Code/fresh-laravel to a fresh [Laravel](​https://github.com/laravel/laravel) installation
• Run vagrant up
• Run vagrant ssh
• Run cd larvel
• Run composer require ocramius/package-versions
• See "Could not delete /home/vagrant/laravel/vendor/ocramius/package-versions/src/PackageVersions:"
• Run cd
• Run composer create-project laravel/laravel not-vbox-share
• Run cd not-vbox-share
• Run composer require ocramius/package-versions
• See "Package manifest generated successfully."

## Logs

Here is a gist of the relevant actions: ​https://gist.github.com/svpernova09/17f7a2c9aba316e24bb063a25010d6f6

[Socratis]

Vagrant is a program that relies on VirtualBox, but modifies its configuration files in unknown ways to us, and with unknown consequences, especially the networking part. It is not supported on these VirtualBox forums/channels, they have their own ​Vagrant support channels.

If you are having this problem with a standalone version of VirtualBox (after a complete uninstallation of Vagrant), then we can continue this discussion.

[Svpernova09]

Vagrant is a program that relies on VirtualBox, but modifies its configuration files in unknown ways to us, and with unknown consequences, especially the networking part. It is not supported on these VirtualBox forums/channels, they have their own Vagrant support channels.

Pretty disappointed in this answer. I've provided replication instructions and an open repository so you can easily replicate exactly what I've done at the most basic level and you can easily view my configuration. I've spent several hours trying to isolate where this bug may be and the common denominator seems to be the Virtualbox provider.

[Socratis]

Replying to Svpernova09:

Pretty disappointed in this answer.

The truth of the matter, no matter how disappointing it may be, is that you can't be calling Apple (for example) for all that's wrong with an app in your OSX installation. First you talk to the app developer, in your case Vagrant or even higher at the package level.

The way that errors are processed in software is usually from the top-to-bottom. You start from the top-layer, and if you find an error due to the layer below you investigate that, and if you find an error due the layer below the below you investigate that, and so on. As I said, unfortunately what you're reporting is three levels up from the basic VirtualBox functionality.

I've provided replication instructions and an open repository so you can easily replicate exactly what I've done at the most basic level and you can easily view my configuration.

As I mentioned, an installation of Vagrant alters the basic configuration of any VirtualBox installation. I'm not going to be tainting my setup by installing Vagrant trying to replicate your problem, I'm sorry. But I'm pretty sure that those instructions/logs would be a lot easier/helpful to work with for someone that's dealing with Vagrant (I'm only dealing with VirtualBox), so your work will not be in vain.

I've spent several hours trying to isolate where this bug may be and the common denominator seems to be the Virtualbox provider.

And I've spent a lot of time looking through your logs. But where exactly is the VirtualBox error? I don't see one. What am I missing here?

[Svpernova09]

As I mentioned, an installation of Vagrant alters the basic configuration of any VirtualBox installation. I'm not going to be tainting my setup by installing Vagrant trying to replicate your problem, I'm sorry. But I'm pretty sure that those instructions/logs would be a lot easier/helpful to work with for someone that's dealing with Vagrant (I'm only dealing with VirtualBox), so your work will not be in vain.

I get it, I'm just frustrated to get completely blown off by the project I'm trying to identify a possible bug for. I'm also curious if you could point me into any documentation which covers "an installation of Vagrant alters the basic configuration of any VirtualBox installation" my understanding of Vagrant is that it's literally an API consumer of Virtualbox. I'm not aware of any changes it makes to Virtualbox at an application level.

And I've spent a lot of time looking through your logs. But where exactly is the VirtualBox error? I don't see one. What am I missing here?

Thanks for taking the time. I do appreciate it. And yes, there is no visible hard error to point to. That's why I've spent the better part of a week trying to debug and diagnose this myself *before* coming here.

The error/issue/bug/whatever we want to call it as I see it:

I can spin up a VM using Vagrant + Virtualbox using *Virtualbox's* own shared folder system and I see weird filesystem errors when running a command.

I do *not* get these errors on my local machine I do *not* get these errors when using Vagrant + Parallels, Vagrant + VMware (Fusion OR Desktop).

I do *not* get these errors when using NFS shared folders, or SMB shared folders.

The only common denominator I can find that is interacting with these folders is Virtualbox's folder sharing.

I'm looking for some Virtualbox specific domain knowledge and insight into *why* these commands fail on a vboxsf folder, but not on another folder share. As demonostrated in my initial report I can copy the files to a non vboxsf folder and the command runs without issue. This is why I came here, to seek support with what I *think* may be a folder sharing issue. I'm looking for a Virtualbox expert in folder sharing to help guide me in my debugging. If that's not you: no worries! Thanks for your time and please ping the rest of your support to team to see if we can find someone who may be able to help me instead of shutting down my questions.

[Svpernova09]

@socratis:

I spun up a new Virtualbox VM and can replicate the issue *WITHOUT* Vagrant.

Gist showing the issue: ​https://gist.github.com/svpernova09/c31d7a11b9444bcfccdb52593c6a7787

There is an image in the comments of the gist above that shows the Virtualbox settings. Please let me know if you need any more info.

Thanks

[Socratis]

Thank you for trying to replicate this Vagrant-less. :)

So, the problem boils down to this?

- Removing ocramius/package-versions (1.4.0)
[RuntimeException]
Could not delete /home/halo/symfony4/vendor/ocramius/package-versions/src/PackageVersions:

What's in there, in that dir? What files/dirs? Any funky ones, like dirs/files starting with a period, hidden, locked, read-only?

And from your successful first run, I see that there is a:

Writing lock file

as the next step in the installation. Maybe that's where the problem is? Again, if you can simplify the scenario to a single, reproducible step without 3rd party tools, it would be ideal.

Did this ever work? Did you try with older VirtualBox versions, like 5.2.32?

[Svpernova09]

Replying to socratis:

Did this ever work? Did you try with older VirtualBox versions, like 5.2.32?

I honestly don't know. This issue is exposing a seldom-used feature (to me) of the package manager. I went all the way back to the latest 5.2.x version and the problem remained, so I stopped there.

For the rest of the debugging I'll have to get back to you on, I don't have much of it written up in a coherent way. If you want to try to follow along with us here's where the issue originated: ​https://github.com/laravel/homestead/issues/1240

[Svpernova09]

Replying to socratis:

I've managed to figure out that VirtualBox's folder sharing isn't fast enough to process the files as quickly as Composer can extract them. More details for those interested here: ​https://github.com/laravel/homestead/issues/1240#issuecomment-513989365

This ticket can be closed.

[coyote]

I don't think this ticket should be closed, composer install was working in prior versions (6.0.x). I don't recall which one exactly. It was working fine prior to all the sharing/permission issues were introduced.

[turbop]

I agree that this ticket should not be closed. Before finding this bug ticket we were trying to execute "composer install" under different circumstances. It is perfectly working within a virtual machine when it's not a shared folder. But as soon as it's a shared folder using the VirtualBox shared folders this error could be reliably reproduced.

When running "composer install -vvv" the stack trace points to ​https://github.com/composer/composer/blob/master/src/Composer/Util/Filesystem.php in line 217. Interesting here are line 204 and 194. What composer seems to do is to delete some files after unarchiving them before. Speed seems to be an issue here, just why they introduce a delay.

Hope this helps.

[Frank Batschulat (Oracle)]

Replying to turbop:

When running "composer install -vvv" the stack trace points to ​https://github.com/composer/composer/blob/master/src/Composer/Util/Filesystem.php in line 217. Interesting here are line 204 and 194. What composer seems to do is to delete some files after unarchiving them before. Speed seems to be an issue here, just why they introduce a delay.

unlinkImplementation() may fail for an arbitrary number of reasons

#334

    private function unlinkImplementation($path)
    {
        if (Platform::isWindows() && is_dir($path) && is_link($path)) {
            return rmdir($path);
        }
        return unlink($path);
    }

so whatever the OS and underlaying file system, in this case obviously the vboxsf module, are returning as an error would be interesting here. unfortunately we don't get this information from this case as it looks like it just returns a boolean. I don't know if unlink() here is the real OS primitie or some PHP thingy ontop of it, I am not a PHP programmer, but it would certiainly be of help to know about the real error code returned for the failing unlink(2) systemcall.

[turbop]

Yes we have this error message. See comment number 6. Also it's part of this bug tickets description.

[Frank Batschulat (Oracle)]

from

​https://github.com/laravel/homestead/issues/1240#issuecomment-513989365

I can only see one error from this code path:

"[RuntimeException]

Could not delete /home/vagrant/symfony/vendor/ocramius/package-versions/src/PackageVersion:

But this is just stating the fact, without telling us the underlaying OS error being returned for the unlink(2). Worthless error message to diagnose a problem.

[Frank Batschulat (Oracle)]

We should really try to write a test case without requiring Vagrand and its PHP adventures.

Question for the submitter: Is the Host OS important, eg. does this only happen using OSX on Mac or has this been reproduced with Vagrant on Linux or Windows hosts as well?

[coyote]

You don't need Vagrant to replicate. Just pull any project via composer and it should generate the error.

My setup is: Windows 10 host, Ubuntu 18 guest. I have not tested linux host, linux guest.

1. Set up shared folder with access in ubuntu. (/media/sf_whatever)
2. Checkout a git repo to the shared folder. In my case I used cakephp (​https://github.com/cakephp/app)
3. Run composer install -vvv

[Frank Batschulat (Oracle)]

Replying to coyote:

You don't need Vagrant to replicate. Just pull any project via composer and it should generate the error.

My setup is: Windows 10 host, Ubuntu 18 guest. I have not tested linux host, linux guest.

1. Set up shared folder with access in ubuntu. (/media/sf_whatever)
2. Checkout a git repo to the shared folder. In my case I used cakephp (​https://github.com/cakephp/app)
3. Run composer install -vvv

Ah I see, I somehow thought "compose" is part of Vagrant. So as I indicated already, the code in composer does not tell us anything reasonable about the underlaying failure. So I want to get composer out of the picture and come up with a test case that replicates the workflow without composer so we can get better understanding of the problem.

[turbop]

My intention to post those composer code lines was to better understand which problem composer has when working with the filesystem. The error message does not really help, I agree here. But it was interesting to note that the composer developers already had a workaround at exactly this position. Sorry if this was causing confusion.

[Frank Batschulat (Oracle)]

Replying to turbop:

My intention to post those composer code lines was to better understand which problem composer has when working with the filesystem. The error message does not really help, I agree here. But it was interesting to note that the composer developers already had a workaround at exactly this position. Sorry if this was causing confusion.

Don't get me wrong. Thanks for pointing to the composer source that reproduces the problem. All I am saying is that we should isolate the usage pattern from that and create a standalone test case that we can use to reproduce and analyze the problem as well as to incorporate it into regression testing later. I hope we can isolate enough from comopser to isolate the trigger.

[Frank Batschulat (Oracle)]

Whjile I am trying to reproduce the issue may I ask the submitter whether or not this issue still exist with the latest 6.0.12 release from https://www.virtualbox.org/wiki/Downloads ?

We have one vboxsf bug fixed in there https://www.virtualbox.org/ticket/18737

Also we have another vboxsf bug currently only fixed in Trunk and in the test builds https://www.virtualbox.org/ticket/18805 if you don't mind testing out the test build from https://www.virtualbox.org/wiki/Testbuilds any 6.0.x Testbuilds with a revision >= r133104.

If you can try those out to see whether or not that makes a difference, that'd be great.

[Frank Batschulat (Oracle)]

according to bug:

Ticket #18937 Regression on shared folders when deleting directories

https://www.virtualbox.org/ticket/18937

6.0.12 still has this problem.

[miklinux]

I had the exact same issue.

This happens when sharing the project directory from an encrypted filesystem on the host. Moving that directory outside the encrypted fs, solved the issue for me, and composer can successfully complete without any error.

Using Virtualbox version 6.0.12 and vagrant 2.2.5

[sseypt]

I had the exact same issue.

Solved it by reverting to VirtualBox Guest Additions v5.2.32.

# Setup

• VirtualBox 6.0.12
• Windows 10 1903
• DockerToolbox 19.03.1 (​https://github.com/docker/toolbox/releases/tag/v19.03.1)

# Problem

• Boot2Docker ISO 19.03.1 (​https://github.com/boot2docker/boot2docker/releases/tag/v19.03.1)
• using VirtualBox Guest Additions v6.0.10

# Solution

• Boot2Docker ISO 19.03.2 (​https://github.com/boot2docker/boot2docker/releases/tag/v19.03.2)
• They reverted to VirtualBox Guest Additions v5.2.32 (​https://github.com/boot2docker/boot2docker/compare/v19.03.1...v19.03.2-beta1)
• Commit: Pin VBoxGuestAdditions to 5.x

[Socratis]

Replying to sseypt:

Solved it by reverting to VirtualBox Guest Additions v5.2.32.

1. That's not a solution, that's a workaround.

2. It's been said time and time again, that Vagrant/Docker/3rd_party apps are really supported, try to replicate it with a clean VirtualBox installation

[sseypt]

Replying to socratis:

Replying to sseypt:

Solved it by reverting to VirtualBox Guest Additions v5.2.32.

1. That's not a solution, that's a workaround.

2. It's been said time and time again, that Vagrant/Docker/3rd_party apps are really supported, try to replicate it with a clean VirtualBox installation

You are right, its' a workaround. I meant solution for me, for now.

I just wanted to point out that the root cause could be the guest addition. Maybe this is helpful for someone. My bugs disappeared after the downgrade. Why boot2docker changed back to 5.x, I can't say.

[Frank Batschulat (Oracle)]

It is very likely that this bug will have the same root cause as the following bug

Ticket #19086 rm / rmdir not working correctly in shared folders https://www.virtualbox.org/ticket/19086

that bug I can reproduce at will without any obscure software stacking.

[Frank Batschulat (Oracle)]

actually we find the first occurence of this bug in combination with vagrant in an older ticket from 9 years ago! see also #8761

[Frank Batschulat (Oracle)]

see also:

#19086 rm / rmdir not working correctly in shared folders
#8761 Silent failure to delete files on Shared Folders

[elb98rm]

I can confirm that (via a similar but different method) that this ticket is still valid. Is this likely to be resolved soon?

For reference, the process that triggers it is likely very common: a symfony skeleton installation on a shared folder. I can share a build to replicate if required.

[binary1230]

for those still following along, I put a simple repro case and kernel debugging info in this ticket here: https://www.virtualbox.org/ticket/8761

I suggest if these are really the same root cause, that we keep the tech details in one spot.

This is really a common and really bad bug that so many people have hit and it takes them a while to trace it back to the info in these tickets, so I'm just making sure it's cross-referenced as much as possible.

I appreciate everyone who has put work into getting to the bottom of it, thanks all.