2

Using this Ansible task against my Ubuntu 18.04 VM, the task fails and shows a message like

"Authentication or permission failure. In some cases, you may have been able to authenticate and did not have permissions on the target directory. Consider changing the remote tmp path in ansible.cfg to a path rooted in \"/tmp\". Failed command was: ( umask 77 && mkdir -p \"echo /home/alan-sysop/.ansible/tmp/ansible-tmp-1529057459.23-56386111798122\" && [...]

Why?

The same task works successfully for a Debian 9 VM. In the past, I successfully used Ansible to control a Ubuntu 16.04 VM.

EDIT: If I run Ansible with triple verbosity (option -vvv), there is a lot more output, and I can find a more specific error message:

mkdir: cannot create directory \xe2\x80\x98/home/alan-sysop/.ansible\xe2\x80\x99: Permission denied.

Ansible command and output (with -v for verbose level 1)

$ ansible-playbook -b -K -v playbooks/all-bootstrap.yml -l ubuntu1804-vm -t copy-test
Using /home/alan-sysop/ansible/ansible.cfg as config file
SUDO password: 

PLAY [all] *********************************************************************

TASK [ansible-target : Basic test of copy module] ******************************
fatal: [ubuntu1804-vm]: UNREACHABLE! => {"changed": false, "msg": "Authentication or permission failure. In some cases, you may have been able to authenticate and did not have permissions on the target directory. Consider changing the remote tmp path in ansible.cfg to a path rooted in \"/tmp\". Failed command was: ( umask 77 && mkdir -p \"` echo /home/alan-sysop/.ansible/tmp/ansible-tmp-1529057459.23-56386111798122 `\" && echo ansible-tmp-1529057459.23-56386111798122=\"` echo /home/alan-sysop/.ansible/tmp/ansible-tmp-1529057459.23-56386111798122 `\" ), exited with result 1", "unreachable": true}

PLAY RECAP *********************************************************************
ubuntu1804-vm              : ok=0    changed=0    unreachable=1    failed=0

Ansible command and output (with -vvv for verbose level 3)

$ ansible-playbook -b -K -vvv playbooks/all-bootstrap.yml -l ubuntu1804-vm -t copy-test
ansible-playbook 2.5.2
  config file = /home/alan-sysop/ansible/ansible.cfg
  configured module search path = [u'/home/alan-sysop/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/bin/ansible-playbook
  python version = 2.7.15 (default, May 16 2018, 17:50:09) [GCC 8.1.1 20180502 (Red Hat 8.1.1-1)]
Using /home/alan-sysop/ansible/ansible.cfg as config file
SUDO password: 
Parsed /home/alan-sysop/ansible/inventory inventory source with ini plugin
statically imported: /home/alan-sysop/ansible/roles/ansible-target/tasks/main-tasks.yml
statically imported: /home/alan-sysop/ansible/roles/ansible-target/tasks/raw.yml
statically imported: /home/alan-sysop/ansible/roles/ansible-target/tasks/nonraw.yml

PLAYBOOK: all-bootstrap.yml **************************************************************************************************************************
1 plays in playbooks/all-bootstrap.yml

PLAY [all] *******************************************************************************************************************************************
META: ran handlers

TASK [ansible-target : Basic test of copy module] ****************************************************************************************************
task path: /home/alan-sysop/ansible/roles/ansible-target/tasks/nonraw.yml:78
<ubuntu1804-vm.local> ESTABLISH SSH CONNECTION FOR USER: None
<ubuntu1804-vm.local> SSH: EXEC ssh -C -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o ConnectTimeout=10 -o ControlPath=/home/alan-sysop/.ansible/cp/2b9a0eeef8 ubuntu1804-vm.local '/bin/sh -c '"'"'echo ~ && sleep 0'"'"''
<ubuntu1804-vm.local> (0, '/home/alan-sysop\n', '')
<ubuntu1804-vm.local> ESTABLISH SSH CONNECTION FOR USER: None
<ubuntu1804-vm.local> SSH: EXEC ssh -C -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o ConnectTimeout=10 -o ControlPath=/home/alan-sysop/.ansible/cp/2b9a0eeef8 ubuntu1804-vm.local '/bin/sh -c '"'"'( umask 77 && mkdir -p "` echo /home/alan-sysop/.ansible/tmp/ansible-tmp-1529058132.74-222830721646724 `" && echo ansible-tmp-1529058132.74-222830721646724="` echo /home/alan-sysop/.ansible/tmp/ansible-tmp-1529058132.74-222830721646724 `" ) && sleep 0'"'"''
<ubuntu1804-vm.local> (1, '', 'mkdir: cannot create directory \xe2\x80\x98/home/alan-sysop/.ansible\xe2\x80\x99: Permission denied\n')
fatal: [ubuntu1804-vm]: UNREACHABLE! => {
    "changed": false, 
    "msg": "Authentication or permission failure. In some cases, you may have been able to authenticate and did not have permissions on the target directory. Consider changing the remote tmp path in ansible.cfg to a path rooted in \"/tmp\". Failed command was: ( umask 77 && mkdir -p \"` echo /home/alan-sysop/.ansible/tmp/ansible-tmp-1529058132.74-222830721646724 `\" && echo ansible-tmp-1529058132.74-222830721646724=\"` echo /home/alan-sysop/.ansible/tmp/ansible-tmp-1529058132.74-222830721646724 `\" ), exited with result 1", 
    "unreachable": true
}

PLAY RECAP *******************************************************************************************************************************************
ubuntu1804-vm              : ok=0    changed=0    unreachable=1    failed=0

For comparison, the task succeeds for a Debian 9 VM

$ ansible-playbook -b -K -v playbooks/all-bootstrap.yml -l debian9-vm -t copy-test
Using /home/alan-sysop/ansible/ansible.cfg as config file
SUDO password: 

PLAY [all] *********************************************************************

TASK [ansible-target : Basic test of copy module] ******************************
changed: [debian9-vm] => {"changed": true, "checksum": "27b41e0724c1aa99931b9e753b639563e3996257", "dest": "/ansible-managed/ansible-target/test-file.txt", "gid": 0, "group": "root", "md5sum": "145fab51c12c1f30714dd15c536f0a7a", "mode": "0644", "owner": "root", "size": 56, "src": "/home/alan-sysop/.ansible/tmp/ansible-tmp-1529057600.23-245931452134186/source", "state": "file", "uid": 0}

PLAY RECAP *********************************************************************
debian9-vm                 : ok=1    changed=1    unreachable=0    failed=0

(And the task is idempotent as expected. If I run it again, it says the system is in the desired state already; no changes were necessary.)

$ ansible-playbook -b -K -v playbooks/all-bootstrap.yml -l debian9-vm -t copy-test
Using /home/alan-sysop/ansible/ansible.cfg as config file
SUDO password: 

PLAY [all] *********************************************************************

TASK [ansible-target : Basic test of copy module] ******************************
ok: [debian9-vm] => {"changed": false, "checksum": "27b41e0724c1aa99931b9e753b639563e3996257", "dest": "/ansible-managed/ansible-target/test-file.txt", "gid": 0, "group": "root", "mode": "0644", "owner": "root", "path": "/ansible-managed/ansible-target/test-file.txt", "size": 56, "state": "file", "uid": 0}

PLAY RECAP *********************************************************************
debian9-vm                 : ok=1    changed=0    unreachable=0    failed=0

Ansible task

The playbook file all-bootstrap.yml looks like this:

- name: Basic test of copy module
  copy:
    src: test-file.txt
    dest: /ansible-managed/ansible-target/
  tags: "copy-test"

test-file.txt contains a single line:

This file is used as a test of the Ansible copy module.

Ansible version

$ ansible-playbook --version
ansible-playbook 2.5.2
  config file = /home/alan-sysop/ansible/ansible.cfg
  configured module search path = [u'/home/alan-sysop/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/bin/ansible-playbook
  python version = 2.7.15 (default, May 16 2018, 17:50:09) [GCC 8.1.1 20180502 (Red Hat 8.1.1-1)]

as installed from the repos of Fedora Workstation 28.

Improve this question

2 Answers 2

Reset to default
2

It says 'mkdir: cannot create directory \xe2\x80\x98/home/alan-sysop/.ansible\xe2\x80\x99: Permission denied'.

The failing command appears to happen before Ansible uses sudo.[1] Ansible cannot write to /home/alan-sysop/.ansible for permission reasons:

alan-sysop@ubuntu1804-vm:~$ ls -ld /home/alan-sysop/.ansible
drwx------ 3 root root 4096 Jun 14 20:33 /home/alan-sysop/.ansible

As far as I can tell, the bad permissions were caused when I ran an Ansible command locally on the VM: sudo ansible-playbook -c local --limit ubuntu1804-vm .... I can avoid setting these bad permissions if I use ansible-playbook -b -K -c local --limit ubuntu1804-vm ... instead.

Evidence

[1] The Ansible verbose level 3 output shows how it runs the failing command. It looks like it does not use sudo anywhere.

<ubuntu1804-vm.local> SSH: EXEC ssh -C -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o ConnectTimeout=10 -o ControlPath=/home/alan-sysop/.ansible/cp/2b9a0eeef8; '/bin/sh -c '"'"'( umask 77 && mkdir -p "` echo /home/alan-sysop/.ansible/tmp/ansible-tmp-1529058132.74-222830721646724 `" && echo ansible-tmp-1529058132.74-222830721646724="` echo /home/alan-sysop/.ansible/tmp/ansible-tmp-1529058132.74-222830721646724`" ) && sleep 0'"'"''`

<ubuntu1804-vm.local> (1, '', 'mkdir: cannot create directory \xe2\x80\x98/home/alan-sysop/.ansible\xe2\x80\x99: Permission denied\n')

Improve this answer
0

Linux sometimes remounts automatically file systems as read-only due to some disk failure or corruption. It happened in my case, and then due to the impossibility of writing to the destination, that same message was displayed. The command "mount -oremount, rw file system" should correct this, or a reboot, in some cases, and if possible. 'Again, this is what happened in my case'. See if this could have happened to you too.

Improve this answer
4
  • surely a read-only filesystem would generate a different error than "Permission denied"?
    – Jeff Schaller ♦
    Jan 20, 2020 at 20:52
  • @JeffSchaller TBF, that's pretty deep lore. I suspect the first error message matched, the "Authentication or permission failure ..." one.
    – sourcejedi
    Jan 20, 2020 at 21:31
  • I suggest editing this answer to note that Linux (sometimes) automatically remounts a filesystem read-only because of a disk error, or unexpected filesystem corruption. Check your logs etc. Don't assume everything will be OK again after remounting RW - the disk might be dying :-).
    – sourcejedi
    Jan 20, 2020 at 22:03
  • Hi, thanks for the suggestion. Yes, 'in my case', that's exactly what happened, but working with RHEL. The error message was the same. The message was due to a lack of permission because he was unable to write to the destination, due to the 'read-only', not necessarily due to a lack of permission. And I didn't assume that everything would be ok, so the mention of 'in my case'. Sorry, I ended up assuming that this would be understood as a possibility for the problem / resolution.
    – Paulo Luizetto
    Jan 21, 2020 at 21:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .