Task "Unzip downloaded file" crashes trying to change ownership to unexisting user/group

[AlexandreGohier]

The "Unzip downloaded file" crashes as it tries to set the ownership of files and directories back to their original values. The original user and group do not exist and thus the task crashes.

- name: Unzip downloaded file
  unarchive:
    src: "{{etcd_download_dir}}/etcd-v{{etcd_version}}-linux-amd64.tar.gz"
    dest: "{{etcd_download_dir}}/"
    remote_src: yes
    creates: "{{etcd_download_dir}}/etcd-v{{etcd_version}}-linux-amd64/etcd"
  tags:
    - etcd

A second playbook run "fixes" the problem as the task is then skipped and other tasks can go on (there is no real ownership problem).

So maybe the owner and group could be set by the task or the error ignored? What is the best option here in your opinion?

I should mention I ran into this problem on a btrfs filesystem, maybe the behaviour is different on ext4.

[githubixx]

Thanks for reporting! #7 should fix it. While it wasn't a problem until now it I guess it really makes sense to fix the ownership of the files after they're un-archived.

[AlexandreGohier]

That is really weird, it still crashes as if the owner and group settings have no effect:

Anyway, running it twice works for now. I guess I could ignore the error with something like:

ignore_errors: yes

but that might prevent other legitimate errors from being detected...

[githubixx]

That's really strange. I tested it on one of my nodes and it changes the ownership as expected. Maybe indeed a issue with tar and btrfs... But I also still use Ubuntu 16.04 ATM. Maybe a issue in Ubuntu 18.04? Maybe it will hit me also when I upgrade to 18.04.

[githubixx]

I guess adding ignore_errors: yes is a option here because if the unarchive fails one of the next steps will fail and it should report a proper error message if a file is missing. So it will only fail one or a few steps further.

[AlexandreGohier]

I tested on both 16.04 and 18.04, same behaviour... It must be related to btrfs.

• This article relates a similar problem on CIFS.
• This issue is specific to Ansible and is supposed to have been solved in this pull but I don't understand how exactly...

Next time I rebuild my stack I will try with ignore_errors: yes.

[AlexandreGohier]

Tried again with ignore_errors: yesand it resulted as expected so this could be a working fix even if it is not very elegant...