Ansible text file busy error

Question

I have a Vagrant / Ansible set up on my Windows host. Ansible is set up to run on the Ubuntu guest, as Vagrant up executes a shell script which copies the provisioning yml files onto the guest and installs Ansible also on the guest.

The script runs the Ansible set up on the guest with the following command:

# Ansible installations
sudo apt-get install -y ansible

# Copy all Ansible scripts to the ubuntu guest
sudo cp -rf -v /vagrant/provisioning /home/vagrant/

# cp /vagrant/hosts /home/vagrant/
sudo chmod 666 /home/vagrant/provisioning/hosts

# Install roles
sudo ansible-playbook /home/vagrant/provisioning/local.yml -i /home/vagrant/provisioning/hosts --connection=local

One of the steps in the Ansible configuration process is setting up a fresh copy of Laravel in the /var/www directory. After pulling in Laravel, my script then copies and then edits the .env file in document root (/var/www).

But therein is the problem, it fails with text file busy message. This is a copy that is happening on the guest as source and destination, so I guess nothing to do with VBox. I have a feeling it has to do with the file name being so unusual, but I have not found an answer.

My task.yml file for Laravel is:

---
- name: Clone git repository
  git: >
      dest=/var/www
      repo=https://github.com/laravel/laravel.git
      update=no
  sudo: yes
  sudo_user: www-data
  register: cloned

- name: copy .env file
  copy: src=env.j2 dest={{ conf_file }}

- name: set APP_DOMAIN={{ server_name }}
  lineinfile: dest=/var/www/.env regexp='^APP_DOMAIN=' line=APP_DOMAIN={{ server_name }}

I have also tried using the template method with the same error:

- name: copy .env file
  template: src=env.j2 dest={{ conf_file }}

My conf file contains:

conf_file: /var/www/.env

It fails at the copy step as follows:

==> default: TASK: [laravel | copy .env file] **********************************************
==> default: failed: [10.0.1.10] => {"failed": true, "md5sum": "a380715fa81750708f7b9b6fea1a48fe"}
==> default: msg: Could not replace file: /root/.ansible/tmp/ansible-tmp-1441176559.19-197929606462535/source to /var/www/.env: [Errno 26] Text file busy
==> default:
==> default: FATAL: all hosts have already failed -- aborting
==> default:
==> default: PLAY RECAP ********************************************************************
==> default:            to retry, use: --limit @/root/local.retry
==> default:
==> default: 10.0.1.10                  : ok=21   changed=18   unreachable=0    failed=1
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

The .env source file is in a folder called files off the Laravel task folder, same as other items I configure which work OK. The file .env is not found in the www folder after it fails so it does not copy it.

Answer 1

There have been some issues with using the Ansible "copy" module on Virtualbox shared folders apparently (cf https://github.com/ansible/ansible/issues/9526) - is the /var/www/ directory a shared folder set up by Vagrant?

Maybe try touching the file first to create it, then copying it:

Change:

- name: copy .env file
  copy: src=env.j2 dest={{ conf_file }}

into:

- name: create .env file
  shell: touch {{ conf_file }}
- name: copy .env file
  copy: src=env.j2 dest={{ conf_file }}

EDIT: This file copy error was fixed in the Ansible 1.9.3 release (July 19th 2015) for some users, but is still a problem for people on Windows hosts running Virtualbox (to do with vboxsf sharing) as of 2016-06-14. The GitHub issue is still closed, but people are still commenting and seem to be supplying possible fixes.

The solution linked below appears to work for most people (several upvotes). It suggests adding the Ansible remote_tmp configuration setting to your local ~/.ansible.cfg which instructs Ansible to use a temp folder on the target (shared) filesystem:

https://github.com/ansible/ansible/issues/9526#issuecomment-199443969