Struggling with ‘command not found’ errors when using sudo? We break down why your PATH disappears and provide three real-world solutions, from the quick-and-dirty hack to the architecturally sound permanent fix.

Why Your Command Works for You, But Not for ‘sudo’

I remember it like it was yesterday. It was 2 AM, the on-call pager was screaming, and a critical deployment to `prod-web-03` was failing. A junior engineer, bless his heart, had written a deployment script. It ran perfectly when he tested it manually, but the moment our Jenkins runner executed it with `sudo`, it fell apart with a classic my-custom-tool: command not found. That sinking feeling of a simple problem causing a major outage is something every ops person knows. The culprit wasn’t the script; it was a fundamental, and very common, misunderstanding of the wall between a user’s world and the world of `sudo`.

The “Why”: Your Environment Isn’t Their Environment

Here’s the thing we often forget: when you run a command with sudo, you are not simply running that one command as the root user in your own cozy, customized shell environment. For critical security reasons, `sudo` is configured by default to create a new, sanitized, and minimal environment for the command it’s about to run.

This means a few things:

• Your custom aliases? Gone.
• Environment variables you set in .bashrc or .zshrc? Vanished.
• And most importantly, your user’s $PATH variable is replaced by a default, secure path defined in the /etc/sudoers file.

If the tool you’re trying to run (like docker-compose, a custom script in /usr/local/bin, or a Node.js binary) isn’t in that restrictive, default path, the system won’t find it. End of story.

Solution 1: The Quick Fix (The Absolute Path Sledgehammer)

It’s 2 AM, the site is down, and you don’t have time for a lecture on security policy. You just need it to work. The fastest, most direct way to solve this is to stop relying on the $PATH and tell `sudo` exactly where the command is.

First, find the full path to your command using the which command:

which my-custom-tool
/usr/local/bin/my-custom-tool

Now, use that full, absolute path in your script or command. It’s ugly, but it’s explicit and it will work.

# Instead of this...
sudo my-custom-tool --deploy

# Do this...
sudo /usr/local/bin/my-custom-tool --deploy

Is it a good long-term solution? Absolutely not. It’s brittle. If the tool moves, your script breaks. But as a battlefield fix to get a service back online, it’s a valid tool in your arsenal.

Solution 2: The “Proper” Fix (Taming the sudoers File)

If this is a recurring problem on a server you manage, the right way to fix it is to tell `sudo` that your path is trustworthy. You do this by editing the `sudoers` file. This is the configuration file that governs all of `sudo`’s behavior.

Warning: Be extremely careful when editing this file. A syntax error can lock you out of `sudo` entirely. ALWAYS use the visudo command to edit it, as it performs a syntax check before saving.

Run sudo visudo and look for a line that looks something like this:

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

This is the restrictive path `sudo` is using. To fix your issue, you can simply append the directory where your custom tools live (e.g., /usr/local/bin) to this line.

# The Updated Line
Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin

Save the file, and now any `sudo` command will be able to find executables in /usr/local/bin without you needing to specify the full path. This is a much cleaner, more maintainable solution for your infrastructure.

Solution 3: The Architect’s Fix (Principle of Least Privilege)

Let’s take a step back. Why does a user or a script need broad `sudo` access in the first place? In a well-architected system, they shouldn’t. The most secure and scalable solution is to grant a specific user permission to run only the specific command they need, and nothing more.

This approach is perfect for automation and CI/CD runners.

Step 1: Create a dedicated service user, for example, `jenkins-runner`.

Step 2: Use visudo to give that user passwordless permission to run only the deployment script.

# In /etc/sudoers, add this line at the bottom
jenkins-runner ALL=(ALL) NOPASSWD: /usr/local/bin/my-custom-tool

Now, your CI/CD pipeline can execute the command as the `jenkins-runner` user, and it’s the only privileged command that user can run. They can’t run sudo rm -rf / or poke around where they shouldn’t. You’re using the full path (like in Solution 1), but within a secure framework that follows the Principle of Least Privilege.

Which Solution is Right for You?

Here’s a quick breakdown to help you decide.

My advice? Use #1 to put out the fire. Use #2 for your general development and management servers where you trust your users. And use #3 for any and all automation. Understanding the “why” behind the `sudo` environment wall is what separates a junior from a senior engineer. Now go fix that pipeline.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions