Linux File Permission Management: Analyzing the Root Causes and Solutions for 'Operation not permitted' Errors in chmod

Problem Phenomenon and Technical Background

In Linux system administration practice, users frequently encounter failures when attempting to modify file permissions. A typical scenario is: after user rehamadel creates a shell script using sudo vi my_script.sh, attempting to execute chmod u+x my_script.sh returns the error message chmod: changing permissions of 'my_script.sh': Operation not permitted. This phenomenon directly reflects the core mechanism of Linux's permission model.

Ownership and Permission Correlation Mechanism

The Linux file system employs an ownership-based permission control model. Each file is associated with three key attributes: owner, group, and others. When a user creates a file using the sudo command, the file's ownership belongs to the root user, not the regular user who executed the command. This state can be clearly viewed using the ls -l command:

-rw-r--r--. 1 root root 52 Jul 30 19:25 my_script.sh

The output shows the file owner as root, with permissions set to 644 (owner can read and write, others can only read). At this point, regular user rehamadel only qualifies as "others" and does not have the authority to modify file permissions.

Core Solution Analysis

To address the mismatch between ownership and permissions, two fundamental solutions exist:

Solution 1: Privilege Elevation Execution

The most direct solution is to use the sudo command to elevate privileges for chmod execution:

sudo chmod u+x my_script.sh

This command adds execute permission for the file owner (root) using root privileges. However, note that only the root user can execute the script at this point. If all users should be able to execute it, use:

sudo chmod a+x my_script.sh

Or more precisely set permissions to 755:

sudo chmod 755 my_script.sh

Solution 2: Ownership Transfer

A solution more aligned with regular workflow is to change file ownership, granting the regular user full control:

sudo chown rehamadel:rehamadel my_script.sh

After executing this command, file ownership transfers to user rehamadel and their eponymous user group. Subsequently, this user can directly use chmod u+x my_script.sh to modify permissions without relying on sudo each time.

Best Practices and Preventive Measures

To avoid frequent permission issues, it is recommended to follow these principles:

1. Principle of Least Privilege: Use sudo to create files only when necessary. For user-owned scripts, create them directly under user permissions.
2. Ownership Management: Use the chown command to reasonably allocate file ownership, ensuring users have appropriate control over required files.
3. Permission Planning: Clarify permission requirements during the early stages of script development to avoid frequent adjustments later. For shared scripts, setting permissions to 755 is recommended; private scripts can be set to 700.

In-depth Technical Principle Analysis

The Linux permission system is implemented based on the inode data structure. Each file's inode contains UID (User ID), GID (Group ID), and permission bit information. When a process attempts to modify file permissions, the kernel first checks whether the process's effective user ID matches the file's UID, or whether the process has the CAP_FOWNER capability (typically obtained via sudo). Regular user processes have a UID of 1000 (assuming), while the file's UID is 0 (root), causing the permission check to fail and the system to return an EPERM error.

The permission modification operation itself does not alter file content, only updating the permission bits in the inode. This design ensures the lightweight nature of permission management. Understanding this underlying mechanism helps system administrators more effectively diagnose and resolve various permission-related issues.