[emerg] open() "/etc/nginx/nginx.conf" failed (13: Permission denied) after configuration restore

Direct Answers

Automatic Detection: Nginx does not automatically detect changes to its configuration files. The master process reads nginx.conf only during the initial startup or when it receives an explicit signal (SIGHUP) via a reload or restart command.

Reload Verification: To ensure a reload has fully applied the restored configuration without leaving stale processes, first run nginx -t to validate syntax. After executing nginx -s reload, verify the process tree using ps auxf. You should see a single master process with new worker process IDs (PIDs); if multiple master processes exist, the reload failed or a stale process is lingering.

Persistent Permission Errors: Yes, a "Permission denied (13)" error can persist despite root:root ownership and 644 permissions if Mandatory Access Control (MAC) systems like SELinux or AppArmor are active. These systems evaluate security contexts and profiles independently of standard Linux DAC permissions.

Analysis and Resolution

Confirmed Technical Facts

• Process Lifecycle: Nginx workers inherit configuration from the master process at the time of forking. A failed reload leaves the existing master and its workers running, which can mask restoration errors.
• Path Traversal: The master process requires execute (+x) permissions on every parent directory in the path (/etc and /etc/nginx) to access the configuration file.

Likely Causes for Permission Denied

When standard permissions are correct, the failure is typically caused by an incorrect SELinux security context (e.g., the restored file lacks the httpd_config_t type) or an AppArmor profile restricting access to the specific restored path.

Recovery Steps

1. Fix SELinux Contexts: Restore default security contexts for the Nginx directory:

   restorecon -Rv /etc/nginx

2. Verify Path Permissions: Ensure the directory chain is traversable:

   stat /etc /etc/nginx

3. Validate and Apply: Test the configuration and reload the service:

   nginx -t && nginx -s reload

4. Confirm Process State: Check for a single master process:

   ps auxf | grep nginx

Assumption: This guide assumes a standard Linux distribution (e.g., RHEL, CentOS, or Ubuntu) where Nginx is managed by a master process running as root.

Diagnostic Detail Needed: Are you running Nginx inside a container? If so, the issue may stem from the host's security labels or the container's securityContext rather than the internal file permissions.