116

I'm not looking for this answer, because my question is different.

When I type vagrant global-status I get a list of vms, but some of those directories and VMs have been deleted along with the Vagrantfiles.

But when i type vagrant destroy [machineid], I get the following error, which I am looking to resolve. Please advise.

The working directory for Vagrant doesn't exist! This is the
specified working directory:

/Users/steven/projects/php/vagrant-laravel
Community
  • 1
  • 1
user710587
  • 1,263
  • 2
  • 9
  • 4

6 Answers6

252

You should use the following command to remove invalid entries from the global index:

vagrant global-status --prune
Emyl
  • 10,460
  • 2
  • 35
  • 34
  • Well, nice that it is an accepted and upvoted answer, but this "prunes" the global-status list. Meaning that the VM no longer shows up in the list. The VM itself remains untouched, though. Meaning one still has to unregister and delete it manually. The very simple thing should be that vagrant does its job properly when given `$ vagrant destroy -f ` – silverdr Dec 14 '15 at 16:04
  • The output of `vagrant global-status --prune` is correct to not be aware of deleted Vagrant directories as Vagrant's knowledge of the VM it managed in that directory was removed when its files managing the VM were. It's the hypervisor's problem now. – bschlueter Aug 09 '16 at 20:25
  • Thanks!! I searched this a long time – Jean-Marc Amon Feb 13 '18 at 10:12
17

I had this issue as well. I was able to fix it by modifying the contents of ~/.vagrant.d/data/machine-index/index. It's in JSON format so I just removed the data related to instances that no longer existed.

I only removed the data that pertained to instances that no longer exist. I wouldn't modify any data that relates to an instance that exists in the file system.

Sarcastron
  • 1,527
  • 14
  • 20
  • I found this useful for just clearing the global-status boxes, which are usually off when I restart the host (my mac). It makes me wonder what the global-status does and if it has an affect on up'ing the box again. – kaplan May 11 '17 at 14:54
16

--prune didn't work for me. I removed ~/.vagrant, ~/.vagrant.d and .vagrant. And manually removed lingering VMs.

I migrated back gems and boxes from original ~/.vagrant.d. Perhaps one can try only removing machine from .vagrant but I didn't test that.

akostadinov
  • 17,364
  • 6
  • 77
  • 85
  • 2
    I had this issue when the directory that the vagrant image was stared in had been deleted. --prune failed but rm -rf ~/.vagrant* worked. Running vagrant global-status after recreated the appropriate directories. (This removes all downloaded boxes to they will be re-downloaded on next vagrant up as needed) – Tommy Strand Jun 09 '15 at 13:06
3

Use vagrant box remove -f [name]

It works. Guaranteed!

Sergey Glotov
  • 20,200
  • 11
  • 84
  • 98
Pendragon
  • 81
  • 4
0

I used 

vagrant global-status --prune
vagrant box remove -f [name]

Also I removed 

~/.vagrant, ~/.vagrant.d and .vagrant.

And manually removed lingering VMs if exists.

David Buck
  • 3,752
  • 35
  • 31
  • 35
Mehmet Özkan YAVUZ
  • 41
  • 5
0

I am working on windows powershell
when vagrant global-status --prune not allow.
debug by this command:
vagrant global-status --prune --debug
look for your path of vagrant.d

my situation

INFO global: VAGRANT_HOME="F:\Vagrant\vagrant.d"

delet F:\Vagrant\vagrant.d\data\machine-index*

"vagrant global-status" again will clear all cache.

maybe linux had same file in machin-index. you can try it.

jacky lin
  • 1
  • 1
  • As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Jan 01 '23 at 05:15