Introduction

The error Operation not permitted from chown means the kernel refused the ownership change, not merely that the path was missing or mistyped. For a file such as /var/lock/apache2.fm2cgWmnxk, the usual causes are insufficient privileges, a restricted filesystem, a container capability limitation, or a file attribute that blocks changes.

Start with the Simple Case: Are You Root?

On Linux, changing file ownership is normally a privileged operation. If you run:

chown www-data:www-data /var/lock/apache2.fm2cgWmnxk

as an unprivileged user, the kernel will usually reject it. The first check is:

whoami
sudo chown www-data:www-data /var/lock/apache2.fm2cgWmnxk

If sudo fixes the problem, there was no deeper mystery. You simply lacked permission.

Inspect the File and Filesystem

If the error happens even with sudo, inspect the file and the mount:

ls -l /var/lock/apache2.fm2cgWmnxk
stat /var/lock/apache2.fm2cgWmnxk
mount | grep ' /var '

These checks help answer:

• who owns the file now
• whether the path is on a special filesystem
• whether the mount is read-only or restricted

Remember that /var/lock is often a system-managed area. Temporary lock files there may be created and removed by services or package scripts, so changing their ownership manually is not always the right fix.

Check for Immutable Attributes

Some files cannot be modified because they have the immutable bit set. That can also block ownership changes.

lsattr /var/lock/apache2.fm2cgWmnxk

If you see an i attribute, clear it first:

sudo chattr -i /var/lock/apache2.fm2cgWmnxk
sudo chown www-data:www-data /var/lock/apache2.fm2cgWmnxk

This is less common for lock files, but it is a real cause of Operation not permitted.

Containers and Missing Capabilities

If you are inside a container, even root inside the container may not have permission to change ownership. Linux capabilities can be dropped, and CAP_CHOWN may be unavailable.

Typical symptom:

• 'whoami says root'
• 'chown still returns Operation not permitted'

In that case, the restriction is coming from the container runtime or orchestrator, not from Unix file mode bits alone.

Network or Special Filesystems

Some filesystems impose additional ownership rules:

• NFS with root_squash
• read-only mounts
• overlay or bind-mounted paths with host restrictions
• certain shared-volume configurations in containers

For example, on NFS with root_squash, root from the client is mapped to an unprivileged identity, so chown can fail even when you think you have full control.

Why the Apache Lock File Name Looks Strange

The path /var/lock/apache2.fm2cgWmnxk looks like a temporary or generated file, not a hand-maintained application asset. That matters because:

• it may be created dynamically during service startup
• a package post-install or init script may manage it
• deleting or recreating it through the proper service command may be safer than forcing ownership manually

For Apache-related files, investigate the service logic:

systemctl status apache2
journalctl -u apache2 --no-pager -n 50

If Apache itself is failing to start because of lock-file issues, fixing the service directory ownership or runtime configuration is usually better than fixing one random temporary filename.

Practical Troubleshooting Sequence

A reasonable sequence is:

1whoami
2ls -ld /var/lock /var/lock/apache2.fm2cgWmnxk
3sudo lsattr /var/lock/apache2.fm2cgWmnxk
4mount | grep ' /var '
5systemctl status apache2

This narrows the failure quickly before you make risky changes to system-owned paths.

Common Pitfalls

The biggest mistake is assuming Operation not permitted means the same thing as Permission denied. In practice, it often indicates a stronger kernel or filesystem restriction, not just missing read or write bits.

Another issue is forcing ownership changes inside /var/lock without understanding what service created the file. System-managed lock files are often symptoms of a startup or packaging issue rather than the root cause.

Finally, if you are in a container or on NFS, do not waste time staring only at Unix mode bits. Capabilities and filesystem export options can override your expectations completely.

Summary

• 'chown ... Operation not permitted means the kernel refused the ownership change.'
• First verify whether you have root privileges or need sudo.
• Check immutable attributes, mount options, and special filesystem behavior.
• In containers, missing capabilities can block chown even for root.
• For Apache lock files, investigate the service and runtime directory setup instead of treating the temporary file as the real problem.