Fix Linux application permissions without chmod 777

A Linux permission error can concern the file, a parent directory, a service sandbox or a security policy. Making everything writable hides the cause and can expose credentials. These checks apply to Debian and Ubuntu with ordinary Unix permissions. Use an administrative shell for inspecting other accounts; save changes for a maintenance window if the application is busy.

Identify the operation and account

Record the exact error, timestamp and affected path. Is the application trying to read configuration, create a cache file or execute a program? Those operations require different access. A file owned by your SSH account is not automatically readable by the web service.

systemctl show example.service -p User -p Group -p DynamicUser
systemctl status example.service --no-pager
ps -eo user,group,pid,comm

Replace the unit name with the actual application. An empty system-level User setting usually means root, but inspect the real process as well: applications may change their own identity. Containers introduce an additional user-ID mapping, so compare numeric IDs inside and outside before changing ownership.

Walk the complete path

namei -l /srv/example/config/settings.conf
stat /srv/example/config/settings.conf
findmnt -T /srv/example/config/settings.conf

Directory execute permission permits traversal. File read permission alone cannot bypass an inaccessible parent. The namei output makes each component visible and also reveals symlinks. A read-only filesystem cannot accept writes even when the mode appears permissive.

If access-control lists are in use, inspect them with getfacl when installed. An ACL mask can limit an otherwise promising entry. Check the service unit for restrictions such as ProtectSystem, ReadWritePaths or PrivateTmp. AppArmor or SELinux denials require policy-aware diagnosis, not a broader file mode.

Test the narrow requirement

For a stable, existing service account, use sudo -u example test -r /srv/example/config/settings.conf to test readability. A zero exit status means the shell test succeeded for that account; it does not reproduce every service sandbox. Check write access only on the intended writable directory. Do not create test files inside a database or overwrite an application-owned file.

Record the current owner, group, mode and any ACL before editing. Grant only the access the operation needs. A common design keeps program files readable but not writable by the service, while allowing writes in a dedicated data directory. Avoid recursive ownership changes across a release, mounted volume or shared directory without examining every affected path.

Verify and undo

Repeat the failing application action once, then review fresh logs. If a restart is required to pick up group membership or unit changes, schedule it and test access afterward. Restore the recorded settings if the change does not solve the specific error. Do not leave both an experimental permission grant and an unexplained denial.

Investigate systemd services. Connect using SSH.

Reference: Official documentation. Check the documentation installed on your own operating-system release when an option differs.