Access denied: how to fix permission errors

Summary

This guide helps you fix “permission denied” and “access denied” errors in two common cases: SSH login (e.g. “Permission denied (publickey)”) and file or directory access on Linux or macOS. You will learn how to read the error, run minimal checks, and apply safe fixes (correct permissions and ownership) without using chmod 777 or weakening security. Use it when you have the exact error message and can run commands on the client or server as appropriate.

Prerequisites

• The exact error message (copy it or a screenshot) and the action that triggered it (e.g. ssh user@host, opening a file, running a script).
• Access to a terminal on the machine where the error occurs; for SSH issues, access to the server (e.g. console or another account) to fix authorized_keys and permissions.
• Basic familiarity with running shell commands. Commands assume Linux or macOS; on Windows use WSL or a similar environment for the same tools.

Steps

Step 1: Read the error and identify the context

Errors often look like:

• SSH: Permission denied (publickey). or Permission denied (publickey,password).
• File: Permission denied when running a command, or Access denied / EACCES in an app.

Write down: (1) The exact message. (2) The command or action (e.g. ssh deploy@prod, ./script.sh, opening /var/app/config). (3) Which user you are and which user or path is involved. Reproduce the failure with one minimal command so you can retest after changes (e.g. ssh user@host or cat /path/to/file).

Step 2: Fix SSH “Permission denied (publickey)”

This means the server rejected all offered keys (or you did not offer one). Fix on both client and server.

On the server (log in via console, password, or another key):

1. Confirm the public key is in the right place:

   cat ~/.ssh/authorized_keys

   The line for your key must be one full line, no line breaks. Append it if missing: echo "PUBLIC_KEY_LINE" >> ~/.ssh/authorized_keys.

2. Set permissions (wrong permissions cause SSH to reject the key):

   chmod 700 ~/.ssh
   chmod 600 ~/.ssh/authorized_keys

3. Ensure you are the user you SSH as; authorized_keys is read from that user’s home directory.

On the client:

1. Offer the key explicitly and see what the server does:

   ssh -v -i ~/.ssh/id_ed25519 user@hostname

   Look for “Offering public key” and “Authentication succeeded” or the rejection reason.

2. If the key has a passphrase, load it into the agent so SSH can use it:

   eval "$(ssh-agent -s)"
   ssh-add ~/.ssh/id_ed25519

3. If you have multiple keys, the server may be getting the wrong one; use -i or configure IdentityFile in ~/.ssh/config for that host.

Step 3: Fix file or directory permission denied

Identify the file or directory and who needs access.

1. Inspect owner and permissions:

   ls -la /path/to/file_or_dir

   Columns: permissions (e.g. rwxr-xr-x), owner, group. If a directory is not executable (x) for your user, you cannot cd into it or use paths through it.

2. Apply the least privilege that fixes the problem:

   • Your own file: You own it but cannot read/write: chmod 600 file (read/write for you only) or chmod 644 file (read for others) if that is required.
   • Directory you need to enter or read from: chmod 755 dir (owner rwx, others rx) is common for shared dirs; chmod 700 dir if only you should access it.
   • Script must run: chmod 700 script or chmod 755 script (755 if others must execute it).
   • Wrong owner: If you have sudo: chown user:group file so the right user owns it, then set permissions with chmod as above.

3. Do not use chmod 777. It gives everyone read, write, and execute and weakens security. Use a specific user/group and minimal permissions (e.g. 755 for dirs, 644 or 600 for files).

Step 4: Verify with a minimal test

Re-run the same action that failed:

• SSH: ssh user@hostname (or with -i if you use a specific key). You should get a shell without “Permission denied”.
• File: Run the command that read or wrote the file (e.g. cat /path/to/file or the app that opens it). It should succeed.

If it still fails, re-check the exact path, user, and error; repeat the relevant step (SSH or file permissions) and test again.

Verification

• SSH: Login with ssh user@hostname (and -i if needed) completes without “Permission denied (publickey)”.
• File: The command or app that previously failed can now read or write the file (or traverse the directory) without “Permission denied” or “Access denied”.
• No 777: You did not use chmod 777; permissions are 755, 700, 644, 600, or similar as appropriate.

Troubleshooting

SSH still “Permission denied” after fixing authorized_keys
Confirm you are editing the right account’s authorized_keys (the one you log in as with ssh user@host). Check server logs: journalctl -u sshd -n 50 or tail -50 /var/log/auth.log (paths vary by OS) to see why the key was rejected (e.g. “Authentication refused”). Ensure the key line has no extra spaces or line breaks.

“Bad permissions” or “WARNING: UNPROTECTED PRIVATE KEY FILE”
Your local private key has overly open permissions. Run chmod 600 ~/.ssh/id_ed25519 and chmod 700 ~/.ssh. SSH will not use the key until this is fixed.

File permission change had no effect
You may have changed the wrong path (symlink, different mount, or typo). Run ls -la again on the exact path you use. If the process runs as another user (e.g. a service), that user needs access; adjust owner/group or group permissions (e.g. 640 with the process in the file’s group).

Operation not permitted even as root
Some files or directories are immutable (e.g. chattr +i) or on a read-only filesystem. Run lsattr /path (Linux) to see attributes; remove immutability only if you understand the impact. For read-only mounts, remount read-write only if safe for the system.

Next steps

• Manage passwords and reset flows safely: How to manage passwords safely (manager, reset flows).
• Before going live: Accounts and access checklist before going live.
• If someone leaves: How to revoke access when someone leaves.