Ansible failed to transfer file to /command
Without touching /etc/ansible/ansible.cfg
If only one host is affected, then this can be remedied on a per host basis in the hosts
file as follows:
alias ansible_host=192.168.1.102 ansible_ssh_transfer_method=scp
This solution requires ansible
version 2.3 or higher.
[Source]
do you have sftp subsystem enabled in sshd on the remote server? You can check it in /etc/sshd/sshd_config, the config file name depends on your distribution…anyway, look there for:
Subsystem sftp /usr/lib/ssh/sftp-server
If this line is commented-out, the sftp is disabled. To fix it, you can either enable sftp, or change Ansible configuration. I prefer the Ansible configuration change, take a look at ansible.cfg and add/change:
[ssh_connection]
scp_if_ssh=True
In CentOS8 I had to replace this line in /etc/ssh/sshd_config
Subsystem sftp /usr/libexec/openssh/sftp-server
with
Subsystem sftp internal-sftp
Then restart sshd service with this command:
systemctl restart sshd
I recently received a message like this for an entirely different reason. I had some stray text that was the result of a cd -
command that I had in my ~/.bashrc
file. I fixed this issue by filtering its output like this:
my ~/.bashrc
...
cd ~/ansible/hacking/ > /dev/null 2>&1 && . env-setup -q && cd - > /dev/null 2>&1
...
Without those redirects of the cd commands to /dev/null
I was getting this message.
TASK [setup] *******************************************************************
ok: [app02]
ok: [app03]
fatal: [app01]: FAILED! => {"failed": true, "msg": "failed to transfer file to /home/admin/.ansible/tmp/ansible-tmp-1474747432.93-129438354708729/setup:\n\n/home/admin\n"}
my ansible.cfg
The other interesting details from my situation are that I'm already using this in my ansible.cfg
file:
[ssh_connection]
scp_if_ssh=True
And the server in the list with the issue, app01, is the same server where I'm running the Ansible playbook from.
The bit of text at the end of my error message:
74747432.93-129438354708729/setup:\n\n/home/admin\n"}
is what clued me into my issue. That's the output from cd ...
when it runs during login when my ~/.bashrc
file is being processed.