Fix: sudo: command not found on Linux

The Error

You run a command with sudo on a Linux system and get:

bash: sudo: command not found

Or:

sudo: command not found

Or in a shell script:

./setup.sh: line 5: sudo: command not found

The system cannot find the sudo binary. This is different from a permissions error like Permission denied or sudo: user is not in the sudoers file — those mean sudo was found but access was denied.

Why This Happens

sudo is not installed on every Linux system by default. Common situations where it is missing:

• Minimal Docker containers (Alpine, Debian slim, Ubuntu minimal) do not include sudo — it is not needed since the container runs as root.
• Freshly provisioned Debian/Ubuntu servers from some cloud providers or VPS hosts ship without sudo.
• Alpine Linux uses doas instead of sudo in many configurations.
• Shell scripts run with su — when you switch to root with su, the PATH may not include /usr/bin where sudo lives.
• Non-interactive SSH sessions — the PATH set up by .bashrc or .bash_profile may not apply.
• Docker RUN commands — each RUN is executed as a new shell with a minimal environment.

Fix 1: Install sudo

If sudo is simply not installed, install it as root:

Debian / Ubuntu:

# Switch to root first
su -

# Install sudo
apt-get update && apt-get install -y sudo

# Add your user to the sudo group
usermod -aG sudo your-username

# Exit root shell
exit

# Apply the group change (log out and back in, or use newgrp)
newgrp sudo

CentOS / RHEL / Fedora:

su -
dnf install -y sudo        # RHEL 8+ / Fedora
# or
yum install -y sudo        # RHEL 7

usermod -aG wheel your-username
exit

On RHEL/CentOS, the wheel group has sudo access by default (not the sudo group).

Alpine Linux:

# As root
apk add --no-cache sudo

# Add user to wheel group
adduser your-username wheel

# Allow wheel group to use sudo without password (optional)
echo "%wheel ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers

After installing and adding your user to the appropriate group, log out and log back in for the group change to take effect. Group membership is read at login — newgrp sudo applies it to the current session without re-logging.

Fix 2: Fix sudo in Docker Containers

Docker containers often run as root, so sudo is unnecessary and not installed. But if your Dockerfile or scripts use sudo, add it:

Dockerfile — Debian/Ubuntu base:

FROM ubuntu:22.04

RUN apt-get update && apt-get install -y \
    sudo \
    && rm -rf /var/lib/apt/lists/*

# Create a non-root user with sudo access
RUN useradd -m -s /bin/bash appuser \
    && echo "appuser ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers

USER appuser

Better approach — run as root during build, switch to non-root for runtime:

FROM node:20-slim

# Run build steps as root (no sudo needed)
RUN apt-get update && apt-get install -y curl \
    && rm -rf /var/lib/apt/lists/*

# Switch to non-root user for the application
RUN useradd -m -u 1001 appuser
USER appuser

WORKDIR /app
COPY --chown=appuser:appuser . .
RUN npm install
CMD ["node", "server.js"]

Pro Tip: In Docker, you do not need sudo in RUN commands — they run as root by default (before any USER instruction). Add sudo only if your application code or scripts explicitly call it at runtime as a non-root user.

Fix 3: Fix sudo in Shell Scripts

When a script is run via su, cron, or a non-login shell, the PATH may not include /usr/bin:

Check where sudo is installed:

which sudo
# /usr/bin/sudo  (most systems)

ls -la /usr/bin/sudo

Use the full path in scripts:

#!/bin/bash
/usr/bin/sudo apt-get update
/usr/bin/sudo systemctl restart nginx

Or fix the PATH at the top of the script:

#!/bin/bash
export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

sudo apt-get update

For cron jobs, always use full paths or set PATH explicitly because cron runs with a minimal environment:

# In crontab (crontab -e):
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0 2 * * * /usr/bin/sudo /usr/bin/apt-get update -y

Fix 4: Use su Instead of sudo on Systems Without sudo

On minimal systems or older distributions where sudo is not installed and you cannot install it, use su to switch to root:

# Switch to root
su -

# Run your commands as root
apt-get update
systemctl restart nginx

# Return to your user
exit

The su - (with the dash) starts a login shell as root, which sets up the correct PATH and environment. su without the dash inherits your current environment, which may have PATH issues.

Run a single command as root with su -c:

su -c "apt-get update && apt-get install -y curl" root

This is equivalent to sudo apt-get update && sudo apt-get install -y curl.

Fix 5: Fix sudo Not Found in SSH Commands

When running commands over SSH non-interactively, the PATH is often minimal:

Broken — PATH does not include /usr/bin:

ssh user@server "sudo systemctl restart nginx"
# bash: sudo: command not found

Fixed — use the full path:

ssh user@server "/usr/bin/sudo /bin/systemctl restart nginx"

Fixed — force a login shell:

ssh user@server "bash -l -c 'sudo systemctl restart nginx'"

The -l flag starts a login shell which sources .bash_profile and sets up the full PATH.

Fixed — use sudo -i or sudo -s in the remote command:

If the user has passwordless sudo configured, you can also use:

ssh user@server "sudo -n systemctl restart nginx"

The -n flag makes sudo non-interactive — it fails immediately if a password would be required instead of hanging.

Fix 6: Fix sudo in CI/CD Pipelines

In GitHub Actions, GitLab CI, and similar platforms, runners often run as root or a restricted user:

GitHub Actions — check the runner user:

- name: Check user
  run: whoami && id

Most GitHub Actions runners run as a non-root user with sudo available and passwordless. If sudo is not found, install it in your workflow:

- name: Install sudo
  run: |
    if ! command -v sudo &> /dev/null; then
      apt-get update && apt-get install -y sudo
    fi

For Docker-based CI runners, add sudo to your base image as shown in Fix 2.

GitLab CI — use before_script to install dependencies:

before_script:
  - apt-get update -qq && apt-get install -y -qq sudo

Fix 7: Verify sudo Is Configured Correctly After Install

After installing sudo, verify it works:

# Check that sudo binary exists
which sudo

# Check your group membership
groups
id

# Test sudo with a safe command
sudo echo "sudo works"

# If prompted for password and you want passwordless sudo:
sudo visudo

In visudo, add this line at the end to allow your user passwordless sudo:

your-username ALL=(ALL) NOPASSWD: ALL

Or for the entire sudo group:

%sudo ALL=(ALL) NOPASSWD: ALL

Warning: Passwordless sudo is convenient but reduces security. Use it only for automated scripts, CI environments, or development machines — not production servers with sensitive data.

Still Not Working?

Check if sudo is installed but not in PATH:

find / -name "sudo" -type f 2>/dev/null

If it finds /usr/bin/sudo but which sudo returns nothing, your PATH is missing /usr/bin. Add it:

export PATH="$PATH:/usr/bin"

Add this to ~/.bashrc or ~/.bash_profile to make it permanent.

Check the sudoers file for syntax errors:

sudo visudo -c  # Check syntax without opening the editor

A syntax error in /etc/sudoers can break sudo for all users. If you cannot use sudo at all, boot into single-user mode or use pkexec visudo to fix the sudoers file.

WSL (Windows Subsystem for Linux): If you are on WSL and sudo is not found, your WSL distribution may be in a broken state. Try resetting it or reinstalling the distribution from the Microsoft Store.

For permission errors after sudo is working (e.g., sudo: user is not in the sudoers file), the fix is adding the user to the sudo/wheel group as shown in Fix 1. For script permission errors, see Fix: bash: Permission Denied.