🚨 Ansible Error Guide: '[Errno 2] No such file or directory' — Fix command Module Failures

Overview

The command module raises this when the executable you asked it to run cannot be found or the working directory does not exist on the target host:

fatal: [app01]: FAILED! => {"changed": false, "cmd": "kubectl get pods", "msg": "[Errno 2] No such file or directory: b'kubectl'", "rc": 2}

A chdir variant points at a missing directory rather than a missing binary:

fatal: [app01]: FAILED! => {"changed": false, "msg": "Unable to change directory before execution: [Errno 2] No such file or directory: b'/opt/app/releases/current'"}

Unlike the shell module, command runs the binary directly without a shell, so it does not search a login PATH, expand globs, or understand pipes — which is exactly why a name that “works in my terminal” fails here.

Symptoms

• A command task fails with [Errno 2] No such file or directory: b'<name>' and rc: 2.
• The same command works when you SSH in and type it manually.
• Switching the task from command to shell makes it work (a strong sign it is a PATH or shell-syntax issue).
• A chdir: path in the task does not exist on the target.
• The binary exists but lives in a directory not on the non-interactive PATH.

Common Root Causes

• Binary not on the module’s PATH — command uses a minimal environment, not your interactive login PATH, so tools in /usr/local/bin or ~/bin may not resolve.
• Binary genuinely not installed on the target host (only on the control node or your laptop).
• Shell syntax in a command task — pipes, &&, >, globs, or $VARS are passed literally to the binary, which then does not exist as named.
• Missing chdir directory — chdir: points at a path that has not been created yet.
• Relative executable path — depending on an assumed working directory.
• Wrong become context — the binary is on root’s PATH but the task runs as a user without it (or vice versa).

Diagnostic Workflow

Confirm whether the binary exists on the target and where, from Ansible’s perspective:

ansible app01 -i inventory -m shell -a "command -v kubectl; echo PATH=$PATH"

If it exists but is not resolving, use its absolute path in the task:

- name: Get pods with an absolute binary path
  ansible.builtin.command:
    cmd: /usr/local/bin/kubectl get pods -n app
    chdir: /opt/app                # must already exist
  register: pods
  changed_when: false

If the task genuinely needs shell features (pipe, redirect, glob), switch to the shell module deliberately:

- name: Count running pods (needs a pipe → use shell, not command)
  ansible.builtin.shell: /usr/local/bin/kubectl get pods | grep -c Running
  register: running
  changed_when: false

Reproduce the failure to confirm the cause:

ansible app01 -i inventory -m command -a "kubectl get pods"
# msg: [Errno 2] No such file or directory: b'kubectl'

Example Root Cause Analysis

A deploy play failed on new hosts with [Errno 2] No such file or directory: b'kubectl', even though operators could run kubectl after logging in. ansible app01 -m shell -a "command -v kubectl" showed the binary at /usr/local/bin/kubectl, but command -v under the module’s non-interactive environment did not find it, because /usr/local/bin was added to PATH only by an interactive shell profile that non-interactive Ansible sessions never sourced.

The fix was to reference the binary by absolute path in the command task (/usr/local/bin/kubectl), which removed all dependence on PATH resolution. For tasks that legitimately needed a pipe, the author switched those specific ones to the shell module rather than smuggling shell syntax into command. The recurring lesson: command runs in a minimal environment, so “it works in my terminal” says nothing about whether the binary is on the module’s PATH.

Prevention Best Practices

• Reference executables by absolute path in command tasks so resolution never depends on a non-interactive PATH.
• Use command for plain executables and shell only when you truly need pipes, redirects, globs, or shell variables — and label why.
• Ensure chdir directories are created by an earlier task before a task changes into them.
• Add a prerequisite task (or creates:) that confirms the binary is installed before invoking it.
• Match the become user to the environment where the binary is available, and verify with an ad-hoc command -v.

Quick Command Reference

# Check whether the target can find the binary, and its PATH
ansible <host> -i inv -m shell -a "command -v <bin>; echo $PATH"

# Reproduce the command-module failure
ansible <host> -i inv -m command -a "<bin> <args>"

# Run the binary by absolute path (in YAML)
# ansible.builtin.command: /full/path/to/<bin> <args>

# Confirm a chdir path exists
ansible <host> -i inv -m stat -a "path=/opt/app/current"

Conclusion

“[Errno 2] No such file or directory” from the command module means the binary (or chdir path) was not found in Ansible’s minimal, non-interactive environment — not that your command is wrong. Use absolute paths for executables, reserve shell for tasks that genuinely need shell features, and make sure directories and binaries exist before you invoke them. Once the path resolves from Ansible’s environment rather than your login shell, the task runs.