Linux file permissions
Read, write, and execute rights apply differently to files and directories.
The idea
Traditional Linux permissions specify rights for the owner, group, and others. On a file, read allows reading content, write allows modifying it, and execute allows execution when appropriate. On a directory, read lists names, execute permits traversal, and write generally permits modifying directory entries. Ownership, access-control lists, special bits, and filesystem state can also affect access. Inspect the context before applying a recursive permission change.
In practice
A private configuration file might use owner-only read and write permissions. A directory needs traversal rights for someone to access files inside it, even if those files are readable.
A common misunderstanding
Making everything world-writable is not a troubleshooting solution. It introduces access risks and hides the original issue.
Check your understanding
Why might a readable file still be inaccessible?
Think it through: A parent directory may lack the required traversal permission, or another control may restrict access.
Evaluate the operation, not just the file's label
A fictional web service needs to read a configuration file but must not modify it. The service account's access depends on the file, its ownership, and the directories leading to it. A readable file inside a directory the account cannot traverse may remain inaccessible. Diagnose the complete path rather than making the file world-readable in frustration.
Directory permissions have different effects from ordinary file permissions. Listing names, traversing a directory, and changing directory entries are distinct operations. Deleting a file generally involves authority over its containing directory, with additional rules such as the sticky bit potentially affecting the result. Reading the file's own write bit alone does not answer every question.
Traditional mode bits are not the entire access model. ACLs, capabilities, mount options, and mandatory access controls may also matter in a particular environment. Record the account and operation being tested so the conclusion remains specific.
Build a small access table
Using a local training directory, define an owner, a group member, and an unrelated test identity conceptually. State who should read a dummy document, modify it, list its directory, and create another file there. Compare those intended outcomes with the configured permissions through approved test accounts.
Avoid recursive permission changes on system or shared directories as a learning shortcut. Such changes can expose secrets or break service assumptions far beyond the original problem. A useful repair grants only the required operation to the intended identity and verifies both legitimate access and expected denial. Understanding permissions is about explaining effective authority, not merely converting between symbolic letters and octal numbers.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
GNU Coreutils manualLinux man-pages: Inodes and file metadata