Ansible Legacy Setup Failed To Execute | Fast Fix Steps

Guide / By

Ansible legacy setup failed to execute usually means the remote host can’t run the setup module, so fact gathering fails before your tasks start.

You run a playbook, it stalls on “Gathering Facts,” and the next line says the legacy setup step failed to execute. Your playbook never mentions “legacy.” It’s just Ansible saying a module didn’t run on the target.

Ansible works by copying a small module to the target, then executing it through an interpreter on that host. If the module can’t be written to a temp folder, can’t be executed, or can’t be run with the interpreter Ansible picked, you’ll see this failure.

The fix is rarely mysterious. It’s usually Python missing, a bad interpreter path, a permissions mismatch under sudo, a temp directory that blocks execution, or an SSH transfer that drops at the wrong moment.

What This Error Means In Plain English

At the start of a play, Ansible gathers facts unless you disable it. That’s done by the setup module. When that module can’t run, Ansible stops early because it can’t trust the state of the host.

Think of it like this: before doing any work, Ansible tries to ask the host a few basic questions. If the host can’t answer because the question runner won’t execute, you don’t get past the doorway.

  • Interpreter problem — Python isn’t installed, or the path Ansible tries doesn’t exist.
  • Temp path problem — The remote temp folder is not writable, or it blocks execution with mount options.
  • Privilege problem — Ansible connects as one user, then sudo changes ownership or permissions in a way that breaks module runs.
  • Transport problem — SSH drops, multiplexing misbehaves, or a jump host interrupts the module transfer.

You can prove which bucket you’re in with one host and four commands. Once you know the bucket, the fix is usually a small config change.

Ansible Legacy Setup Failed To Execute Error On Remote Hosts

This section is your fastest path to the cause. Run these against one failing host from your control node. Use -vvvv for the run that fails, then scan for the temp path and the interpreter path Ansible attempted.

Run A Small Preflight Playbook

If you manage mixed images, a tiny preflight playbook saves time. It gives you one standard check that fails fast and tells you if the host can run modules before you start bigger roles.

---
- hosts: all
  gather_facts: false
  tasks:
    - name: Ping
      ansible.builtin.ping:
    - name: Show identity
      ansible.builtin.command: id
    - name: Minimal facts
      ansible.builtin.setup:
        gather_subset: min

Run this against new hosts with --limit first. When it passes, your real playbooks have a clean starting point.

  1. Confirm you’re hitting the right host — Run ansible -i inventory.ini host1 --list-hosts and check the output.
  2. Check basic reachability — Run ansible -i inventory.ini host1 -m ping to verify SSH auth and a usable shell.
  3. Reproduce the failure directly — Run ansible -i inventory.ini host1 -m setup -a 'gather_subset=min' -vvvv.
  4. Confirm it’s the setup stage — Set gather_facts: false for one run. If tasks run, the setup stage is your trigger.

Use this table to match what you see to what to try next. It’s meant for quick log decisions.

What You See In -vvvv Likely Cause First Fix To Try
“/usr/bin/python: not found” Python missing or wrong path Install python3 or set ansible_python_interpreter
Temp path shows “permission denied” Remote temp not writable Fix user/become or set remote_tmp
Temp path shows “operation not permitted” Temp filesystem blocks execution Move remote_tmp to a path that allows exec
SSH transfer resets or hangs Connection or multiplexing issue Test manual SSH, then disable ControlPersist

If you’re still unsure, look for the two most helpful lines in the log: the remote temp path Ansible chose, and the interpreter line that shows what it tried to run. Those two lines usually tell you where to go next.

Fix Python And Interpreter Problems

The most common root cause is simple: the target host can’t run the interpreter Ansible selected. That shows up as “python not found,” “bad interpreter,” or a module crash that points to Python.

When you hit this, you have two jobs: make sure Python exists on the target, and then tell Ansible which interpreter to use so it stops guessing.

Set ansible_python_interpreter Explicitly

If the host already has python3, set the interpreter per host or group. This is the cleanest fix for mixed fleets where some systems still have python2 paths and others don’t.

  • Set it per host — In inventory, add host1 ansible_python_interpreter=/usr/bin/python3.
  • Set it per group — In group vars, set ansible_python_interpreter: /usr/bin/python3 for that distro family.
  • Validate the change — Run ansible host1 -m setup -a 'gather_subset=min' and confirm it returns facts.

Bootstrap Python On Bare Images

If Python isn’t installed, most modules can’t run. Use the raw module for a one-time bootstrap, because raw runs through the remote shell and doesn’t require Python first.

  1. Debian or Ubuntu — Run ansible host1 -m raw -a 'sudo apt-get update -y && sudo apt-get install -y python3'.
  2. RHEL or CentOS — Run ansible host1 -m raw -a 'sudo yum install -y python3' (use dnf on newer hosts).
  3. Alpine — Run ansible host1 -m raw -a 'sudo apk add --no-cache python3'.
  4. Re-run setup — Run ansible host1 -m setup -a 'gather_subset=min' after install.

If sudo isn’t allowed, install Python through your image build or a one-time manual step. After that, keep the interpreter pinned in inventory so you don’t see the same ansible legacy setup failed to execute message on the next rebuild.

To confirm the host really has a usable Python, run one plain command and compare it to your interpreter setting. You’re checking two things: the executable exists, and it can run a short script without crashing.

  • Check python3 location and version — Run ansible host1 -m command -a 'command -v python3 && python3 -V'.
  • Check basic imports — Run ansible host1 -m command -a 'python3 -c "import json,ssl; print(1)"'.
  • Keep the path consistent — Once it works, keep the same ansible_python_interpreter value for that host group.

Fix Sudo, Permissions, And Remote Temp Issues

When Ansible runs a module, it writes files to a remote temp folder, then executes them. If that folder is blocked by permissions or mount rules, the module can’t run even if SSH is fine.

Start by confirming which user Ansible connects as, then confirm what happens under privilege escalation. Many failures come from connecting as one user and running parts of the play as another user.

  1. Check the connected user — Run ansible host1 -m command -a 'id' and confirm the uid and groups.
  2. Check become behavior — Run ansible host1 -b -m command -a 'id' and confirm it becomes root when expected.
  3. Check /tmp mode — Run ansible host1 -m command -a 'ls -ld /tmp' and look for the sticky bit (often 1777).

Move remote_tmp To A Safer Path

If /tmp is locked down, point Ansible to a temp path you control. Set remote_tmp in ansible.cfg so it’s consistent across runs and hosts.

  • Use /var/tmp for longer runs — Set remote_tmp = /var/tmp/ansible and create that folder with safe permissions.
  • Use a per-user folder — Set remote_tmp = /tmp/.ansible-${USER}/tmp if your policy allows execution there.
  • Retest the setup module — Run ansible host1 -m setup -a 'gather_subset=min' -vvvv and confirm the temp path changed.

Spot Execution Blocks Like noexec

Some systems allow writing to /tmp but block running files from it. That’s often a noexec mount option. The log may read like a permission issue even when file ownership looks fine.

  • Inspect mount options — Run ansible host1 -m command -a 'mount | grep -E " /tmp | /var/tmp "'.
  • Pick a different temp filesystem — Point remote_tmp to a path on a filesystem that allows execution.
  • Keep cleanup predictable — Use one dedicated temp folder so you can prune it safely.

Fix SSH Transport And Authentication Quirks

Sometimes the module never finishes transferring to the target host. A dropped SSH session, a misconfigured jump host, or multiplexing issues can leave a partial module file behind. The end result still looks like an execution failure.

Start by confirming that manual SSH from the control node works cleanly. Then test one Ansible run with multiplexing disabled to see if it’s a connection reuse issue.

  1. Test manual SSH — Run ssh -vvv user@host1 and confirm it connects without resets.
  2. Disable multiplexing for a test — Run ANSIBLE_SSH_ARGS='-o ControlMaster=no' ansible host1 -m setup -a 'gather_subset=min' -vvvv.
  3. Limit to one host — Use --limit host1 so parallel runs don’t mask the real error.

Match Inventory Settings To Your SSH Setup

If your SSH works only with a non-default port, a specific identity file, or a proxy jump, make that explicit in inventory. Small mismatches can allow a connection that’s “good enough” for a ping and then fails mid-module.

  • Set ansible_host and ansible_port — Use these when DNS and port don’t match defaults.
  • Set ansible_user and IdentityFile — Add ansible_ssh_common_args='-o IdentityFile=~/.ssh/id_rsa' when you need a specific identity file.
  • Keep jump rules consistent — Put ProxyJump in SSH config or inventory so every tool uses the same route.

Keep It Fixed With A Small Guardrail Checklist

Once the error is gone, lock in the assumptions that made it go away. That’s how you stop this from returning after image rebuilds, new hosts, or a new distro that lands in the same inventory group.

A good guardrail is simple. It keeps remote execution predictable when hosts change or get rebuilt.

  1. Pin the interpreter per distro — Set ansible_python_interpreter for each distro group so guessing doesn’t happen.
  2. Set a known remote_tmp — Choose one temp path that works across your hosts and keep it in ansible.cfg.
  3. Keep a bootstrap play — For bare hosts, run a first play that installs python3, then run your real roles.
  4. Add a preflight check — Run ping, id, and minimal setup on new hosts before running bigger playbooks.
  5. Save the failing log lines — When a host fails, keep the interpreter and temp path lines from -vvvv so the next fix is faster.

Run A Tiny Preflight Playbook

A preflight play checks connection, privilege, temp execution, and Python before roles. Run it on new hosts first.

---
- hosts: all
  gather_facts: true
  tasks:
    - name: Ping
      ansible.builtin.ping:
    - name: Show Python
      ansible.builtin.command: python3 -V
      changed_when: false

If the play fails during fact gathering, you’re still in the setup bucket. If it passes, your tasks are the next place to look.

After you change one thing, rerun ansible host1 -m setup -a 'gather_subset=min'. If you still see ansible legacy setup failed to execute, re-check the interpreter and remote_tmp lines. When it passes, run the full playbook.