Linux file permissions: ownership, modes, groups and ACLs explained

Identify the process user and group

A web server, application, cron job, deployment agent, and interactive shell may run as different users. Check the actual service identity before changing ownership.

For a directory path, execute permission on every parent controls traversal even when the final file itself appears readable.

Distinguish ownership from mode bits

chown changes owner/group; chmod changes permission bits. ACLs, setgid directories, umask, and security modules can add rules beyond the basic rwx display. Use namei/getfacl-style tools when the simple mode does not explain the result.

Do not solve a write error by making an application tree world-writable.

Design shared-write paths deliberately

Uploads, cache, logs, sockets, deployments, and shared team directories may need write access, while application code should often stay read-only to the runtime. Separate those paths so the permission model reflects actual jobs.

For deployment workflows, use group ownership or ACLs so the web server and administrator do not need to keep taking ownership from each other.

Test from the service context

Run a safe read/write check as the service user or through the real application path. Confirm new files inherit the intended group and mode after the fix, not only the file you manually edited.

• Find the real service identity.
• Check every parent directory.
• Keep code and writable state separate.
• Verify inheritance for new files.