each time I do the vagrant up command I get the error
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
chown `id -u vagrant`:`id -g vagrant` /vagrant
Stdout from the command:
Stderr from the command:
chown: changing ownership of ‘/vagrant’: Not a directory
I can't find any solutions ( already tried to change the sudoers file but don't know exactly what to change)
chown: changing ownership of ‘/vagrant’: Not a directory
This sounds like /vagrant is Not a directory, which probably it is a file, therefore remove the file and re-try again.
Or try to re-create your VM again, also double check your Vagrantfile if such file is not created.
To investigate the issue further, run the vagrant in the debug mode, e.g.
vagrant up --debug
Using a version 0.21 for vagrant-vbguest helped me to fix mine
vagrant plugin uninstall vagrant-vbguest
vagrant plugin install vagrant-vbguest --plugin-version 0.21
I have been trying to get a Vagrant 1.9.1-VirtualBox 5.1.10-Fedora 25 x64-Atomic host image running on my Windows 10 x64 Host.
I thought the Vagrant plugin vbguest didn't work well with the Atomic host type, as it mentioned during the provisioning.
Turns out the error still occurred for me, and I found this bug report: Vagrant cannot create synced folder.
dustymabe seems to support the situation with a temporary workaround until the bug is fixed by using this line of code:
config.vm.synced_folder "/tmp", "/vagrant", disabled: 'true'
jorti, the user that seems to be having the same issue as I, has used these lines of code both to workaround the bug, and set-up their own pathway to continue working with the same feature:
config.vm.synced_folder ".", "/vagrant", disabled: true
config.vm.synced_folder ".", "/home/vagrant/provision", type: "rsync"
This issue was reported on Nov 25 2016 at 14:45:46, and was only commented on currently just up to 3 days after that time.
This is no permission problem, but a simple error message, that the expected home directory "/vagrant" does not exist. It may be a file or just not existent.
Anyway this command has to be called by user root.
Just create that directory:
mkdir /vagrant
as user root.
Related
Having just updated to the newest Windows 10 release (build 14316), I immediately started playing with WSL, the Windows Subsystem for Linux, which is supposed to run an Ubuntu installation on Windows.
Maybe I'm trying the impossible by trying to install Apache on it, but then someone please explain me why this won't be possible.
At any rate, during installation (sudo apt-get install apache2), I received the following error messages after the dependencies were downloaded and installed correctly:
initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: No such file or directory
runlevel:/var/run/utmp: No such file or directory
* Starting web server apache2 *
* The apache2 configtest failed.
Output of config test was:
mktemp: failed to create directory via template '/var/lock/apache2.XXXXXXXXXX': No such file or directory
chmod: missing operand after '755'
Try 'chmod --help' for more information.
invoke-rc.d: initscript apache2, action "start" failed.
Setting up ssl-cert (1.0.33) ...
Processing triggers for libc-bin (2.19-0ubuntu6.7) ...
Processing triggers for ureadahead (0.100.0-16) ...
Processing triggers for ufw (0.34~rc-0ubuntu2) ...
WARN: / is group writable!
Now, I understand that there seem to be some folders and files missing for Apache2 to work. Before I start changing anything that will mess with my Windows installation, I want to ask whether there's a different way? Also, should I worry about / being group writable or is this just standard Windows behaviour?
In order to eliminate this warning
Invalid argument: AH00076: Failed to enable APR_TCP_DEFER_ACCEP
Add this to the end of /etc/apache2/apache2.conf
AcceptFilter http none
Note the following in your output
failed to create directory via template '/var/lock/apache2.XXXXXXXXXX': No such file
I tried listing /var/lock. It points to /run/lock, which doesn't exist.
Create the directory with
mkdir -p /run/lock
The install should now work (you may need to clean the installation first)
You have to start bash.exe in administrator mode to avoid a lot of problems related to network.
i installed Lamp (Apache/MySQL/Php) without any problem :
Start bash.exe in administrator mode
type : sudo apt-get install lamp-server^
add these 2 lines in /etc/apache2/apache2.conf :
Servername localhost
AcceptFilter http none
then you can start apache :
/etc/init.d/apache2 start
Following the great advice here I edited apache2.conf and inserted the following to end of file after receiving all the various errors above and apache2 then worked great on the debian wsl package:
Servername localhost
AcceptFilter http none
AcceptFilter https none
I'm getting a very strange error when I run ansible:
GATHERING FACTS ***************************************************************
fatal: [i-0f55b6a4] => Could not make dir /$HOME/.ansible/cp: [Errno 13] Permission denied: '/$HOME'
TASK: [Task #1] ***************************************************************
FATAL: no hosts matched or all hosts have already failed -- aborting
PLAY RECAP ********************************************************************
to retry, use: --limit #/home/ubuntu/install.retry
i-0f55b6a4 : ok=0 changed=0 unreachable=1 failed=0
Normally, this playbook runs without problems, but I've recently made some changes so that the program that calls ansible is called from start-stop-daemon so that I will run as a service. The ultimate goal being to have a service that can run the playbook automatically, when it deems it necessary.
The beginning of the playbook looks like this:
---
- hosts: w_vm:main
sudo: True
tasks:
- name: Task #1
...
sudo is set to True so I'm somewhat certain that the error is not on the target machine.
The generated invocation of ansible-playbook looks like this:
ansible-playbook -i /tmp/ansible3397486563152037600.inventory \
/home/ubuntu/playbooks/main_playbook.yml \
-e #/home/ubuntu/extra_params.json
I'm not sure if that Could not make dir /$HOME/.ansible/cp error is occurring on the server or on the remote machine, or why ansible is trying to make a directory named $HOME in /. This only happens when the program that calls ansible is called from the linux service, not when it's called explicitly from the command line.
I've asked a more specific question here:
https://unix.stackexchange.com/questions/220841/start-stop-daemon-services-environment-variables-and-ansible
Try sudo chown -R YOUR_USERNAME /home/YOUR_USERNAME/.ansible
Late to answer but might be useful to someone. Check the ownership of ~/.ansible. The ownership of .ansible in the local machine (which runs ansible/ansible controller node) might be causing the problem. Do "chown -R username:groupname .ansible" (username:groupname should be of the user running the playbook) and try to run the playbook again
As an alternative remove this .ansible directory from controller node and rerun the playbook.
Ansible creates temporary files in ~/.ansible on your local machine and on the remote machine. So that could be theoretically triggered from both sides.
My guess is, it is on the local machine where Ansible runs since how Ansible was started should not have an effect on the target boxes. A quick search showed programs started with start-stop-deamon do not have $HOME (or any env at all) available, but it has an -e option to set them according to your needs.
If -e is unavailable, see this answer, which suggests to additionally exec /usr/bin/env to set environment variables.
I ran into a similar issue using Jenkins. It had a default $HOME env var set to /root/. The solution was to inject the environment variable at runtime.
HOME=/path/to/your/users/home
I’m using Cygwin (CYGWIN_NT-6.3-WOW64) under Windows 8. I’m also running Vagrant (1.7.2) and Ansible (1.8.4). To be complete, my Virtualbox is 4.3.22.
Cygwin and Vagrant have been installed from their respective Windows install packages. I’m running Python 2.7.8 under Cygwin and used ‘pip install ansible’ to install Ansible.
All of these applications work fine in their own right. Cygwin works wonderfully; I use it as my shell all day, every day with no problems.
Vagrant and Virtualbox also work with no problems when I run Vagrant under Cygwin. Ansible works fine under Cygwin as well when I run plays or modules against the servers on my network.
The problem I run into is when I try to use Ansible to provision a Vagrant VM running locally.
For example, I vagrant up a VM and then draft a simple playbook to provision it. Following are the Vagrantfile:
VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.define :drupal1 do |config|
config.vm.box = "centos65-x86_64-updated"
config.vm.hostname = "drupal1"
config.vm.network "forwarded_port", guest: 80, host: 10080
config.vm.network :private_network, ip: "192.168.56.101"
config.vm.provider "virtualbox" do |v|
v.name = "Drupal Server 1"
v.memory = 1024
end
config.vm.provision :ansible do |ansible|
ansible.playbook = "provisioning/gather_facts.yml"
end
end
and playbook:
---
- hosts: all
gather_facts: yes
However, when I run ‘vagrant provision drupal1’, I get the following error:
vagrant provision drupal1
==> drupal1: Running provisioner: ansible... PYTHONUNBUFFERED=1 ANSIBLE_FORCE_COLOR=true ANSIBLE_HOST_KEY_CHECKING=false
ANSIBLE_SSH_ARGS='-o UserKnownHostsFile=/dev/null -o
ControlMaster=auto -o ControlPersist=60s' ansible-playbook
--private-key=C:/Users/mjenkins/workspace/Vagrant_VMs/Drupal1/.vagrant/machines/drupal1/virtualbox/private_key
--user=vagrant --connection=ssh --limit='drupal1' --inventory-file=C:/Users/mjenkins/workspace/Vagrant_VMs/Drupal1/.vagrant/provisioners/ansible/inventory
provisioning/gather_facts.yml PLAY [all]
GATHERING FACTS
fatal: [drupal1] => private_key_file
(C:/Users/mjenkins/workspace/Vagrant_VMs/Drupal1/.vagrant/machines/drupal1/virtualbox/private_key)
is group-readable or world-readable and thus insecure - you will
probably get an SSH failure PLAY RECAP
to retry, use: --limit #/home/mjenkins/gather_facts.retry
drupal1 : ok=0 changed=0 unreachable=1
failed=0 Ansible failed to complete successfully. Any error output
should be visible above. Please fix these errors and try again.
Looking at the error, its plainly obvious that it has something to do
with Ansible’s interpretation of my key and the file permissions on
either it or the folder its in.
Here are a few observations and steps I’ve tried:
I tried setting the permissions on the file and all the directories leading up to the file in Cygwin. That is chmod -R 700 .vagrant in the project directory. Still got the same error.
The key file is being referenced using a Windows path, not a Cygwin path (odd, though, that the file in the limit output has a Cygwin path). So I checked the permissions from the Windows side and changed it so that ‘Everyone’ has no access to .vagrant and all files/folders under it. Still got the same error.
Then I thought there might still be some problems with the file permissions/paths between my Cygwin based Ansible so I installed Python for Windows; used that pip to install Ansible, set my paths to that location, created an ansible-playbook.bat file, and ran Vagrant from a Windows cmd shell. Glad to say that tool chain worked….but I still got the same problem.
At this point I’m just about out of ideas so I turn to you, friends of Stackoverflow, for your input.
Any thoughts on solving this problem?
Your private key is very open and accessible by anyone. A check in SSH client prevents using such keys.
Try changing permissions with chmod from your cygwin or git bash, on your private and public keys.
On C:/Users/mjenkins/workspace/Vagrant_VMs/Drupal1/.vagrant/machines/drupal1/virtualbox/private_key
with chmod 700 private_key and ensure you have -rwx------ with ls -la
BAAAH! I just commented out the check in lib/ansible/runner/connection.py
Then I had to add in ansible.cfg
[ssh_connection]
control_path = /tmp
My solution to this was to override synced folder's permissions settings in the VagrantFile with the following ones:
Vagrant.configure(2) do |config|
config.vm.synced_folder "./", "/vagrant",
owner: "vagrant",
mount_options: ["dmode=775,fmode=600"]
...
I had similar issue and figured out a solution. I added following entries in my vagrant file
config.ssh.insert_key = false
config.ssh.private_key_path = "~/.vagrant.d/insecure_private_key"
and copied the insecure_private_key from my windows user folder to cygwin home as the path above. afterwards I did a
chmod 700 ~/.vagrant.d/insecure_private_key
and as a last step I removed the content of this file in cygwin home
~/.ssh/known_hosts
once I rerun the ansible-playbook command, I confirmed to add my localhost back to the known_hosts and the ssh connection worked.
truly saying it is much simpler if you understand what is happening.
Vagrant keep one folder for sharing file with host and other VM, that is /vagrant . Anything into that will be having mode 777 nothing can be done for that. sudo chmod too will not help , and you cannot change the mode.
Ansible is asking you to reduce the mode so that is not readable by group or all
so it is as simple as making a copy of the private key from
/vagrant/.vagrant/machines/yourmachine/virtualbox or any provisioner/
to may be home i.e ~ or /root
and then change chmod to 700 and use it in the inventory list in hosts file.
You could use the ansible_local provisioner for Vagrant. That will install Ansible into the VM. If you work with multiple vagrant virtual machines, then is is useful to let one be the ansible controller. This would then need the private SSH key. That can be done in the Vagrantfile with:
config.vm.provision "file", source: "~/.vagrant.d/insecure_private_key", destination: "/home/vagrant/.ssh/id_rsa"
config.vm.provision "shell", inline: "chmod 600 /home/vagrant/.ssh/id_rsa"
I am trying to set up a Vagrant environment to host Snowplow (https://github.com/snowplow). When I launch vagrant from a cygwin shell
$vagrant up && vagrant ssh
I get into an Ubuntu guest image (12.04), and when I attempt to install java8 into this environment using ansible, I get this message:
vagrant#precise64:~$ ansible-playbook
/vagrant/ansible-playbooks/java8-gradle.yml
--inventory-file=/vagrant/home/ansible/ansible_hosts --connection=local ERROR: The file /vagrant/home/ansible/ansible_hosts is marked as executable, but failed to execute correctly. If this is
not supposed to be an executable script, correct this with chmod -x
/vagrant/home/ansible/ansible_hosts.
The file is indeed 777:
-rwxrwxrwx 1 vagrant vagrant 24 Mar 3 19:03 ansible_hosts*
but this same file is sync'd to the host (Windows) and cygwin shows the file as 644:
-rw-r--r-- 1 rcoe Domain Users 24 Mar 3 14:03 ansible_hosts
Is there a known issue running in a headless (VirtualBox) Vagrant environment that doesn't allow permissions to be set on files that are sync'd to the host?
Thanks.
It is a known deficiency, but reportedly not a bug: Changing shared folder permissions from within virtual machine
There is a good tutorial on how to set up the synced folder in vagrant so that it would suit your needs - if you navigate to that link it will show the following snippet
config.vm.synced_folder "./", "/var/sites/dev.query-auth", id: "vagrant-root",
owner: "vagrant",
group: "www-data",
mount_options: ["dmode=775,fmode=664"]
that shows how to adjust the permissions of the synced folder.
Alternatively you could also use a different method of syncing the folder, such as rsync (keeping in mind what the trade-offs are)
config.vm.synced_folder "/Users/ryansechrest/Projects/Sites", "/var/www/domains",
type: "rsync"
More on that here
Vagrant creates a development environment using VirtualBox and then provisions it using ansible. As part of the provisioning, ansible runs a reboot and then waits for SSH to come back up. This works as expected but because the vagrant machine is not being started from a "vagrant up" command the synced folders are not mounted properly when the box comes back up from the reboot.
Running "vagrant reload" fixes the machine and mounts the shares again.
Is there a way of either telling vagrant to reload the server or to do all the bits 'n bobs that vagrant would have done after a manual restart?
Simply running "sudo reboot" when SSH-ed into the vagrant box also produces the same problem.
There is no way for Vagrant to know that the machine is being rebooted during the provisioning.
If possible, the best would be to avoid rebooting here altogether. For example kernel updates should be already done when building the base box.
Another easy (but not very convenient) way is to handle it with log output or documentation, or with a wrapper script which invokes vagrant up && vagrant reload.
And finally, you could write a plugin which injects all the needed mounting etc. actions to Vagrant middleware stack after the provisioning, but you would still need to think how to let the plugin know that the machine has been booted. Other challenge is that this easily gets provider specific.
You should be able to add the filesystems to /etc/fstab to mount on boot.
Here's my example:
vagrant /vagrant vboxsf defaults 0 0
home_vagrant_src /home/vagrant/src vboxsf defaults 0 0
home_vagrant_presenter-src /home/vagrant/presenter-src vboxsf defaults 0 0
Your vagrant directory should have a .vagrant hidden directory in it, and in there you should find a path to the "synced_folders" file (in my case: /vagrant/.vagrant/machines/default/virtualbox/synced_folders).
That file should help you figure out what the labels are and their mount points:
{"virtualbox":{"/home/vagrant/src":{"guestpath":"/home/vagrant/src","hostpath":"/home/rkomorn/src","disabled":false,"__vagrantfile":true},"/home/vagrant/presenter-src":{"guestpath":"/home/vagrant/presenter-src","hostpath":"/home/presenter/src","disabled":false,"__vagrantfile":true},"/vagrant":{"guestpath":"/vagrant","hostpath":"/home/rkomorn/vagrant","disabled":false,"__vagrantfile":true}}}
It's not the easiest to read but, using python terminology, the labels appear to be the inner dictionary's keys, with / translated to _ (eg: the /home/vagrant/presenter-src key became the home_vagrant_presenter-src label).
I'm actually not sure why vagrant doesn't just use /etc/fstab for shared folders but I'm guessing there's a good reason.
Split your provisioners into two separate steps and use the vagrant-reload plugin as additional provisioner between.
Example Vagrantfile:
config.vm.provision "Step 1 - requires reboot", type: "shell", path: "scripts/part1.sh"
config.vm.provision :reload
config.vm.provision "Step 2 - happens after reboot", type: "shell", path: "scripts/part2.sh"
In case anyone else runs into this issue and finds this question like I did here's how I worked around the issue:
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure("2") do |config|
config.vm.box = "..."
# create a shared folder for the top-level project directory at /vagrant
# normally already configured but for some reason it isn't on these boxes
# https://www.vagrantup.com/docs/synced-folders/virtualbox.html#automount
# http://www.virtualbox.org/manual/ch04.html#sf_mount_auto
config.vm.synced_folder ".", "/mnt/vagrant", id: "vagrant", automount: true
config.vm.provision "shell", inline: "usermod -a -G vboxsf vagrant"
config.vm.provision "shell", inline: "ln -sfT /media/sf_vagrant /vagrant"
# More settings omitted...
end
There's a few parts to this solution:
The first line assigns a specific id of vagrant to the shared folder. This is important because the automatic mount functionality in VIrtualBox uses /mnt/sf_<id> by default. It also mounts the folder at /mnt/vagrant to keep it out of the way. Ideally you'd pick a more obscure location that's present on all of your VMs or just document not to use it there.
The third line creates a symbolic link from the automatic mount location at /mnt/sf_vagrant to the usual place users expect the shared folder at /vagrant.
The second line adds the vagrant user in the virtual machine to the vboxsf group. This is necessary to access files inside /mnt/sf_vagrant because the guest utilities mount the folder with root:vboxsf ownership. They also set appropriate file and directory modes so it works fine in practice but you do need to be a member of the vboxsf group.
This solution has the following benefits:
The mount at /mnt/sf_vagrant is automatically mounted by the virtualbox guest utilities after a reboot so /vagrant should always be available.
It does not require installing plugins or using any outside tools.
It has the following drawbacks:
Potential for unexpected behavior if users find and use the /mnt/vagrant mount. That mount will only be present if the virtual machine was most recently booted / rebooted through the vagrant console client otherwise it will not be present.
It requires a relatively recent version of VirtualBox and Vagrant.
EDIT: Added -T option to ln to avoid the corner case where it creates /vagrant/sf_vagrant as a symlink.
I had a same issue. This is what I had in my /etc/fstab.
#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
vagrant_data /vagrant_data vboxsf uid=1000,gid=1000,_netdev 0 0
vagrant /vagrant vboxsf uid=1000,gid=1000,_netdev 0 0
#VAGRANT-END
So if you see fstab entry is still there, all you have to do is run sudo mount -a to trigger mount again. Or you can copy this lines.