Ubuntu File Permissions: Fix Permission Denied

When an Ubuntu command cannot open or run a file, the denied access may involve the file or a directory in its path. Linux file permissions determine who can use a file and traverse its parent directories.

I’ll show how to identify the user and permission check behind the error, then choose a narrow permission or ownership change.

TL;DR: Check the path before changing permissions

For a permission-denied error, identify the current user, inspect the file’s owner and mode, then check search permission on every parent directory before changing one specific permission.

What do Linux file permissions control?

Linux permissions assign access rights to the file owner, its group, and other users. A long listing displays mode bits in three adjacent groups. A dash means that particular right is absent.

On a file, read opens contents, write changes them, and execute runs it as a program. For a directory, execute permits traversal by name.

In -rw-r—–, the owner can read and write, the group can read, and others have no access. In drwxr-x—, d marks a directory whose owner can list and search it.

The system checks the owner first, then group membership, then other. I inspect ownership before choosing a permission class because the error alone does not show which class applies.

For the symbolic and numeric forms of chmod, see the Linux chmod command guide. To change ownership, use the separate Linux chown command guide.

How to diagnose and fix permission denied in Ubuntu

Use the same account and exact path as the failed operation. The sequence starts with identity, then checks the target and its parent path before changing anything.

Use a file you are authorized to inspect. Avoid changing an entire system directory.

Step 1: Confirm which user is running the command

Check the identity that made the request. An interactive terminal and background service can run under different accounts, so inspect the service configuration when only the job fails.

id

I ran id. It reported uid=1001(ubuntu) and included group 27(sudo). This output describes this shell, not yours.

If a scheduled job fails while your shell succeeds, inspect the job’s configured account.

Step 2: Inspect the file owner and mode

Use a long listing on the exact target. Include the full path when you are unsure which file the command resolved. Relative paths depend on the current working directory, so two commands with the same filename can refer to different files.

ls -l -- /path/to/file

Read the permission characters, owner, and group. Check membership with id before applying the group bits.

A script can be readable but lack execute permission. If you own it and intend direct execution, chmod u+x script.sh adds the owner bit. Verify the path first.

Step 3: Check every parent directory

Inspect each path component.

namei -l /path/to/file

Look for any directory where the relevant user class lacks x.

Do not add read access to a directory just to enable path traversal. If the directory belongs to another user or is a system location, ask its administrator to grant the minimum needed access or use the intended interface.

Step 4: Apply the smallest permission change

Apply a change only after the listing identifies a missing bit and the target belongs to you or you have authorization.

chmod u+r -- file.txt
chmod g+x -- directory

The first command adds owner read access. The second grants group search access. Use the one that matches the intended access, then inspect the target.

Symbolic modes use u, g, and o for owner, group, and others. Plus adds a permission, minus removes it, and equals replaces the selected class.

Numeric modes replace the full mode, using 4 for read, 2 for write, and 1 for execute. For example, chmod 640 data gives the owner read/write, the group read, and others no access.

Avoid chmod 777 because it grants everyone read, write, and execute.

For deletion errors, inspect the parent directory. Its write and search permissions govern removing a name. A sticky directory limits who can remove entries.

Step 5: Correct ownership only when it is wrong

Only use chown when the file owner or group is wrong and you are authorized to correct it.

sudo chown "$USER":"$(id -gn)" -- file.txt

An ownership change can disrupt services when the file is system-managed. Review how sudo privileges are managed before making an administrative change.

Use sudo only when the intended operation requires administrator rights and your account is authorized. Running an application or editor as root can create root-owned files in your home directory, causing a later denial for your normal account.

What if chmod does not fix the error?

When basic permission bits appear correct, check for another access rule or a filesystem restriction.

An access control list (ACL) can add rules for a named user or group. Read-only mounts, network storage, and application sandboxes can also enforce their own access rules. Identify which policy applies before changing permissions.

GNU documents how chmod handles symbolic links in its chmod manual. Confirm the target path before changing a mode.

For a lock-file error, identify the application and check whether it is already running. A lock can prevent two processes from changing the same data at once. Do not remove it just to silence the message because that may leave the application state inconsistent.

Repeat the original operation as the same user. If access still fails, check the filesystem or application policy rather than resetting permissions recursively.

Conclusion: Change only the permission that is missing

Use the narrowest change that restores the intended access.

For command details, see the LinuxForDevices guides to chmod and chown, and the GNU chmod documentation.

FAQ

These answers cover common Ubuntu permission checks that need a short reminder.