How to fix exec: "#!/bin/bash\r": executable file not found in $PATH in Docker

DockerBEGINNERMEDIUMUpdated Dec 6, 2025· 196 views

This error occurs when a shell script has Windows-style line endings (CRLF), causing Docker to interpret the shebang line literally as '#!/bin/bash\r' instead of '#!/bin/bash'. Converting the script to Unix line endings (LF) fixes the issue.

Quick fix

Fixes exec: "#!/bin/bash\r": executable file not found in $PATH

file entrypoint.sh
  1. Verify the file has Windows line endings
  2. Convert line endings using dos2unix
  3. Convert line endings using sed or tr
  4. Fix line endings in your text editor
docker — error
file entrypoint.sh
exec: "#!/bin/bash\r": executable file not found in $PATH

What this error means

When Docker tries to execute a shell script as an entrypoint or command, it reads the shebang line (e.g., `#!/bin/bash`) to determine which interpreter to use. If the script was created or edited on Windows, it likely contains CRLF line endings (`\r\n`) instead of Unix-style LF endings (`\n`). The carriage return character (`\r`) becomes part of the interpreter path, so Docker looks for an executable literally named `/bin/bash\r` (with the carriage return embedded in the name). Since no such file exists, Docker reports it cannot find the executable in `$PATH`. This is one of the most common cross-platform Docker issues, especially when Windows developers collaborate with Linux/Mac developers, or when CI/CD pipelines clone repositories on different operating systems.

Typical symptoms

  • Error message shows the shebang line followed by \r in quotes
  • Container fails immediately at startup with 'executable file not found in $PATH'
  • The script file clearly exists in the container when inspected
  • Error only occurs on some machines or CI environments, not others
  • Scripts work when run directly but fail as Docker entrypoints
  • Problem appeared after editing scripts on Windows or cloning on a Windows machine
  • Git shows no changes to the file, but Docker suddenly cannot run it

Common causes

  1. Shell script was created or edited on Windows with CRLF line endings
  2. Git auto-converted line endings when cloning on Windows (core.autocrlf=true)
  3. Text editor saved the file with Windows line endings by default
  4. Script was transferred via FTP or copy-paste, converting line endings
  5. IDE configured to use Windows line endings for all files
  6. File was edited in Windows Notepad which adds CRLF endings

How to fix "exec: "#!/bin/bash\r": executable file not found in $PATH"

1Verify the file has Windows line endings

Before making changes, confirm that CRLF line endings are the issue. Check your script file:

bash
file entrypoint.sh

If it shows "CRLF line terminators" or "with CRLF", that confirms the problem. You can also inspect the raw bytes:

bash
cat -A entrypoint.sh | head -5

If you see ^M at the end of lines (representing \r), those are the problematic carriage returns.

2Convert line endings using dos2unix

The simplest fix is to convert the file to Unix line endings using dos2unix:

bash
dos2unix entrypoint.sh

If dos2unix is not installed:

bash
# Ubuntu/Debian
sudo apt-get install dos2unix

# macOS (with Homebrew)
brew install dos2unix

# Alpine Linux
apk add dos2unix

# RHEL/CentOS/Fedora
sudo dnf install dos2unix
3Convert line endings using sed or tr

If you cannot install dos2unix, use built-in tools to remove carriage returns:

Using sed:

bash
sed -i 's/\r$//' entrypoint.sh

On macOS, the syntax is slightly different:

bash
sed -i '' 's/\r$//' entrypoint.sh

Using tr:

bash
tr -d '\r' < entrypoint.sh > entrypoint.sh.tmp && mv entrypoint.sh.tmp entrypoint.sh
4Fix line endings in your text editor

Most modern editors allow you to change line endings directly:

VS Code:
1. Open the file
2. Look at the bottom-right status bar where it says "CRLF"
3. Click on it and select "LF"
4. Save the file

Notepad++:
1. Open the file
2. Go to Edit > EOL Conversion > Unix (LF)
3. Save the file

JetBrains IDEs (IntelliJ, PyCharm, WebStorm):
1. Open the file
2. Go to File > Line Separators > LF - Unix and macOS
3. Save the file

Sublime Text:
1. Open the file
2. Go to View > Line Endings > Unix
3. Save the file

5Fix line endings in the Dockerfile

If you cannot control the source files, fix them during the Docker build process:

dockerfile
# Using sed (no additional packages needed)
COPY entrypoint.sh /app/entrypoint.sh
RUN sed -i 's/\r$//' /app/entrypoint.sh && chmod +x /app/entrypoint.sh

# Using dos2unix (Debian/Ubuntu)
RUN apt-get update && apt-get install -y --no-install-recommends dos2unix \
    && dos2unix /app/entrypoint.sh \
    && apt-get purge -y dos2unix && apt-get autoremove -y && rm -rf /var/lib/apt/lists/*

# Using dos2unix (Alpine)
RUN apk add --no-cache dos2unix \
    && dos2unix /app/entrypoint.sh \
    && apk del dos2unix
6Configure Git to preserve line endings

Prevent this issue from recurring by telling Git to keep LF endings for shell scripts. Create or update .gitattributes in your repository root:

gitattributes
# Force LF line endings for shell scripts and Docker files
*.sh text eol=lf
*.bash text eol=lf
Dockerfile text eol=lf
docker-entrypoint* text eol=lf
entrypoint* text eol=lf
*.yml text eol=lf
*.yaml text eol=lf

After adding .gitattributes, refresh existing files:

bash
git rm --cached -r .
git reset --hard

Alternatively, configure Git globally to convert CRLF to LF on commit:

bash
git config --global core.autocrlf input
7Rebuild the Docker image

After fixing the line endings in your source files, rebuild the Docker image to pick up the changes:

bash
docker build --no-cache -t your-image:tag .

The --no-cache flag ensures Docker rebuilds all layers and copies the corrected files. Without this flag, Docker might use cached layers containing the old files with CRLF endings.

Advanced notes

Why the error message looks strange: Docker is showing you exactly what it is looking for. The \r in the error message exec: "#!/bin/bash\r": executable file not found represents the literal carriage return character. The system is searching for a file named /bin/bash followed by a carriage return byte, which obviously does not exist.

Here-documents as a workaround: For simple scripts, you can avoid file-based line ending issues entirely by using Dockerfile here-documents (BuildKit feature):

dockerfile
# syntax=docker/dockerfile:1
COPY <<EOF /app/entrypoint.sh
#!/bin/bash
set -e
exec "$@"
EOF
RUN chmod +x /app/entrypoint.sh

CI/CD considerations: If your CI/CD system runs on Windows or clones with Git for Windows, configure the checkout step to preserve line endings:

yaml
# GitHub Actions
- uses: actions/checkout@v4
  with:
    # Prevents CRLF conversion
    autocrlf: false

Editor configuration with EditorConfig: Add an .editorconfig file to enforce LF endings across all team members' editors:

ini
[*.{sh,bash}]
end_of_line = lf
insert_final_newline = true

Frequently asked questions

What does "exec: "#!/bin/bash\r": executable file not found in $PATH" mean?
/bin/bash) to determine which interpreter to use. If the script was created or edited on Windows, it likely contains CRLF line endings (\r\n) instead of Unix-style LF endings (\n). The carriage return character (\r) becomes part of the interpreter path, so Docker looks for an executable literally named /bin/bash\r (with the carriage return embedded in the name).
How do I fix "exec: "#!/bin/bash\r": executable file not found in $PATH"?
This error occurs when a shell script has Windows-style line endings (CRLF), causing Docker to interpret the shebang line literally as '#!/bin/bash\r' instead of '#!/bin/bash'. Converting the script to Unix line endings (LF) fixes the issue.
What causes "exec: "#!/bin/bash\r": executable file not found in $PATH"?
Shell script was created or edited on Windows with CRLF line endings Git auto-converted line endings when cloning on Windows (core.autocrlf=true) Text editor saved the file with Windows line endings by default
Is the "exec: "#!/bin/bash\r": executable file not found in $PATH" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading