A “Permission denied” error does not automatically mean that chmod should be made more permissive. Begin by identifying the account running the command and examining every directory in the target path.
1. Identify the effective user and groups
The result of a test can differ depending on whether it runs under your account, root, a service account, or a scheduled task. Check the identity and current group membership first.
whoami id getent group devops
2. Inspect the path and ownership
Use ls and namei to inspect the file and parent-directory permissions. Users need execute permission on each directory in the path to traverse it, even when the final file itself is readable.
ls -ld /srv /srv/proyek namei -l /srv/proyek/tes.txt stat /srv/proyek
3. Prefer group-based access for shared folders
For a shared project directory, a dedicated group is often easier to maintain than repeatedly granting access to individual users. The setgid bit can make newly created items inherit the directory group; verify the result using the accounts intended to use the directory.
sudo chown root:devops /srv/proyek sudo chmod 2770 /srv/proyek ls -ld /srv/proyek
4. Test with the intended account
Confirm both the allowed and denied cases. Do not default to chmod 777: broad permissions can expose files or allow unintended changes.
sudo -u budi touch /srv/proyek/permission-test.txt sudo -u tamu ls /srv/proyek