How to Fix Permission Denied in Ubuntu: Causes and Solutions

What the 'Permission Denied' Error Means

The Permission denied (EACCES) error in Ubuntu occurs when a process attempts to access a file or directory, but the current user does not have sufficient permissions. The error text in the terminal typically looks like this:

bash: /path/to/file: Permission denied

Or when running a command:

ls: cannot open directory 'protected_directory': Permission denied

This error can appear when trying to read, write, delete, or execute a file, as well as when accessing network resources or devices.

Common Causes

The "Permission denied" error has specific technical causes. Here are the most frequent:

1. The file belongs to another user — you are not the file owner, and the permissions for "others" do not allow your type of access (read/write/execute).
2. The file's group does not include your group — if you are not in the owning group, and the permissions for "group" are insufficient.
3. Permissions for "others" are denied — even if you are not in the group, permissions for other users may be set to none.
4. The parent directory is inaccessible — entering a directory requires execute (x) permission on all directories in the path. If any directory denies execute permission, access to the file is blocked.
5. The filesystem is mounted with noexec, nosuid, nodev options — for example, if a partition is mounted as noexec, executing any files on it is prohibited.
6. AppArmor or SELinux restrict access — Ubuntu has AppArmor enabled by default, which can prevent an application from accessing certain files even if standard permissions allow it.
7. The file is open in exclusive mode or locked by another process (e.g., via flock).
8. Attempt to write to a file opened read-only — even if you have write permissions, if the file is opened by another process with the O_RDONLY flag, writing may be denied.
9. Using sudo for a command, but the target file requires root permissions, and the command is run without sudo — for example, apt update requires sudo, but running it without will result in permission denied.

Solutions

Method 1: Using sudo for Privileged Operations

If the error occurs when running system commands (e.g., apt, systemctl, accessing /etc), you need superuser privileges.

1. Add sudo before the command:

   sudo apt update
   

2. Enter your user password (your account must be in the sudo group). Check group membership:

   groups $USER
   

   If sudo is not in the output, add your user to the group (requires existing root privileges):

   sudo usermod -aG sudo $USER
   

3. After adding to the group, log out and back in or run newgrp sudo.

⚠️ Important: Do not use sudo for all commands. Apply it only when necessary to avoid accidental system changes.

Method 2: Changing Permissions with chmod

If you own the file but lack the required permissions, change them using chmod.

1. Check current permissions:

   ls -l /path/to/file
   

   
   Example output: -rw-r--r-- 1 user group 0 Feb 17 12:00 file Here: owner (user) has rw-, group (group) r--, others r--.
2. Add permissions for owner (u), group (g), or others (o). For example, give the owner execute permission:

   chmod u+x /path/to/file
   

   
   Or give the group write permission:

   chmod g+w /path/to/file
   

3. Use numeric mode for quick configuration:

   chmod 755 /path/to/file   # owner: rwx, group and others: r-x
   chmod 644 /path/to/file   # owner: rw-, group and others: r--
   

4. For directories, always include execute permission (x), otherwise you cannot enter them:

   chmod u+rx /path/to/directory
   

Method 3: Changing Ownership with chown

If the file belongs to another user (e.g., root) and you lack permissions to change it via chmod, change the owner.

1. Check the current owner:

   ls -ld /path/to/file
   

2. Change the owner to your current user (requires sudo):

   sudo chown $USER /path/to/file
   

   
   Here $USER is the environment variable with your username.
3. To recursively change all files in a directory:

   sudo chown -R $USER /path/to/directory
   

4. You can change the group simultaneously:

   sudo chown $USER:$USER /path/to/file   # both owner and group become $USER
   

5. If you want the group to remain unchanged while changing the owner:

   sudo chown new_user: /path/to/file
   

Method 4: Configuring Group Permissions and Adding to a Group

For shared directories (e.g., /var/www or /home/shared), group permissions are often used.

1. Set group permissions on the directory:

   sudo chgrp developers /path/to/directory   # change group to 'developers'
   sudo chmod 2775 /path/to/directory        # setgid bit: new files inherit the group
   

2. Add your user to the group:

   sudo usermod -aG developers $USER
   

3. Log out and back in or run newgrp developers to apply changes in the current session.
4. Verify the user has the correct permissions:

   groups $USER
   

Method 5: Checking and Configuring AppArmor (for Ubuntu)

AppArmor can restrict an application's access to files even if standard permissions are granted.

1. Check AppArmor status:

   sudo apparmor_status
   

   
   If the output includes "apparmor module is loaded", it is active.
2. Find profiles that might affect the problematic file:

   sudo aa-status | grep -i "application_name"
   

   
   Or review profiles in /etc/apparmor.d/.
3. Temporarily disable the profile for testing (not recommended for production):

   sudo apparmor_parser -R /etc/apparmor.d/usr.bin.your_application
   

4. For a permanent solution, edit the profile:
   • Open the profile file (e.g., /etc/apparmor.d/usr.bin.your_application).
   • Add a rule for file access, for example:

     /path/to/file rw,
     

   • Reload the profile:

     sudo systemctl reload apparmor
     

5. If AppArmor is not the cause, check SELinux (rarely enabled by default in Ubuntu):

   getenforce
   

   
   If it returns "Enforcing", review logs: sudo ausearch -m avc -ts recent.

Method 6: Checking Filesystem Mount Options

If the file is on a separate partition (e.g., /mnt/data), check how it is mounted.

1. Identify the mount point for the file:

   df -h /path/to/file
   

   
   The output shows the partition and mount point (e.g., /dev/sdb1 on /mnt/data).
2. Check mount options:

   mount | grep /mnt/data
   

   
   Example: /dev/sdb1 on /mnt/data type ext4 (rw,noexec,relatime) — here noexec prohibits execution.
3. If noexec is present, modify options in /etc/fstab:
   • Edit /etc/fstab with sudo:

     sudo nano /etc/fstab
     

   • Find the line for the partition and remove noexec (or replace with exec).
   • Example change:

     /dev/sdb1 /mnt/data ext4 defaults 0 2
     

   • Remount the partition:

     sudo mount -o remount /mnt/data
     

4. Verify after remounting:

   mount | grep /mnt/data
   

Method 7: Checking Locks and Anomalies

In rare cases, the error is caused by file locks or filesystem specifics.

1. Check if the file is locked by another process (using flock or fcntl):

   lsof /path/to/file
   

   
   If the file is open, terminate the process (carefully):

   sudo kill -9 <PID>
   

2. For network filesystems (NFS, Samba), check permissions on the server and mount options (e.g., root_squash in NFS can map root to nobody).
3. Check file attributes (e.g., immutable bit via chattr):

   lsattr /path/to/file
   

   
   If i (immutable) is present, remove the attribute:

   sudo chattr -i /path/to/file
   

4. Check available disk space: df -h. Sometimes operations fail with access errors when disk space is low.

Prevention

To avoid "Permission denied" errors in the future:

• Configure permissions when creating files — use umask to define default permissions. For directories, umask 002 yields 775; for files, 664.
• Use group permissions for shared resources — create a group, add users, set chmod 2775 on directories.
• Do not run applications as root unnecessarily — use sudo only for specific commands, not for the entire shell.
• Regularly audit permissions — check /etc, /var, and home directories for excessive permissions (e.g., chmod 777).
• Configure AppArmor/SELinux carefully — when installing new software, check for existing profiles and adjust them as needed.
• Avoid mounting with noexec on partitions where file execution is needed (e.g., /tmp or /home in some scenarios).