Quick answer

What this guide helps you do

Diagnose Linux permission errors using user identity, ownership, modes, parent-directory access, groups and ACLs without falling back to chmod 777.

Start with the failed identity

Record the exact command, path and service account. Your SSH user, a systemd service and a Docker container may all use different numeric identities.

id
ps -eo user:20,group:20,pid,comm | head
systemctl show YOUR_SERVICE -p User -p Group

Inspect the full path

stat /srv/data/example
stat -c '%A %a %U(%u) %G(%g) %n' /srv/data/example
namei -l /srv/data/example
getfacl -p /srv/data/example

A user needs execute permission on every parent directory to reach a file. The final file mode alone may look correct while an earlier directory blocks traversal.

Check the filesystem state

findmnt -T /srv/data/example
df -hT /srv/data/example
mount | grep ' /srv/data '

A read-only filesystem, missing drive or unsupported ownership model is not fixed by chmod.

Choose the narrow permission model

Use ownership when one service should own the data. Use a shared group when several trusted accounts collaborate. Use ACLs for a specific additional identity. Avoid broad world-write access.

For a shared directory, the setgid bit can make new items inherit the directory’s group:

sudo chgrp media /srv/media
sudo chmod 2775 /srv/media

Test new-file ownership; existing content is not automatically corrected.

Understand recursive changes

Recursive chown or chmod can affect thousands of files and break other applications. Inspect a sample first, back up critical metadata, and scope the command to the intended subtree. Never copy a recursive command containing placeholders without replacing them.

Test as the real service user

sudo -u YOUR_SERVICE_USER test -r /srv/data/example && echo readable
sudo -u YOUR_SERVICE_USER test -w /srv/data/example && echo writable

For Docker, test using the container process identity and its in-container path. For Samba, both Linux filesystem permissions and Samba share rules must allow access.

Verification checklist

  • The failing user or service identity is known.
  • Numeric UID and GID values were checked.
  • Every parent directory is traversable.
  • The correct filesystem is mounted read-write.
  • Ownership, group or ACL change is narrowly scoped.
  • No chmod 777 workaround was used.
  • A test as the real service identity succeeds.
  • New files inherit intended access.

This is a diagnostic framework; application-specific security controls may add another boundary.

Next: Find What Is Using Disk Space on Ubuntu Server. Return to Mount a Drive Automatically with fstab.

Official reference: GNU Coreutils du.