Check Linux file permissions: diagnose Permission denied without chmod 777

Permission denied does not automatically mean that permissions should be opened to everyone. First check the user, file and directory path. This guide covers traditional Unix permissions on GNU/Linux; additional access controls can apply independently.

Step by step

  1. Record the full affected path and intended operation: reading, writing, executing or creating a file in a directory. Replace /path/file in the examples with your actual path.
  2. Read id to identify the user and groups of your current session. For a service, its execution account matters, not your interactive login. Identify that account from the service configuration.
  3. Inspect ls -ld /path/file and ls -ld /path. The output shows type, mode, owner and group. Inspect the other parent directories too. A symbolic link is not its target file; check the actual target separately.
  4. Identify the applicable permission class: owner, otherwise a matching group, otherwise others. For directories, x permits traversal and r listing; creating or removing entries normally needs w and x on the directory. The sticky bit and other rules can impose further restrictions.
  5. If traditional permissions fit, investigate ACLs, SELinux/AppArmor, a read-only mount or a container namespace. A plus sign in the mode output can indicate additional access methods. Do not disable protection globally.
  6. Only after identifying a specific missing permission, record the previous mode and change exactly one file. For example, chmod u+r /path/file adds only owner read access. This helps only when that is the missing access; avoid recursive changes and blanket 777.

Check the result

Repeat the original operation using the same affected account and inspect the mode again. Success as root does not prove access for the service user. If the error remains, investigate the next supported finding instead of granting more permissions.

Undo and limitations

The diagnostic commands are read-only. Restore the recorded previous state after a permission change; account separately for ACLs and special bits. Blanket chmod 644 is not a universal rollback, especially for directories or executables.

Source