How to Fix Permission Denied Errors on Linux Mint (2026 Guide)

Understanding Linux File Permissions Basics

Linux Mint, like all Linux-based operating systems, uses a robust permission system to control who can read, write, or execute files and directories. When this system flags an action as unauthorized, you see the dreaded "Permission Denied" error. Understanding how permissions work is the first step to fixing them permanently.

Every file and directory in Linux has three permission groups:

• Owner (User) — the person who created or owns the file
• Group — a set of users sharing access rights
• Others — everyone else on the system

Each group has three permission types:

• r (read) — view file contents or list directory contents
• w (write) — modify a file or add/remove files in a directory
• x (execute) — run a file as a program, or enter a directory

When you run ls -l in the terminal, you see output like:

-rw-r--r-- 1 alice alice 4096 Jun 18 10:00 myfile.txt

The string -rw-r--r-- breaks down as: file type (-), owner permissions (rw-), group permissions (r--), and others permissions (r--). The user alice owns this file and belongs to the group alice.

Permission errors typically arise when:

• A file is owned by root but you are trying to access it as a regular user
• You ran a GUI application with sudo, which changed file ownership to root
• A script or installation changed permissions incorrectly
• You copied files from a different system or partition

Diagnosing Permission Denied Errors (ls, stat, whoami)

Before applying any fix, diagnose the exact problem. Blindly running commands can make things worse. Use these tools to gather the facts.

Step 1: Identify Your Current User

whoami

This outputs your username (e.g., alice). If you see root, you are already the superuser and the permission error may point to a deeper system issue like SELinux or AppArmor.

Step 2: Check File Permissions and Ownership

ls -l /path/to/file

For a directory, use:

ls -ld /path/to/directory

Look at the owner and group columns. If you see root root where your username should appear, ownership has been changed — usually from a rogue sudo command on a GUI app.

Step 3: Get Detailed File Metadata with stat

stat /path/to/file

The stat command gives you more detail including numeric permissions (e.g., 0644), owner UID, and group GID. This is especially useful when ls output is ambiguous.

Step 4: Check Groups

groups

This lists all groups your user belongs to. If a file is group-owned by video or sudo and you are not in that group, you will be denied access.

Common Error Messages Decoded

• bash: /path/to/script.sh: Permission denied — the file lacks execute permission for your user
• mkdir: cannot create directory '/opt/myapp': Permission denied — the parent directory is owned by root
• open: Permission denied — a GUI app cannot read or write a file your user does not own

Method 1: Fix with chmod (Changing Permissions)

chmod stands for change mode. It modifies the read, write, and execute bits on a file or directory. Use this when the file is already owned by you but the permission bits are wrong.

Symbolic Syntax

# Add execute permission for the owner
chmod u+x script.sh

# Give the owner read and write; group and others read-only
chmod u=rw,go=r myfile.txt

# Remove write permission from group and others
chmod go-w sensitive.conf

Numeric (Octal) Syntax

Each permission digit is a sum: read=4, write=2, execute=1.

# 755: owner=rwx, group=rx, others=rx (standard for scripts/executables)
chmod 755 myscript.sh

# 644: owner=rw, group=r, others=r (standard for regular files)
chmod 644 myfile.txt

# 700: owner=rwx, no access for group or others (private scripts)
chmod 700 private_script.sh

Recursive chmod for Directories

# Set all files in a directory to 644 and directories to 755
find /home/alice/myproject -type f -exec chmod 644 {} \;
find /home/alice/myproject -type d -exec chmod 755 {} \;

Warning: Avoid chmod 777 (full permissions for everyone) on production files — it removes all access control and is a serious security risk.

Method 2: Fix with chown (Changing Ownership)

chown stands for change owner. Use this when the file is owned by the wrong user — typically root when it should be owned by your regular account. You must use sudo to run chown.

Basic Syntax

# Change owner to alice
sudo chown alice /path/to/file

# Change owner and group simultaneously
sudo chown alice:alice /path/to/file

# Use $USER variable to reference your own username
sudo chown $USER:$USER /path/to/file

Recursive chown for Directories

# Take ownership of an entire directory tree
sudo chown -R alice:alice /path/to/directory

Practical Example: Fixing a Download Folder

If you accidentally ran a download tool with sudo and your Downloads folder is now owned by root:

# Check the current state
ls -ld ~/Downloads

# Fix it
sudo chown -R $USER:$USER ~/Downloads

# Verify the fix
ls -ld ~/Downloads

You should now see your username as both owner and group, and the Permission Denied error will be gone.

Method 3: Restore Home Directory Ownership

This is the most critical and most overlooked fix. A very common Linux Mint problem occurs when users run a graphical application with sudo — for example, sudo nautilus or sudo gedit. These GUI apps create or modify configuration files in your home directory as root, corrupting ownership for hundreds of hidden files. The result: you cannot log in properly, desktop apps crash, or settings fail to save.

Fix When You Can Still Log In

# Restore ownership of everything in your home directory
sudo chown -R $USER:$USER $HOME

This single command recursively sets your username as owner and group for every file and folder in your home directory. It is safe to run and is the standard recovery command on Linux Mint forums.

Fix When You Cannot Log Into the Desktop

If the corruption is severe and your desktop session fails to start:

1. At the login screen, press Ctrl + Alt + F2 to open a virtual terminal (TTY)
2. Log in with your username and password
3. Run the restoration command:

sudo chown -R yourusername:yourusername /home/yourusername

4. Press Ctrl + Alt + F7 (or F1) to return to the graphical login screen
5. Log in normally

Fix from Recovery Mode (Worst Case)

If you cannot log in at all:

1. Reboot and hold Shift during startup to access the GRUB menu
2. Select Advanced options for Linux Mint
3. Choose the recovery mode kernel entry
4. Select Drop to root shell prompt
5. Run:

mount -o remount,rw /
chown -R yourusername:yourusername /home/yourusername
exit

6. Reboot normally

Reset File Permission Bits After Ownership Fix

If permission bits are also corrupted, run these after restoring ownership:

# Set directories to 755
find /home/yourusername -type d -exec chmod 755 {} \;

# Set regular files to 644
find /home/yourusername -type f -exec chmod 644 {} \;

Preventing Future Permission Issues

Once your system is fixed, take these steps to avoid the same problem recurring.

Never Use sudo with GUI Applications

This is the single most important rule. Instead of:

# Wrong — corrupts home directory ownership
sudo nautilus
sudo gedit /etc/hosts

Use pkexec for graphical privilege elevation:

# Better for GUI apps
pkexec nautilus

# For editing system files, use a terminal editor
sudo nano /etc/hosts

Set Correct Permissions When Creating Files

# Check your current umask (default permission mask)
umask

# Common safe defaults
# 022 = new files get 644, new dirs get 755
# 027 = new files get 640, new dirs get 750 (more restrictive)

Use Groups Instead of Loosening Permissions

If multiple users need access to shared files, add them to a group rather than using chmod 777:

# Create a shared group
sudo groupadd sharedteam

# Add users to the group
sudo usermod -aG sharedteam alice
sudo usermod -aG sharedteam bob

# Set group ownership on shared directory
sudo chown -R :sharedteam /srv/shared
sudo chmod -R 775 /srv/shared

Audit Permissions Regularly

# Find files in your home directory owned by root
find $HOME -not -user $USER -ls

Run this periodically. If you see root-owned files in your home directory, restore ownership before they cause problems.

If you are repeatedly running into complex permission issues or system-wide errors, professional help can save you hours of troubleshooting. Get Expert Linux Mint Support from CloudHouse Technologies — our certified technicians resolve Linux Mint permission issues remotely, usually within 60 minutes.

FAQ: Common Permission Scenarios

Q1: Why do I get "Permission Denied" even when I use sudo?

Using sudo grants root privileges, but some directories and files may have ACL (Access Control List) restrictions or be mounted with noexec flags that block even root. Check mount options with cat /proc/mounts and ACLs with getfacl /path/to/file. Also verify you are typing the correct path — a typo will return the same error.

Q2: How do I fix "Permission Denied" when running a shell script?

The script is missing the execute permission. Fix it with:

chmod +x myscript.sh
./myscript.sh

If the script is on a USB drive or partition mounted with noexec, copy it to your home directory first, then run it.

Q3: I ran sudo nautilus and now my desktop is broken. How do I fix it?

This is the classic home directory ownership corruption. Open a terminal and run:

sudo chown -R $USER:$USER $HOME

Then log out and log back in. This restores ownership of all configuration files in your home directory to your regular user account.

Q4: What is the difference between chmod and chown?

chmod changes the permission bits (read, write, execute) on a file — it controls what actions are allowed. chown changes who owns the file — it controls which user and group the permission bits apply to. Most permission errors require both: first use chown to assign the correct owner, then use chmod to set the correct permission level.

Q5: Is it safe to use chmod 777 to fix permission errors?

No. chmod 777 grants full read, write, and execute access to every user on the system. While it will eliminate the "Permission Denied" error immediately, it exposes the file to any program or user — including malware — that runs on your machine. Always use the minimal permissions required: 644 for regular files, 755 for directories and executables. Only use 777 in isolated test environments, never on your home directory or system files.