Linux answers Permission denied (errno EACCES) when the user running a command lacks the specific access a file or directory requires. The message is one line for several distinct problems: a script with no execute permission (the daily classic, -bash: ./script.sh: Permission denied), a file the user cannot read or write, or a directory somewhere along the path that denies traversal. Identifying which access, on which component, for which user, is the whole diagnosis; chmod by guesswork is how systems get worse.
ls -l /path/file shows owner, group, and the rwx triples for owner, group, and others. Compare against who you are (id) and what the operation needs: read to read, write to modify, execute to run a program or a script.namei -l /full/path/to/file prints the whole chain with permissions, the single most useful command for this error.noexec (common for removable media and some /tmp or home mounts) refuses execution even with correct bits; mount | grep on the mount point confirms it.chmod +x script.sh adds the execute bit (or run it through its interpreter explicitly, bash script.sh, which needs only read permission and is a handy test that the file itself is fine).sudo chown $USER file) or add group access deliberately (chmod g+r plus group membership). Prefer changing ownership of your own files over widening permissions for everyone.chmod o+x or the group equivalent as appropriate); it permits traversal without permitting listing, a distinction worth using.exec if the mount is yours to govern; copying a binary to /tmp sometimes trades one denial for this one.chmod 777 is not a fix, it is the removal of the protection that reported the problem. It leaves files world-writable afterward, and on shared systems it converts a one-line permission question into a security incident. The correct change is almost always one bit, for one class of user, on one component of the path.
Why can I read the file but not run it, when both are “access”? They are separate bits by design: read shows content, execute runs it. A script needs execute to run as ./script.sh; reading it through an interpreter (bash script.sh) needs only read, which is why that works as a test.
sudo works, is that the fix? sudo proves the file is fine and the denial is about your user's rights; it is not a durable fix for repeated tasks. Fix ownership or the specific bit, and reserve sudo for genuinely administrative files.
I created the file, why do I not own access? Creation context matters: files made by root (via sudo), by a service, or extracted from an archive keep their creator's ownership and modes. Archives in particular preserve foreign permissions faithfully; chown after extraction is normal.