Fixing the Permission Denied Error in Debian: Step-by-Step Guide

What the EACCES (Permission denied) Error Means

The Permission denied error (system code EACCES) indicates that the Linux kernel has blocked your attempt to perform an operation on a file, directory, or device. The full message in the terminal typically looks like this: bash: ./setup.sh: Permission denied, cp: cannot create regular file '/etc/app.conf': Permission denied, or ls: cannot open directory '/root': Permission denied.

This message appears immediately after you enter a command, run a script, or try to open a file in a graphical interface. The system checks the inode permission metadata before every disk access request. If your account is not on the list of authorized users or groups, the operation is instantly aborted. This is a fundamental Debian security mechanism designed to prevent accidental or malicious data modification.

Common Causes

• Missing execute permission (x) on downloaded scripts, binaries, or Python files.
• Attempting to write to system directories (/etc, /var/log, /usr/local, /sys), which are read-only for regular users by default.
• The file is owned by root or another user, while you are operating under a standard user account.
• The partition is mounted with the noexec flag (commonly found on external USB drives, in /tmp, or enforced via fstab security policies).
• Conflicts with mandatory access control (MAC) policies (SELinux, AppArmor), which restrict access at the process context level, even if standard rwx permissions are correctly set.

How to Fix It

Method 1: Granting Execute Permissions to a Script

If the terminal throws an error when trying to run a .sh, .py, or compiled file, you need to explicitly grant the system permission to execute it.

1. Open a terminal and navigate to the directory containing the file:

   cd ~/загрузки
   

2. Check the current metadata:

   ls -l скрипт.sh
   

   You will see something like -rw-r--r--. The x flag is missing.
3. Add execute permission:

   chmod +x скрипт.sh
   

4. Run the file using a relative path:

   ./скрипт.sh
   

💡 Tip: If the file has incorrect line endings (CRLF instead of LF), Bash may still refuse to run it with a similar error. Convert the file using dos2unix скрипт.sh before running chmod.

Method 2: Changing Resource Ownership

This error frequently occurs when working with projects extracted from an archive or created as root via sudo cp. Revert ownership back to your account.

sudo chown -R $USER:$USER /путь/к/рабочей/папке

The command recursively (-R) changes both the owner and group to your current account. The $USER variable automatically substitutes the current username, so you don't need to type it manually. Afterward, any programs launched under your profile will have full access to the contents.

Method 3: Temporarily Elevating Privileges with sudo

Sometimes, accessing a file genuinely requires administrator privileges (e.g., editing network service configurations or log files). Use sudo only for the specific command, rather than spawning an entire root shell.

sudo nano /etc/nginx/nginx.conf

If you need to copy a file to a protected directory, specify the full path or use sudo tee to avoid output redirection issues:

echo "новое_значение=1" | sudo tee -a /etc/sysctl.conf

Method 4: Checking Partition Mount Flags

External drives or special directories may be mounted with the noexec restriction, which prevents executing any programs regardless of chmod settings.

1. Check the current partition's mount options:

   mount | grep /media/ваш_диск
   

   If noexec appears in the output, file execution will be blocked.
2. Remount the partition with the exec flag (requires root privileges):

   sudo mount -o remount,exec /media/ваш_диск
   

3. For a permanent fix, edit /etc/fstab, replace noexec with exec in the line corresponding to the target UUID, and run sudo mount -a.

⚠️ Important: Enabling the exec flag on removable media reduces security. Do not run files from untrusted sources, and use this method only for trusted devices.

Prevention Best Practices

• Keep user projects, scripts, and downloads strictly within your home directory (~/), where Debian automatically assigns you as the owner.
• Add your account to specialized groups instead of relying on constant sudo. For example, to access Docker, run sudo usermod -aG docker $USER, and for printer management, use sudo usermod -aG lpadmin $USER.
• Review external drive mount settings in /etc/fstab. Specify uid=1000,gid=1000,exec for drives used in development.
• Regularly scan working directories for files with suspicious permissions: find ~ -type f -perm -o+w will list objects writable by all users, which should be immediately restricted using chmod go-w.