Unarchive module thinks existing dirs are nonexistent

[ghost]

Issue Type:

Bug Report

Ansible Version:

ansible 1.9 (devel eb850bf) last updated 2015/03/12 12:05:31 (GMT -400)

Environment:

Linux vm0 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:12 UTC 2014 i686 i686 i686 GNU/Linux
DISTRIB_DESCRIPTION="Ubuntu 14.04.1 LTS"

Summary:

Attempting to use the 'unarchive' module to unpack a tgz to remote:/opt fails, returning that "/opt must be an existing dir" (and it does exist on remote).

Steps To Reproduce:

name: Unarchive tgz on remote /opt
unarchive: src=files/archive.tar.gz dest=/opt

Expected Results:

Ansible happily unpacks .tgz into remote:/opt

Actual Results:

msg: dest '/opt' must be an existing dir

[abadger]

Seems to work as a normal user to a dir owned by that user. Fails if sudo has to be used.

[MrMMorris]

@abadger I just hit this and that's what I thought, but I guess not?

- name: create consul directory
  file: >
    state=directory
    path={{ item }}
    owner=consul
    group=consul
  with_items:
    - "{{ consul_home }}"
    - "{{ consul_home }}/bin"
    - "{{ consul_data_dir }}"
    - "{{ consul_config_dir }}"

- name: set ownership
  file: >
    state=directory
    path={{consul_home}}
    owner=consul
    group=consul
    recurse=yes
  when: consul_was_downloaded|changed

- name: copy and unpack
  unarchive: >
    src={{ consul_download_folder }}/{{ consul_archive }}
    dest={{ consul_home }}/bin
    copy=no
  when: consul_was_downloaded|changed

TASK: [consul | copy and unpack] **********************************************
failed: [52.0.56.9] => {"failed": true}
msg: dest '/opt/consul/bin' must be an existing dir

FATAL: all hosts have already failed -- aborting

$ ls -la /opt | grep consul
drwxr-xr-x  4 consul consul 4096 Mar 18 22:56 consul

Did Ansible devel go through a major regression or something? The set ownership task was after the unarchive task in the repo originally and it was creating all those directories as root:root. So it seems that not only does the user/group not get set with file, but unarchive also breaks even if the dest is owned by non-root

This was all working before I started using the devel branch

[MrMMorris]

or do I have to set the unarchive to sudo: false?

[bcoca]

I have a partial fix, for sudo in all cases and for su on linux ansible/ansible#10488, let me know if this fixes it for you.

[ghost]

Pulled in the latest devel this morning (73f5a1f) and it looks like this has been resolved. Thank you, gentlemen!

[MrMMorris]

Works for me as well! thanks 👍

[yeroc]

Will this be backported to the 1.9.x series or is it only going to be fixed on 2.0?

[yeroc]

Does anyone have a workaround for this on 1.9.x? I've been fighting with this and still haven't figured out why it's occurring on some machines and not others, nor have I found a workaround for the issue outside of reverting to the command module to execute tar directly... Can anyone shed more light on this?

[abessifi]

This issue is typically related to the root/top directory access permissions.

[namero999]

Still experiencing this problem.

I'm accessing the machine as normal user and then "su". Debugging the output of whoami shows "root". Other non-unarchive tasks work.

group_vars
  ansible_become: yes
  ansible_become_method: su

playbook
  unarchive:
    dest: /opt

RESULT

FAILED! => {"changed": false, "failed": true, "msg": "dest '/opt' must be an existing dir", "stat": {"exists": false}}

The dir is there and perfectly accessible. Same task executed directly as root without "become" works.

[hpio]

I'm still experiencng the bug on:
ansible --version #ansible 2.0.0.2
is there a workaround at the moment?

[bequiet88]

@p1hr
Same behavior for me. Still experiencing this bug in Ansible 2.0.0.2.

[ghost]

I hit the same problem in Debian Jessie :( Version 2.0.0.2

[thatarchguy]

Version 2.0.1.0 seeing the same problem.

[steve-todorov]

I confirm this is still an issue with ansible 2.0.1.0. Hopefully it'll get resolved :)

[bostone]

Yep, looking at it right now. Is there a workaround beside using "command"?

[kunitake]

Execute ansible-playbook command with "-K" option. It work for me...

[moriyoshi]

For 1.9.x, the fix is here: ansible/ansible#15386

[abadger]

Note: If anyone is still experiencing this bug in 2.1.x, please open a new bug. This one was closed long ago so no one has been seeing the comments here. Since a fix was applied for this, it's likely a different bug with similar symptoms is being provoked here. Getting a new bug with a reproducer will start the process of getting a fix.

Thanks!

[perigee]

The bug reappears in 2.1.1.0 :(