Squid shm_open Permission Denied: Check Shared-Memory Ownership

Could not read pid file and shm_open(...): Permission denied can appear during the same failed Squid startup. They name different resources. Fixing the ownership of a cache directory does not, by itself, fix either one.

On Linux, a POSIX shared-memory object is commonly represented under /dev/shm. Its owner and access mode matter. An object left by a different runtime identity can therefore cause a later process to fail even when squid.conf is readable and the listening port is free.

Reconstruct how this instance started

Compare the normal service launch with any manual launch used during troubleshooting. A manually started process and the packaged service may use different users, paths or configuration files. Establish whether another Squid instance is still running before treating an object as stale.

Then read the exact failing operation. A PID error concerns the configured PID location and its parent directory. A log error concerns the log file or directory. A cache initialization error concerns storage. A shm_open error concerns the named shared-memory object and may also involve the security policy applied to the process.

For each resource, compare the required runtime access with its current owner and mode. If ordinary permissions appear sufficient, inspect the relevant SELinux or AppArmor denial evidence. “Permission denied” alone does not identify which layer refused access.

Repair ownership without creating a second problem

Keep the runtime account consistent with the installation's service configuration. Switching everything to nobody can break helper access and introduce a new mismatch with service-managed files.

Nor is deleting every Squid-looking object in /dev/shm a good first move. A named object may belong to an active instance. Cleanup, where required, should target a confirmed abandoned resource with the affected service stopped, followed by startup through the normal service mechanism.

The useful result is a consistent launch and ownership model. Running one command as root until the error disappears can leave the next routine restart with exactly the same problem.