Why Did Nginx Return 403? Uncovering Permissions, UMASK, and Jenkins Pitfalls

Background

The release system consists of Jenkins invoking a deployment program (code‑named varian ) that builds a Docker image, pushes it to a registry, and updates a container cluster accessed via a load balancer.

The original varian was a mix of shell and Python scripts with many compatibility hacks, making the codebase messy. A refactor was undertaken to rewrite varian entirely in Python, modularize functionality, and upgrade Jenkins to the latest version with JDK 1.8.

New environment details:

OS: Debian 8

Language: Python 3.4

JDK 1.8 + Jenkins 2.134

Fault Handling Process

Resolving Nginx 403 Errors

After deploying a static HTML project via Jenkins, the web page loaded without styles because the CSS file returned a 403 status. The browser console showed the failed request.

Typical reasons for Nginx returning 403 include:

IP not in whitelist

Directory listing disabled for a directory request

File owned by a user/group without read permission for the Nginx worker user

Incorrect index directive (e.g., pointing to index.shtml when only index.html exists)

In this case the problem was file permissions: Nginx ran as www-data, but the CSS file was owned by root with no permissions for others.

Understanding Linux File Permissions

-rw-r----- 1 root root 7.9K Jul 24 12:34 csl.css

The first ten characters represent the permission bits. The first character indicates the file type ( - for regular file, d for directory, l for link). The next nine characters are grouped in threes for owner, group, and others, with r =4, w =2, x =1.

Owner has read/write (rw‑)

Group has read only (r‑‑)

Others have no permissions (---)

Other fields show link count, owner, group, size, modification time, and filename.

Tomcat8 UMASK Issue

Running the deployment script directly from a Linux console produced files with correct permissions, but the same script executed by Jenkins resulted in incorrect permissions.

Investigation revealed that the generated files inherited the UMASK value of the process. Both the root and Jenkins users had a UMASK of 0022, which should yield 644 for files. However, Tomcat8 (the container running Jenkins) changed its default UMASK to 0027, causing the generated CSS file to lack read permission for the Nginx user.

After adjusting Tomcat8’s UMASK back to 0022, the permission problem was resolved.