Should Vagrant require sudo for each command?

Question

My question in short: I run into permissions error every time I execute any Vagrant command without 'sudo' - from vagrant up to vagrant provision. Is this expected behaviour?

/Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/machine.rb:295:in `unlink': Permission denied - /Users/Cibulka/Sites/.vagrant/machines/default/virtualbox/id (Errno::EACCES)
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/machine.rb:295:in `delete'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/machine.rb:295:in `id='
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/machine.rb:438:in `state'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/action/created.rb:11:in `call'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builder.rb:116:in `call'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/runner.rb:66:in `block in run'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/util/busy.rb:19:in `busy'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/runner.rb:66:in `run'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builtin/call.rb:43:in `call'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builder.rb:116:in `call'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/runner.rb:66:in `block in run'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/util/busy.rb:19:in `busy'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/runner.rb:66:in `run'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/machine.rb:196:in `action_raw'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/machine.rb:173:in `block in action'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/environment.rb:434:in `lock'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/machine.rb:161:in `call'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/machine.rb:161:in `action'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/commands/provision/command.rb:35:in `block in execute'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/plugin/v2/command.rb:226:in `block in with_target_vms'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/plugin/v2/command.rb:220:in `each'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/plugin/v2/command.rb:220:in `with_target_vms'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/commands/provision/command.rb:34:in `execute'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/cli.rb:42:in `execute'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/environment.rb:252:in `cli'
from /Applications/Vagrant/bin/../embedded/gems/gems/vagrant-1.6.3/bin/vagrant:166:in `<main>'

I am running on Mac OSX, 10.7.5.

Sidenote

Besides the permission error mentioned above, I receive a lot of other various errors and timeouts, so I suspect that there may be something fundamentally wrong with my Vagrant installation (maybe permission wise?). But as I am clearly no Unix ninja, I'm not really sure what is the problem here. Most of the errors, according to Google, are pretty common and can be caused by multiple reasons (such as "Timed out while waiting for the machine to boot." or else).

Recently, after xth trail, I was able to successfuly vagrant up. I received this error: The private key to connect to the machine via SSH must be owned by the user running Vagrant." After running ...

sudo chown root insecure_private_key

... my Vagrant seems to act little more stable.

This just a sidenote to provide some (pretty localized) context to my question, so feel free to edit/delete it, if it does not provide any value.

Answer 1

I did my first vagrant up as a part of my own installation script, which is ran as sudo. Because of that, every file installed belonged to the root user, not my current account.

Related:

• https://github.com/Varying-Vagrant-Vagrants/VVV/issues/261
• Vagrant Up by Non-Sudo Vagrant User fails

In short, when you arrive to similar problem, you can always "reclaim" the ownership of relevant files.

chown -R <USERNAME> /<YOUR-WEBSITES-DIRECTORY>/.vagrant/machines/

chown -R <USERNAME> /<YOUR-HOME-DIRECTORY>/.vagrant.d

vagrant up and other command should work without sudo from now on.

Answer 2

I had to change the user/group of "/media" for vagrant to be able to create VMs within this folder.

sudo chown -R <USERNAME>:<USERNAME> /media

After that, vagrant up worked as expected without requiring sudo privileges.

Answer 3

For Vagrant users that rely on libvirt for creating the virtual machine:

I found another possible thing to do in order to run vagrant without sudo. But I am running it on Ubuntu so not totally sure it applies to Mac OS. But still I am quite confident about it since it is mostly about unix rights.

While googling my problem, I found out this Red hat doc that explains the problem: When you install libvirt, it creates a "libvirt" group on the system and states that only people from this group can use it.

So all you have to do is add yourself to that group. For example on systems where usermod is available, that would be:

sudo usermod -a -G libvirt your_username

You have to log out (or reboot) for the new group to apply to your user