Linux Permission Denied: Check Identity and the Whole Path

If a file is visible in your shell but a service receives Permission denied, identify whether the failed operation is reading, writing or execution. Success under an SSH login does not establish access for PHP-FPM or a systemd service identity.

A readable script can still fail direct execution

A temporary shell script owned by an ordinary user produced PermissionError when directly executed with mode 0600. The same file returned exit code 0 with mode 0700. Content, path and identity stayed fixed; only the execute bit changed. Asking an interpreter to read a script and executing the file itself are different checks.

id
namei -l /srv/example/bin/task
stat -c '%U %G %a %n' /srv/example/bin/task
findmnt -T /srv/example/bin/task -o TARGET,OPTIONS

Replace the example path and compare the result with the service’s user and groups. Use namei to inspect every parent directory and findmnt to distinguish noexec or read-only mount conditions. A missing search permission on a parent can block access despite sufficient permissions on the final file. Linux path resolution documents this rule.

Recheck under the same identity after one correction

Correct only the ownership, group or ACL entry that is actually wrong. Applying chmod 777 or recursive chown to an entire tree can alter shared data and key files. If ordinary permissions are correct, inspect the service’s read-only path restrictions, AppArmor or SELinux denials, and the script’s interpreter path. Also compare configured identity with the running process.

Verification must use the same identity, path and operation. If a write probe is necessary, create a uniquely named temporary file in an approved test directory and remove only that file. The execute-bit experiment does not reproduce every cause of Permission denied or demonstrate a production service repair.