55

I have a Vagrant running Linux and I'm trying to install Symfony.

After the command composer create-project symfony/framework-standard-edition ./ "2.5.*" I have the error : 

[RuntimeException]
  Could not delete ./.git/objects/pack/tmp_idx_llwUKb:

If I try to composer update another project, I always have this kind of error Could not delete

Any ideas?

Edit: For a simple sudo composer update -vvv on another project: 

  - Installing sonata-project/admin-bundle (dev-master 8a022aa)
Failed to download sonata-project/admin-bundle from source: Could not delete /vagrant/crm_neo/vendor/sonata-project/admin-bundle/.git/objects/pack/tmp_idx_hchQhc:
Now trying to download from dist
  - Installing sonata-project/admin-bundle (dev-master 8a022aa)

Failed: [RuntimeException] Could not delete /vagrant/crm_neo/vendor/sonata-project/admin-bundle/.git/objects/pack/tmp_idx_hchQhc:



  [RuntimeException]
  Could not delete /vagrant/crm_neo/vendor/sonata-project/admin-bundle/.git/o
  bjects/pack/tmp_idx_hchQhc:



Exception trace:
 () at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:193
 Composer\Util\Filesystem->unlink() at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:151
 Composer\Util\Filesystem->removeDirectoryPhp() at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:129
 Composer\Util\Filesystem->removeDirectory() at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:35
 Composer\Util\Filesystem->remove() at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:80
 Composer\Util\Filesystem->emptyDirectory() at phar:///usr/local/bin/composer/src/Composer/Downloader/FileDownloader.php:108
 Composer\Downloader\FileDownloader->doDownload() at phar:///usr/local/bin/composer/src/Composer/Downloader/FileDownloader.php:89
 Composer\Downloader\FileDownloader->download() at phar:///usr/local/bin/composer/src/Composer/Downloader/ArchiveDownloader.php:35
 Composer\Downloader\ArchiveDownloader->download() at phar:///usr/local/bin/composer/src/Composer/Downloader/DownloadManager.php:201
 Composer\Downloader\DownloadManager->download() at phar:///usr/local/bin/composer/src/Composer/Installer/LibraryInstaller.php:156
 Composer\Installer\LibraryInstaller->installCode() at phar:///usr/local/bin/composer/src/Composer/Installer/LibraryInstaller.php:87
 Composer\Installer\LibraryInstaller->install() at phar:///usr/local/bin/composer/src/Composer/Installer/InstallationManager.php:152
 Composer\Installer\InstallationManager->install() at phar:///usr/local/bin/composer/src/Composer/Installer/InstallationManager.php:139
 Composer\Installer\InstallationManager->execute() at phar:///usr/local/bin/composer/src/Composer/Installer.php:548
 Composer\Installer->doInstall() at phar:///usr/local/bin/composer/src/Composer/Installer.php:217
 Composer\Installer->run() at phar:///usr/local/bin/composer/src/Composer/Command/UpdateCommand.php:128
 Composer\Command\UpdateCommand->execute() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:252
 Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:889
 Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:193
 Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:135
 Composer\Console\Application->doRun() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:124
 Symfony\Component\Console\Application->run() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:84
 Composer\Console\Application->run() at phar:///usr/local/bin/composer/bin/composer:43
 require() at /usr/local/bin/composer:15
halfer
  • 19,824
  • 17
  • 99
  • 186
Clément Andraud
  • 9,103
  • 25
  • 80
  • 158

22 Answers22

46

It happened once to me and it turns out that I was hitting composer's timeout.

You could take the following measures to gain some speed:

  1. Increase composer process-timeout (default 300) (not really needed if the following settings will help you gain speed, but can't hurt)
  2. Set dist as preferred install type.
  3. Enable https protocol for github, which is faster.

~/.composer/config.json

{
    "config": {
        "process-timeout":      600,
        "preferred-install":    "dist",
        "github-protocols":     ["https"]
    }
}

If you still have problems after that, you can also clear composer's cache:

rm -rf ~/.composer/cache
Alexandru Guzinschi
  • 5,675
  • 1
  • 29
  • 40
  • Yes i cleared the cache. I added these lines on my config.json in my symfony folder – Clément Andraud Oct 06 '14 at 13:15
  • 1
    Do you run composer as `vagrant` user ? And if not, what permissions that user has for `/vagrant` directory ? – Alexandru Guzinschi Oct 06 '14 at 13:22
  • 1
    I'm on SSH with the default vagrant user – Clément Andraud Oct 06 '14 at 13:23
  • Try to git clone a repository which fails to install under composer. At least you can identify the source of the problem: git or composer – Alexandru Guzinschi Oct 06 '14 at 13:35
  • If I git clone https://github.com/sonata-project/SonataAdminBundle i have the same error : fatal: fsync error on '/vagrant/SonataAdminBundle/.git/objects/pack/tmp_idx_gOBF8b': Permission denied fatal: index-pack failed – Clément Andraud Oct 06 '14 at 13:40
  • So is git or something related. Try to update git if you did not already did that ; try with `sudo` and you could rephrase your question and tag it as `git`. Maybe someone had encountered this problem before and can help you. – Alexandru Guzinschi Oct 06 '14 at 13:46
  • 1
    Solution worked for me, in a vagrant machine, using vagrant user via ssh. Not only the limit is higher, but the speed has increased a lot. Thanks! – Natxet Nov 03 '14 at 14:43
  • Config update worked for me too. I was getting an issue with deleting a simpletest cache file when working with Laravel. Thanks! – dave Jul 09 '15 at 10:47
  • I tried all this but was unlucky - I could not get it to work. Instead I re-ran composer update as root and it worked. My 'web' user should have had all the permissions so I could not see why it didn't work with that, though. – therobyouknow Jan 15 '17 at 23:23
  • Indeed, in my case it was a timeout problem ! Increase it worked like a charm for me ! – Nicolas Facciolo Feb 09 '21 at 08:15
39

I was trying to update project dependencies (using composer update) during a Laravel Framework upgrade exercise in my local Homestead environment (having run vagrant ssh to login as the default "vagrant" user) and none of the previous answers in this thread made any difference to the... 

Could not delete /home/vagrant/projects/projectname/vendor/kylekatarnls/update-helper/src/UpdateHelper

...error message I repeatedly encountered.

The only thing that worked for me was to include a composer option as follows:

composer update --no-plugins

Plugins are used to alter or extend the functionality of Composer. The above command disables all installed plugins. Unfortunately, I'm not clear as to why this command worked for me, as I certainly haven't written any plugins myself. All I can conclude is that there was an erroneous Composer plugin installed that was causing this issue.

w5m
  • 2,286
  • 3
  • 34
  • 46
  • 1
    This did not work for me (also on Laravel Homestead). Plus, it would be helpful to explain what `--no-plugins` does and what that would sacrifice. But it didn't work. – Ryan Feb 03 '20 at 23:21
  • 3
    This worked for me, but it then skipped some required packages (cakephp 4.x). When I use `--prefer-source` it installs all, but it's slow as f... – Jelmer Jan 08 '21 at 09:53
  • 2
    I had this problem with TYPO3 v9.5. This option solved it. Thanks! – Daviz Mar 12 '21 at 11:45
  • for Laravel Homestead, use NFS... it will solve the issue... take a look https://medium.com/@dogcomp/ec996f9a2cb6 at 4.2 for how to configure NFS. – Kidd Tang May 29 '21 at 13:56
  • 1
    Thank you, my issue was fixed with `composer update --no-plugins` – Andrei Lupuleasa Feb 03 '22 at 14:30
8

TL;DR Switch to Docker. It is the industry standard.

I came across this issue and spent quite some time doing research. I've tried every possible option to fix it but none of them worked for me. For me, the bug occurred on GNU/Linux host with Vagrant and VirtualBox provider.

It turns out it's a VirtualBox bug related to the file system layer and race conditions when creating/deleting files. It occurs only for VirtualBox shared folders, not for regular ones. The sad part is that it seems like it's not going to be fixed any time soon.

Some guys reported that they were able to solve the problem using the following tricks:

  • Downgrading to VirtualBox version 6.0.4.
  • Using nfs or rsync instead of shared folders.
  • Patching composer to add some pauses after certain operations.
  • Disabling plugin usage with --no-plugins option.

But all of this seemed dirty to me. I personally was able to use a workaround suggested on GitHub which is to configure composer to install packages from sources. That's a simple and kind of clean trick which should not have significant negative side effects on your workflow. Try putting the following config into your ~/.config/composer/config.json. Or instead you can edit your composer.json accordingly depending on your needs. Keep in mind that composer.json will override your global config.

{
    "config": {
        "preferred-install": "source"
    }
}
Kolyunya
  • 5,973
  • 7
  • 46
  • 81
  • 1
    This answer should have more votes. I too have had the issue before but completely forgot about it until you mentioned a VirtualBox bug - then it all came flooding back. Good news though! Looks like 5 days ago somebody was assigned to said bug, so hopefully there could be a more permanent fix in sight. – Dave S Oct 05 '20 at 09:17
  • 3
    While your "config" option was indeed the working solution for me, I cannot in good conscience upvote this answer because of it's weird TL;DR of "Duh, switch to Docker!" mentality. Sometimes vagrant machines can be complicated and do not have a Docker equivalent. What's weirder is that beyond the headline, you actually don't mention Docker in the answer at all! EDIT: I upvoted the answer anyways because it DID fix the issue, but the headline has no place here imo. – Daydream Nation May 20 '22 at 17:16
7

Just got the same issue.

I see the problem in accessing to some local files. In my case target directory was under "root" and I'm not the root user.

Solution

Change permissions/owner of your files/directory.

  1. Redefine owner:

    sudo chown myuser:myuser -R /path/to

  2. Maybe there is some lack of permissions for group which you are in.
    So, try to run:

    sudo chmod g+rwX -R /path/to

Or maybe you may run your command with "sudo" if it works for you (not recommended). :)

P.S. Never use 777. It's not secure.

UPD1

Another thing, you may found out useful to solve the root of the cause, to wrap up your composer binary to run it always behalf a certain user.

$ cat /usr/local/bin/composer
#!/bin/bash

# run composer behalf www-data user

set -o pipefail
set -o errexit
set -o nounset
#set -o xtrace

[[ "${DEBUG:-}" = "true" ]] && set -o xtrace || true

composer_debug=$([[ 'true' != "${COMPOSER_DEBUG:-}" ]] || echo '-vvv' )

sudo -u www-data -- /usr/bin/composer ${composer_debug:-} $@
Kirby
  • 2,847
  • 2
  • 32
  • 42
4

I had this problem when provisioning the machine, which was bootstrapped to run composer install. I simply exited the VM and ran composer install on the code on my host machine and it worked.

So, if you're facing this problem while running Composer inside the VM, just try running Composer from outside the VM.

Update: As pointed in the comments below, this can pose some problems with different versions of packages being installed owing to the difference in system configurations between the local and Vagrant environments, so exercise appropriate caution while trying this.

aalaap
  • 4,145
  • 5
  • 52
  • 59
  • 1
    This might get you going, but doesn't solve the problem. – YakobeYak Feb 15 '17 at 17:38
  • Be careful about this. Depending on for PHP version composer might want to download different packages. So if your vb has different version than your default os version than it might become a problem. – Maciej Paprocki Oct 30 '17 at 16:20
  • @MaciejPaprocki I agree and this also renders the whole point of using Vagrant useless, but it's something to do when you have nothing else in sight. – aalaap Oct 31 '17 at 06:44
  • @aalaap unfortunately, I've been in similar situation multiple times, however, it would be good to probably add that to your answer as novice users might have a lot of problems after doing that. – Maciej Paprocki Oct 31 '17 at 19:06
  • I try run composer under Windows and Vagrant. When i run composer under VM i have similar error with symfony packages. Under windows git bash terminal composer work correctly. Thank you a lot – Grzegorz Brzęczyszczykiewicz Jul 17 '18 at 19:06
  • Not a satisfactory answer - the entire point of Vagrant is running these kind of commands from within it / not having to worry about the host machine OS or software versions. – Daydream Nation May 20 '22 at 17:18
3

We're running into issues also. There are several people who seem to have this issue, a fix has not been provided. For more information you can look into github issues of vagrant-winnfsd.

vokx
  • 76
  • 2
2

Just run 

sudo chmod -R 777 /folder/path

This will give you write access to the folder you are running composer in. I know this is an old post but this works so I have to share it.

Michael Obi
  • 526
  • 1
  • 6
  • 17
2

for my case, I only used the NFS folders type instead of the shared folders and it works:

folders:
    - map: ~/code/cs-cart-trial
      to: /home/code/cs-cart-trial
      type: "nfs"
Dharman
  • 30,962
  • 25
  • 85
  • 135
Yassine Qoraiche
  • 1,077
  • 14
  • 32
1

In my case I was trying composer update but I got

[RuntimeException] Could not delete .../vendor/bin/php-parse:

Despite I'm using Laravel framework, this question was the first link in Google, so I decided to post an answer.

My solution was to grant ownership for vendor: sudo chown -R $USER:www-data vendor/ and
sudo chown -R $USER:www-data composer.json

Update: my host OS was Ubuntu 16.04.

Tarasovych
  • 2,228
  • 3
  • 19
  • 51
  • I too am using Laravel Homestead vagrant and suddenly started getting problems this morning saying `[RuntimeException] Could not delete`. Unfortunately your solution didn't change anything for me. – Ryan Feb 03 '20 at 17:38
  • @Ryan my solution is not universal, in my case the problem was with ownership of `composer.json` file and `vendor`. Check your permissions for other folders as well. – Tarasovych Feb 04 '20 at 15:03
  • This happened to me multiple times yesterday and was temporarily solved by rebooting Windows. My latest guess, though, is that it's related to NetBeans 11.2. I recently upgraded from NetBeans 8.2, and I think 11.2 is much slower and seems to be accessing files more often and must be messing with their permissions. – Ryan Feb 04 '20 at 15:14
  • @Ryan oh, you're using Windows as host system. I've updated my answer. – Tarasovych Feb 04 '20 at 15:46
1

Having the same issue for Cakephp 4.2.1

Error:

Could not delete /var/www/vendor/cakephp/plugin-installer/src:

Solution:

Based of https://stackoverflow.com/a/63139337/1110760

After trying out several options mentioned above, for me this was the easiest way to solve it.

composer install --prefer-source

The argument --no-plugins worked as well, sort of. It skipped some packages but my localhost seemed to work just fine. This is faster, but it's missing some.

Jelmer
  • 2,663
  • 2
  • 27
  • 45
0

On AWS I got this error while deploying Yii framework project there was this

/var/app/current/vendor/

folder i deleted everything inside it came back to my document root and ran composer update it fetched all the repos again.

Swapnil Gondkar
  • 345
  • 1
  • 4
  • 12
0

In my case , by removing the plugin and re-create the box solve the issue.

Ahmad Satiri
  • 459
  • 1
  • 7
  • 16
0

For me it caused by composer's timeout. I checked my internet speed and found it dropped to 0.7M which is nearly unusable. After I reconnected the wifi and have my internet connection speed back to normal, the errors are gone.

Tim Yao
  • 1,077
  • 1
  • 13
  • 17
0

This has something do to with the synchronization of the folders between host and guest OSes, the folder might be simply temporarily locked from your host machine.

The solution is simply to delete the offending .git folder from your host OS or reboot the machine and launch composer install again.

Ideally each OS has its own dependencies and different binaries, therefore you should isolate your /vendor folder out from the rsync/vagrant folder share, likewise you would do the same with /node_modules on a Nodejs project.

MacK
  • 2,132
  • 21
  • 29
0

Another thing to check for, Composer needs to run in the context of a directory it has permissions to.

In my case I was trying to issue a create-project command from /var/www, aimed against /var/www/html. /var/www is owned by root, /var/www/html is owned by the same user I executed Composer as (www-data). I got the following error; Could not delete /var/www/html/:

Issued the same Composer command from within /var/www/html itself and it worked perfectly.

Nanaki
  • 1
0

To me it helped to install a (new) version via command line from download homepage https://getcomposer.org/download/. I can exclude some file permissions as I was root with chmod +R 0777, though I had virtualbox mounted drive. Anyway since new version worked, would mean it was version, or running a new version via php phar, and the original bin belonged to root

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === '48e3236262b34d30969dca3c37281b3b4bbe3221bda826ac6a9a62d6444cdb0dcd0615698a5cbe587c3f0fe57a54d8f5') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"
FantomX1
  • 1,577
  • 2
  • 15
  • 23
0

I have solved the problem by creating a mount : In /home/vagrant create a folder named vendor then apply command : mount --bind /home/vagrant/vendor /path/to/source/vendor

Dharman
  • 30,962
  • 25
  • 85
  • 135
Coolhand
  • 106
  • 1
  • 9
0

It's a bit unrelated with the question, but in my case with Docker. It was failing because Webpack was watching and it didn't allow other files to be deleted.

It worked when I turned off Webpack.

DevExcite
  • 399
  • 4
  • 6
0

I had same problems trying composer install

- Installing aws/aws-sdk-php (3.218.3): Extracting archive
Install of aws/aws-sdk-php failed

In Filesystem.php line 330:

  Could not delete /home/vagrant/code/my-project/vendor/composer/cefa44c2/aws-aws-sdk-php-a1bd217/src:

What I did I comment it out

type: "nfs"

from my homestead.yaml

and make a fresh vagrant provision

I'm using Oracle Virtual box 6.1 on Windows 10.

Yevgeniy Afanasyev
  • 37,872
  • 26
  • 173
  • 191
0

Turn of Dropbox or other file sync

Morten Landmark
  • 1
  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Dec 06 '22 at 20:45
-1

Best hack i found was to replace the unlink commands with the one below. I am running ubuntu.

sudo nano +219 /usr/share/php/Composer/Util/Filesystem.php

exec("sudo rm -rf $path"); return true;

Ahad Ali
  • 398
  • 5
  • 11
  • Not a good idea: If the problems are permissions, clarify why. Your answer suggests to just circumvent permissions. Messed up permissions are a sign of something wrong elsewhere. – Ulrich Eckhardt Jan 17 '22 at 17:45
-3

For Windows users

Wow, I can't believe how long it took me to realize this, and sadly it has happened multiple times, and I'm finally writing this note so that I and others can quickly recover next time.

  1. Just use Windows Explorer to go delete the /vendor/whatever_project_name folder instead of trying to delete it from the Vagrant command line.

  2. Then run composer update to reinstall the dependencies.

Ryan
  • 22,332
  • 31
  • 176
  • 357