No such file or directory (errno ENOENT) usually means what it says, the path does not exist. But it has three famous disguises where the file is visibly right there: a script whose first line names an interpreter the system cannot find (often because the file has Windows line endings), an executable built for a different architecture whose dynamic loader is absent, and any path resolved relative to a working directory other than the one you assume. Checking which of the four situations you are in is faster than checking the filename ten times.
ls -l /the/full/path and pwd. A relative path that works in one terminal fails in a service, cron job, or script running from a different directory; absolute paths remove the ambiguity.file ./program reports what it actually is (script text, ELF 64-bit, ELF 32-bit). The answer chooses the branch below../script.sh gives “No such file or directory” when the shebang line (#!/bin/bash) is polluted by a carriage return from Windows line endings: the kernel looks for an interpreter literally named /bin/bash
. head -1 script.sh | od -c | head exposes the
. Fix by converting the file (dos2unix script.sh, or the editor's line-ending setting) and saving scripts as LF on any platform./lib/ld-linux.so.2), not the binary. file shows the architecture; the remedy is the correct build of the program, or installing the matching loader and libraries for the 32-bit case on distributions that support multiarch.ls -l on the final file can succeed through one route while a symlink in the chain points at a target that was moved; readlink -f /path resolves the whole chain and shows where it breaks.Documents and documents are different directories, and names copied from a Windows context often differ in exactly this way.Why does it say the file is missing when ls shows it? Because the missing thing is something the file needs: its interpreter (scripts) or its dynamic loader (binaries), or a component of the path. The kernel reports all of these as ENOENT. The file command distinguishes them in seconds.
Cron says it every night but my manual run works, why? Cron runs with a minimal environment and a different working directory. Relative paths and PATH-dependent commands are the usual casualties; use absolute paths in scheduled scripts.
How do I see the carriage return problem? cat -A script.sh shows line ends as $ with a visible ^M for carriage returns, or od -c shows directly. Any editor's line-ending indicator (CRLF vs LF) shows it too.